On 7 September 2026 we queried the public DNS records of 219 mail domains belonging to large Spanish companies across eight sectors, from banking to construction. Three in four have a DMARC blocking policy, but only 38% have reached p=reject, 27% remain unprotected (7% publish no record and 20% sit at p=none), and one in five SPF records is three DNS lookups or fewer away from failing.
Publishing DMARC with a p=none policy stops nobody from sending mail in your domain's name: it merely asks the servers that receive it to report what they see. It is a gauge, not a control.
Large Spanish companies are well ahead of the global average across domains of every size: according to the EasyDMARC 2026 adoption report, covering the top 1.8 million domains, 52.1% publish a DMARC record and only around 9% pair a blocking policy with the reports that show what is being blocked. The Spanish problem is not the start; it is the last stretch.
At Hard2bit we review SPF, DKIM and DMARC in every Microsoft 365 security audit and in our public attack surface scanner, and in mid-sized companies we nearly always find the same scene: a DMARC record exists, the policy is none, and the reports land in a mailbox nobody opens. The scan of large companies shows that many have moved past that stage and stalled at the next one: quarantine, without the final step.
What did we find across 219 large-company domains?
The sample is made up of large companies from eight sectors chosen on public criteria: listed on the Spanish stock exchange, licensed by the Bank of Spain or the insurance regulator, private universities, and the largest companies by revenue in each sector according to published rankings. Of 233 candidate domains, the 219 that receive mail were scanned.
Every check is a read of public DNS records, the same ones any mail server consults when a message arrives, and results are published only as aggregates by sector, with at least 23 companies per group and no company named.
By sector, technology and telecoms, together with retail and consumer goods, lead with 87% of domains under a blocking policy, followed by banking and insurance (83%), energy (76%) and manufacturing (75%). Healthcare and pharma sits at 65%, and private higher education and construction, property and logistics close the table at 55%. In education, 38% of domains remain at p=none, the highest share in the sample; in construction and logistics, 17% publish no DMARC record at all.
The reject policy, the only one that truly prevents spoofing, passes the halfway mark only in banking and insurance (62%); retail sits exactly at 50%. Technology, with 87% under blocking, has 47% at quarantine and only 40% at reject; energy has 44% at quarantine and 32% at reject. Quarantine sends spoofed mail to the junk folder, where the user can still open it.
Two secondary findings matter as much as the policy itself. Eleven domains have a blocking policy but no reporting address, so they block mail without knowing what they are blocking. And eleven of the 84 domains at p=reject publish none of the usual DKIM selectors, which suggests they rely on SPF alone, precisely what RFC 9989 forbids for a reject policy. The scan cannot rule out a custom selector, so this is a suspicion, not proof.
The SPF figure is the most surprising. Almost everyone publishes a record (216 of 219) and 77% of those that do end in -all, but six domains already exceed the ten-lookup limit, so their SPF should return a permanent error at any receiver applying RFC 7208 strictly, and another 49, or 22%, sit between eight and ten.
Every new sending provider signed up by any department adds one or more includes, and the record breaks without anyone touching DMARC. Technology (11 domains between eight and ten, two above) and education (9 and 3) are the sectors closest to the edge.
The later layers barely exist: MTA-STS appears on 6 domains out of 219, TLS-RPT on 10 and BIMI on 23, two thirds of them in banking, retail and technology. The np tag from RFC 9989 is published by none, and sp, which protects existing subdomains, by only 20%.
What the big mailbox providers and the new standard now require
Since 1 February 2024, any sender delivering more than 5,000 messages a day to Gmail accounts has had to publish SPF and DKIM and hold a DMARC record, which Google accepts at p=none as a minimum. On top of that, the domain shown in the visible From address must match the domain authenticated by SPF or DKIM, known in the trade as alignment.
Google's email sender guidelines add infrastructure and good-practice requirements on top of the authentication ones: valid PTR records, TLS in transit, a spam complaint rate below 0.3% (Google recommends staying under 0.1%) and one-click unsubscribe for commercial mail. The same guidelines set a floor for every sender, whatever the volume: SPF or DKIM at the very least.
Microsoft took an equivalent position a year later. From 5 May 2025 its notice for high-volume senders applies the same three authentication requirements (SPF, DKIM and DMARC with alignment) to anyone sending more than 5,000 messages a day to Outlook.com consumer mailboxes and their sister domains. Senders that fall short first see their mail routed to the junk folder and, on a date Microsoft has yet to announce, will see it rejected with error code 550 5.7.515.
The DMARC standard itself has been renewed. In May 2026 the IETF published RFC 9989, which replaces RFC 7489 from 2015 and raises DMARC to Proposed Standard; it is accompanied by RFC 9990, covering aggregate reports, and RFC 9991, covering failure reports.
Under RFC 9989 a DMARC record still begins with v=DMARC1, so nothing needs migrating in a hurry, but several parts of the deployment model change: the pct, rf and ri tags become historic, np arrives for non-existent subdomains and t=y for testing a policy without fully applying it, and organisational-domain discovery no longer depends on the Public Suffix List. One sentence in the RFC deserves underlining by anyone responsible for corporate mail: domains that publish p=reject must not rely on SPF alone and must sign with DKIM, and the RFC phrases that as an obligation.
On the Spanish regulatory side, the National Security Framework (ENS) reserves a specific measure for email within its service-protection block, mp.s.1, and domain authentication is the most direct evidence for it in an ENS certification. Outside Spain, the UK's NCSC has maintained an email security and anti-spoofing guide since 2019 that orders deployment in this sequence: TLS, SPF, DKIM, DMARC at none, quarantine and, last of all, reject.
Why so many organisations stall at p=none
The most common objection deserves a serious answer because it is legitimate: the fear of losing mail. An ordinary corporate domain sends from the mail server, but also from the CRM, the marketing platform, the invoicing system, the ticketing tool, the payroll provider, the e-signature service and half a dozen other systems nobody wrote down when they were signed up for. Any of them that fails to authenticate properly will start failing the moment the policy moves to quarantine, and the first to notice will be the customer who does not receive an invoice.
Two technical traps add to that objection and punish anyone who moves to reject unprepared. One is the SPF limit: RFC 7208 requires receivers to abort evaluation with a permanent error if a record triggers more than ten DNS lookups, and each provider's include consumes one or several. The other is forwarding: when a mailbox forwards a message automatically, or a distribution list resends it, SPF fails because the originating IP is no longer the original sender's, a problem documented in RFC 7960 as far back as 2016.
A third trap is forgotten subdomains: mail from some legacy system still leaves through them and, unless somebody assigns them a policy of their own, they inherit the parent domain's. When the parent domain moves to reject, that mail vanishes and nobody knows why.
The consequence of that objection and those three traps is familiar: the systems team publishes p=none to satisfy Google's requirement, confirms that mail still arrives and closes the request. Meanwhile anyone can keep sending fake invoices with the company's domain in the From field, and receivers treat them like any other message without a blocking policy.
Why the reports answer the objection
The answer to the fear of losing mail is built into DMARC itself, in its reports. The aggregate reports are requested through the rua tag and sent by Google, Microsoft, Yahoo and every other participating receiver. They state, for each IP that has sent mail using your domain, how many messages there were, whether they passed SPF, whether they passed DKIM and whether they were aligned. Read over a few weeks, they build up the complete inventory of legitimate senders nobody had on paper, together with the sources spoofing the domain.
The forwarding problem is solved by DKIM: the signature travels inside the message and survives the hop between servers as long as nobody alters the signed body. For that reason RFC 9989 makes DKIM mandatory for anyone publishing reject, and for that reason the NCSC notes that DKIM, though less widely deployed than SPF, is the mechanism that copes with forwarded mail.
Distribution lists that rewrite the subject or append a footer remain the hard case, because they break the DKIM signature. For that scenario RFC 9989 asks receivers not to reject a message solely because of the published policy and to draw on other signals so those flows are not broken.
SPF's ten-lookup limit is handled with inventory: remove from the record the providers that already sign with aligned DKIM, drop the includes of services that were cancelled and, if it still does not fit, move bulk mail to a subdomain with an SPF record of its own. Subdomains are covered by the sp tag, for those that exist, and np, for those that do not, so that an attacker cannot simply invent one.
How to reach p=reject without losing mail
The sequence that follows from RFC 9989 and the NCSC guide fits into six steps, and none of them should be skipped.
- Publish DMARC in monitoring mode from day one: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.example. If the reports go to a domain other than the one publishing the policy, that domain has to authorise it with a _report._dmarc record; otherwise receivers discard them.
- For at least a month, turn the aggregate reports into an inventory: every legitimate source with its service, its internal owner and its authentication method. The reports are XML files written for machines, so an analysis tool, commercial or open source, saves you reading them by hand.
- Fix authentication source by source: each provider signs with DKIM aligned to your domain, with keys of at least 1,024 bits (Google requires that minimum and recommends 2,048) and with selectors of its own that you can rotate without touching the rest. In SPF include only what is essential and end the record with -all without exceeding ten lookups.
- Move to p=quarantine once every known source passes authentication. RFC 9989 offers the t=y tag to ask receivers to apply the policy one step below the one published while reports keep flowing; it replaces the old gradual roll-out through the pct tag, which the same RFC marks as historic.
- Move to p=reject once the reports have gone weeks without failures from legitimate sources. Declare sp=reject so that any subdomain without a record of its own inherits the rejection, and np=reject for subdomains that do not exist; subdomains that do send mail need a DMARC record of their own.
- Lock down the domains that send no mail, often more numerous than those that do: v=spf1 -all, a null MX record and DMARC at reject. A parked domain without that configuration is among the first an attacker tries to spoof.
With the six steps done, two layers remain that protect inbound mail in transit and leave outbound identity to DMARC: MTA-STS, which obliges whoever sends you mail to use valid TLS and stops an intermediary downgrading the connection, and TLS-RPT, which reports failures in that negotiation. In our report on 60 large European enterprises, 98% of domains published some DMARC record and only 15% published MTA-STS: outbound mail has been on the agenda of large organisations for years; inbound transport has not.
What to watch afterwards
Reaching the rejection policy is not the end of the job. The aggregate reports still need reading, because every new provider signed up by marketing or HR will reappear as an unauthenticated source, and because the IPs that keep trying to spoof the domain are useful information for the security team. An attack surface assessment that covers email also catches the lookalike domains DMARC cannot reach: in June we scanned 24 brands and found 591 live lookalike domains, against which no policy on the legitimate domain helps.
The price of leaving the domain at p=none
Email fraud comes with an official price tag. The FBI's IC3 2025 annual report records 24,768 complaints of business email compromise with $3.046 billion in reported losses, up from $2.77 billion in 2024; total reported cybercrime in 2025 came to $20.877 billion. The complaints were filed with the FBI, mostly from the United States, and no directly comparable series exists for Spain, but the fraud works the same way in any country.
DMARC stops direct spoofing of the domain, one of the hardest forms of phishing for a user to detect because the sender is exactly the real one, and that alone. It does not stop a lookalike domain, a legitimate mailbox taken over with stolen credentials, or a call made with a cloned voice. Each of those needs its own controls, and the existence of those threats is no excuse for leaving the domain open.
The one thing the board cannot delegate
Moving from p=none to p=reject is a business decision that looks like a technical task, because it requires someone with authority to tell every department that buys a mailing tool: your sending providers authenticate properly or you stop using the domain. Without that backing, nobody in the systems team will take on the risk of breaking another department's mail, and the policy stays at none.
As a cybersecurity company that audits domains every week, and having just reviewed the 219 in this scan, what we see failing is almost never the DNS configuration, which is a matter of hours. What fails is that the domain has no recognised owner inside the organisation. Naming that person is what the board cannot delegate.
About the scan: the sector figures come from public DNS queries made on 7 September 2026 against 219 mail domains of large Spanish companies selected on the criteria described in the text; only aggregates by sector are published, with at least 23 companies per group, and no company is identified. The absence of a common DKIM selector does not prove that a domain does not sign with DKIM. DNS records change, and a company may have altered its policy after that date.
This article is for general information. The records and deployment sequence described are based on RFC 9989, RFC 7208 and the public guidelines of Google, Microsoft and the NCSC at the date of publication, and must be adapted to each organisation's sender inventory and tooling; a reject policy applied without a prior inventory can block legitimate mail. Adoption and fraud figures come from third parties and are cited with their source.
