SPF, DKIM and DMARC in practice

Email authentication has an unusual property: almost everyone has deployed some of it, and almost nobody has finished. Records exist, they were set up once, and they quietly drift as new sending systems get added by people who never see the DNS zone. This piece covers what each mechanism proves, what changed in the specification this year, and the sequence that gets a domain to enforcement without breaking legitimate mail.

What each mechanism actually proves

The three protocols are usually described as layers, which obscures the more useful point that they answer different questions about different identifiers.

SPF validates the envelope sender, the address used in the SMTP transaction, which the recipient never sees. DKIM validates the domain in the signature header, which the recipient also never sees. Both can pass on a message whose visible From address belongs to someone else entirely, which is exactly the gap that made domain spoofing so easy for so long.

DMARC closes it by requiring alignment. As RFC 9989 puts it, a DMARC pass requires not only an SPF or DKIM pass but that the domain associated with that pass shares an organisational domain with the visible From domain, in relaxed mode, or is identical to it, in strict mode. A message can pass both underlying checks and still fail DMARC. That is not a bug; it is the entire purpose.

One consequence is worth stating plainly for anyone auditing a configuration: a green tick on an SPF checker tells you very little on its own. The question is always whether the validated identifier lines up with the From domain.

SPF, and the ways it runs out

SPF’s practical limits matter more than its syntax. The specification caps the number of DNS-querying mechanisms at ten, and includes a separate limit on lookups that return nothing. Every third-party sender you authorise through an include costs part of that budget, and the budget is consumed by the full expansion, not the count of entries in your own record. Organisations rarely notice they have crossed the limit until mail from one particular system starts failing, because exceeding it produces a permanent error rather than a clean fail.

The second trap is the hard fail qualifier. RFC 9989 notes that an SPF hard fail can cause rejection early in the SMTP transaction, before DMARC processing happens at all. A message that would have passed DMARC on an aligned DKIM signature can be rejected purely on SPF. Worse for diagnosis, those rejections never reach the data phase, so the From domain is never revealed and the message never appears in your aggregate reports. You lose both the mail and the evidence.

Finally, SPF generally does not survive forwarding. When a message is relayed by an alumni address, a role alias or a mailing list, the connecting address belongs to the relay rather than to you.

DKIM, and why it carries more weight now

DKIM signs selected headers and the body with a private key, publishing the public key in DNS under a selector. Because the signature travels with the message, it usually survives relaying, which is precisely why the specification now leans on it.

Two operational habits do most of the work. Use a distinct selector for each sending system, so that rotating or revoking one platform’s key does not disturb the others and so that reports tell you which system signed what. And rotate keys on a schedule you actually keep, which in practice means one you have automated. Key length should follow current guidance rather than whatever a provider defaulted to years ago, and any signing still using SHA-1 needs replacing.

DKIM breaks when something modifies the signed content in transit. Mailing lists that append footers or rewrite subject lines are the usual culprits, and this is a known limitation rather than a fault in your configuration.

What changed in the specification this year

In May 2026 the IETF published RFC 9989 along with RFC 9990 for aggregate reporting and RFC 9991 for failure reporting. Together they obsolete RFC 7489 from 2015 and move DMARC onto the Standards Track. The original was published through the independent submission stream as an informational document, which is a detail that used to matter when arguing with auditors and no longer does.

Records still begin with the same version tag, and unknown tags must be ignored, so there is no emergency here. The removals are straightforward: the percentage tag is gone, replaced by a test-mode flag that is all or nothing, and two reporting tags that receivers largely ignored have been dropped. The test-mode flag has a specific meaning worth reading carefully, because it applies the policy one level below the one you declared. Setting it alongside a quarantine policy results in none being applied; alongside reject, quarantine is applied.

The additions are more interesting. A non-existent subdomain tag lets you set a separate policy for subdomains that do not exist in DNS at all, which closes a spoofing gap that previously required publishing records defensively across a namespace. A public suffix domain tag declares whether a name is a public suffix, and setting it to no lets a delegated part of a large organisation declare itself an organisational boundary with its own policy and reporting.

Policy discovery itself has been rebuilt. The Public Suffix List is replaced by a DNS tree walk, in which the receiver queries for a record at the author domain, then works up the hierarchy. There is a hard cap of eight queries to prevent abuse, and it has a sharp edge: if an author domain has more labels than the walk will reach, a record published at an intermediate node will never be discovered. The specification is explicit that domains wanting a specific policy on a deeply nested name must publish a record at that name.

The two requirements most likely to change your plan

First, receivers are now told they must not reject messages solely because a domain publishes a reject policy, and that in the absence of other analysis they must treat failing mail as though the policy were quarantine. This reframes what publishing reject actually buys. It is a strong request that participating receivers weigh alongside their own signals, not a switch that discards mail on your behalf. If your programme’s business case rested on reject being absolute, it needs restating.

Second, and pointing the other way, the conformance requirements state that a domain owner publishing reject must not rely solely on SPF for a DMARC pass and must apply valid DKIM signatures. The logic follows directly from forwarding: SPF breaks on relayed mail and DKIM usually does not, so an SPF-only domain at reject is systematically damaging its own legitimate indirect mail. If you are at reject today with unsigned mail streams, that is now a conformance gap and not merely an inelegance.

The specification is also candid about a technology often presented as solving this. It notes that Authenticated Received Chain and similar methods intended to let mailing lists work without rewriting the From header have not achieved wide use as of publication. Plan for list software rewriting your senders’ addresses, because that remains the established behaviour.

A deployment sequence that does not break mail

The order matters more than the speed. Inventory first: every system that sends using your domain, including the ones procurement bought without telling you. Marketing platforms, ticketing systems, payroll, CRM, monitoring alerts and the appliance in the server room all count.

Then publish SPF and configure DKIM signing for each of those systems with an aligned domain, before publishing any DMARC policy. Set up a mailbox for aggregate reports and something to parse them, because they are XML and reading them by hand does not scale past a day or two.

Publish DMARC at none with a reporting address, and then wait. This is the step organisations compress and regret. RFC 9989 suggests running at none for at least a month, then quarantine for an equally long period, comparing the results before deciding on reject. Use that time to fix what the reports reveal rather than to prove the project is progressing.

One more thing about reports: a record with a valid reporting address but an invalid policy tag is treated by receivers as though it said none. Syntax errors do not fail loudly here. They fail silently, at the exact moment you believed you were protected, which is why validating the published record from outside your own network is a step rather than an afterthought.

What this does and does not stop

DMARC addresses exact-domain spoofing. It does not address lookalike domains, and it explicitly does not address abuse of the display name, which is the part most recipients actually read. An attacker who registers a similar domain, or who simply sets the display name to your chief executive while sending from a webmail account, is unaffected by anything in this article.

It also does nothing about the technique currently taking over accounts at scale, in which a genuine sign-in page is relayed so that authentication succeeds and the session is stolen. We covered one active campaign doing exactly that, and the authentication of the phishing email itself was never the control that would have stopped it.

What email authentication does is remove your domain as a free asset for attackers, make your legitimate mail more deliverable as mailbox providers tighten their requirements for bulk senders, and give you visibility into who is using your name. Those are worth having. They are not the same as being protected from phishing, and a programme sold internally as the latter will eventually embarrass whoever sold it.

Last verified: 7 August 2026 against RFC 9989, RFC 9990 and RFC 9991. Mailbox provider requirements for bulk senders change independently of the specification and should be checked against each provider’s current guidelines.