An email that does not arrive costs more than an email that is badly written. Since February 2024, Google and Yahoo have required bulk senders to authenticate fully and publish a DMARC record; Microsoft followed in 2025 for Outlook.com. Authentication is no longer one good practice among others: it is the entry condition. Here is what SPF, DKIM and DMARC cover, and the order in which to deploy them.
Three mechanisms, three different questions
| Mechanism | Question it answers | Where it lives |
|---|---|---|
| SPF | Is this server allowed to send for this domain? | DNS TXT record |
| DKIM | Has the message been altered since it was sent? | Header signature + public key in DNS |
| DMARC | What should happen when SPF or DKIM fails, and who is told? | DNS TXT record |
The most widespread confusion is believing these mechanisms replace one another. They complement each other: DMARC only works on top of SPF and DKIM, and its main benefit — the reports — does not exist without them.
SPF: declaring authorised servers
SPF is a TXT record at the domain root listing the servers allowed to send on its behalf. A self-hosted site that delegates delivery to an email platform must include that platform.
; TXT record on example.com
"v=spf1 include:spf.brevo.com include:_spf.ovh.net -all"Two details decide the outcome:
- The terminator.
-all(hard fail) is the right choice once the list of senders has been verified.~all(soft fail) is a transition step, not a destination. - The ten-DNS-lookup limit. Every
include:triggers a resolution; beyond ten, verification returns a permanent error and SPF stops protecting anything. Records accumulated tool by tool are the most frequent cause of that overrun.
An SPF record that exceeds ten DNS lookups protects nothing: it fails silently, and nobody notices before deliverability drops.
DKIM: signing to prove integrity
DKIM adds a cryptographic signature to the message headers. The recipient fetches the public key from the sender’s DNS and verifies that the signed content was not modified in transit.
; public key, on a dedicated selector
mail._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."In practice the key is generated by the sending platform, which supplies the record to publish. The point to watch is the selector: each service uses its own, which lets several senders coexist on one domain without conflict. A key rotation on the provider’s side requires republishing the record — a frequent oversight when changing platforms.
DMARC: policy and reports
DMARC tells receiving servers what to do when authentication fails, and where to send reports. It is also what enforces alignment: the domain visible in the From: field must match the one validated by SPF or DKIM. A message perfectly signed for a third-party domain but displaying your name fails DMARC — which is precisely the mechanism that blocks impersonation.
; start in observation mode
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"
; target once the reports are clean
_dmarc.example.com. TXT "v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]; adkim=s; aspf=s"The recommended progression
p=none— no effect on delivery, but reports start arriving. Allow two to four weeks to inventory every legitimate sender: invoicing tool, CRM, site form, email platform.p=quarantine— unauthenticated messages go to junk. Enable once the reports are clean, optionally on a partial percentage throughpct=.p=reject— unauthenticated messages are refused. This is the target, and what the major providers expect from bulk senders.
p=reject on a domain that sends through several tools means cutting delivery for the ones you had forgotten. Aggregate reports exist precisely to prevent that.What authentication does not solve
SPF, DKIM and DMARC answer the question “does this message really come from this domain”. They say nothing about its quality. A perfectly authenticated domain sending unsolicited content lands in junk like any other: IP reputation, complaint rate, unsubscribe rate and engagement then take over. Authentication opens the door; it does not guarantee a welcome.
Two complements are worth adding in the same pass: BIMI, which displays the sender’s logo in compatible clients and requires at least p=quarantine, and a one-click unsubscribe link compliant with RFC 8058, now expected from bulk senders.
Verify before concluding
| Check | Method |
|---|---|
| Records published | dig +short TXT example.com and dig +short TXT _dmarc.example.com |
| SPF lookup count | An online SPF validator; above 10, reduce the include: entries |
| Actual alignment | Test message to a Gmail address, then “Show original”: all three lines must read PASS |
| Sender coverage | Reading DMARC aggregate reports for two to four weeks |
What to take away
The deployment order does not vary: SPF first, then DKIM, then DMARC in observation, then a progressive tightening of the policy. Each step is verified before the next. The shortcut — publishing all three records on the same day at p=reject — is the fastest way to cut legitimate mail without knowing which.
On every domain I administer, moving to p=reject revealed a forgotten sender: an invoicing tool, a backup notification, an old form. DMARC reports at p=none are not there to tick a box — they are there to reveal what sends in your name without your knowing. — Simon Janvier
Further reading
Provider requirements are documented on the Google Workspace side. The DMARC specification is RFC 7489.
