Email authentication is three DNS records, published on your own domain, that let a receiving mail server decide whether a message really came from you. SPF names the servers allowed to send. DKIM signs each message so tampering shows. DMARC says what to do when the first two disagree with the address in the From header, and asks for reports about it.
Publishing all three used to be good practice. Since February 2024 it is a condition of delivery at the largest mailbox providers, and most domains still have not finished. Across the domains we test for the Unspam 2026 Email Deliverability Benchmark, 93% publish a valid SPF record and 90% sign with a working DKIM key, but only 48% publish a DMARC policy. The gap between 90 and 48 is this entire article.
You can see where your own domain stands in about thirty seconds with a free email health check, which reads all three records at once and tells you which of them a receiver would actually act on.
The three records answer three different questions
A receiving server does not ask one question about your mail. It asks three, and each record answers exactly one of them.
| Record | The question it answers | What it is |
|---|---|---|
| SPF | Was this server allowed to send for this domain? | A TXT record listing permitted senders |
| DKIM | Was this message altered, and who signed it? | A public key in DNS, plus a signature in the header |
| DMARC | What should I do when the answers do not match the From address? | A TXT record with a policy and a reporting address |
The order matters because DMARC is not independent. It is a decision layer sitting on top of the other two, and it has nothing to act on until at least one of them passes. A domain with DMARC but no working SPF or DKIM has published an instruction that can never be followed.
SPF publishes which servers may send for your domain
SPF is a list of the servers you have authorized, published as a DNS TXT record on your own domain. When a server connects to deliver mail claiming to be from you, the receiver looks up that list and checks whether the connecting IP address is on it.
A record looks like v=spf1 include:_spf.google.com include:sendgrid.net ~all. Each include delegates to another organization's list, which is how you authorize Google Workspace and your marketing platform at the same time without tracking their IP addresses yourself.
Two limits catch people out. The first is that SPF allows a maximum of ten DNS lookups per check, and every include spends at least one. Exceed it and the result is a permanent error, which most receivers treat as a failure rather than as a missing record. The second is that SPF breaks on forwarding: when a mailing list or a forwarding address relays your message, the connecting server is theirs, not yours, and SPF fails through no fault of your own. That second limit is precisely why DKIM exists. Our guide to SPF records covers the syntax and the lookup budget in full. SPF breaking on forwarding is also the problem ARC was built to solve, and our guide to ARC covers why that experiment is being retired.
DKIM signs the message itself, so forwarding does not break it
DKIM attaches a cryptographic signature to each outgoing message, generated with a private key your sending platform holds. You publish the matching public key in DNS, and the receiver uses it to verify the signature.
Because the signature covers the headers and body rather than the connection, DKIM survives being forwarded. It also proves the message was not altered in transit, which SPF cannot do at all. That combination makes it the stronger of the two signals and the one DMARC is most likely to be relying on when your mail passes.
Keys are rotated on a schedule by every reputable sending platform, and the selector in the header is what lets a domain carry several keys at once: s1._domainkey.example.com and s2._domainkey.example.com can both be live, which is how a rotation happens without a gap. A receiver reads the selector out of the signature and looks up only that key. Use 2048-bit keys rather than 1024-bit ones; the shorter length still validates but is no longer considered adequate. The full record format is in our guide to DKIM signatures. How long a key should be, and the ways an upgrade quietly shortens it, are in our guide to DKIM key length.
DMARC only works when SPF or DKIM aligns with your From domain
Alignment is the part most introductions skip, and it is where working records fail. DMARC does not ask whether SPF or DKIM passed. It asks whether either of them passed for the same domain your reader sees in the From header.
Your marketing platform can sign every message perfectly with its own domain and pass SPF on its own sending domain, and DMARC will still fail, because neither identifier matches yours. The fix is configuring that platform to sign as your domain, which every serious sending platform supports and many customers never switch on. The address SPF authenticates is the envelope sender rather than the one your reader sees, which our guide to the Return-Path covers in full.
Once a receiver has an alignment result, your policy tells it what to do:
p=nonemeans take no action and send me reports. This is the starting position, not the destination.p=quarantinemeans put failing mail in the spam folder.p=rejectmeans refuse it at the door.
Two things about DMARC changed in May 2026 that most documentation has not caught up with. RFC 9989 replaced RFC 7489, making DMARC a standards-track specification rather than an informational one, and it retired the pct, ri and rf tags. If your record carries pct at anything below 100 alongside quarantine or reject, your enforcement is now stricter than you configured it, with no edit to your DNS. Our guide to DMARC records covers each tag.
Mailbox providers stopped treating DMARC as optional in 2024
Any guide telling you DMARC is recommended but not required is describing the world before February 2024. That month, Google and Yahoo both began requiring a DMARC policy from bulk senders to their own mailboxes. Apple followed in February 2025 and Outlook.com in May 2025.
Four details are worth getting right, because they are commonly reported wrong:
- Google's threshold is 5,000 messages a day to personal Gmail addresses. Outlook.com uses the same number for its consumer mailboxes. Yahoo has publicly declined to publish one at all, so treat any figure attributed to Yahoo with suspicion.
p=nonesatisfies the requirement. The providers require a published policy, not enforcement. Starting at none is compliant and is also the correct way to start.- Microsoft's rule covers Outlook.com consumer mail, not Microsoft 365 tenants. If you send business to business, that requirement does not describe your recipients.
- Spam complaint rates carry their own threshold, 0.3% at Google and Yahoo, and a rate below 0.1% is what Google recommends rather than requires.
Authentication is necessary but not sufficient. A perfectly authenticated message still lands in spam if the content trips a filter, which is scored separately and is the subject of our guide to SpamAssassin scores.
Five ways these records fail while looking correct
Every failure below produces a record that reads fine to a human and does nothing at a receiver. They are the ones our own analyzer was built around, in rough order of how often we see them.
Two SPF records on one domain. Publishing a second TXT record rather than editing the first does not merge them. The result is a permanent error, and most receivers treat a permanent error as a failure rather than as no record at all. One domain, one SPF record, always.
More than ten DNS lookups in the SPF chain. Each include costs at least one lookup, and the vendor behind it may spend several more inside its own record. Four or five providers is enough to blow the budget. The record still looks short and readable; it simply stops evaluating partway through.
A typo in the DMARC sp or np tag. This is the cruelest one. An invalid subdomain policy discards the entire record, including a perfectly good p=reject. v=DMARC1; p=reject; sp=quarintine protects nothing at all, and a checker that reports the p it managed to read will tell you the domain is locked down.
Nothing aligned with the From domain. SPF passes on the platform's domain, DKIM signs with the platform's domain, both checks report a pass, and DMARC fails anyway. Every result in your logs looks green. This is the single most common reason a carefully configured domain sits at p=none for a year.
A policy of p=none mistaken for protection. None is an instruction to do nothing. It is the right place to start and the wrong place to stop, and a domain that has sat there for two years is publishing a request for reports nobody reads.
Publish them in order, because DMARC depends on the other two
The sequence below is not a preference. Reversing it publishes a policy with nothing underneath it.
- Publish SPF and confirm it passes. One record per domain, under ten lookups, ending in
~allor-all. Two SPF records on one domain is a permanent error, not a merge. - Turn on DKIM signing at every platform that sends as you. Your ESP, your CRM, your helpdesk, your invoicing tool. Each one publishes its own selector.
- Check that at least one of them aligns with your From domain. This is the step that gets skipped, and skipping it makes everything after it decorative.
- Publish DMARC at
p=nonewith a reporting address. You are collecting evidence, not enforcing anything yet. - Read the reports for two to four weeks. You are looking for legitimate senders you forgot about, because those are what an enforcement policy would block.
- Move to
p=quarantine, thenp=reject. Only once every legitimate source is passing and aligned.
Step five is where the tooling matters, because raw DMARC reports arrive as XML and are close to unreadable by hand. We compared the options in our roundup of DMARC monitoring tools, including the free ones. If you only want to confirm your record is published and parses correctly, a free DMARC checker is enough.
BIMI shows your logo in the inbox, and almost nobody qualifies yet
BIMI displays your brand's logo beside your messages in supporting inboxes, and it is the only one of these standards your recipients can see. It is also the only one that requires the others first: a domain must already be at p=quarantine or p=reject before a receiver will show the logo.
Adoption is genuinely rare. 99% of the domains we test publish no BIMI record at all, which makes it one of the few remaining ways to look different in a crowded inbox. Gmail additionally requires a Verified Mark Certificate, a paid attestation that you own the trademark on the logo, which is the main reason the number stays where it is.
Treat BIMI as the reward for finishing DMARC rather than as a separate project. If you are not at enforcement, there is nothing to configure yet.
What to check after you publish
Records drift. A platform gets added without an SPF update, a key gets rotated badly, someone edits a record by hand and drops a semicolon. The failure is silent, because nothing in your own mail flow tells you that a receiver started rejecting.
Four checks are worth running on a schedule:
- All three records parse and say what you think they say. An invalid
spornptag discards an otherwise perfect DMARC record entirely, and a checker that reports thepit can read will hand you a green badge on an open domain. - Every sending platform still aligns. New tools get bought, and they do not authenticate themselves.
- Your DMARC reports still arrive. If your reporting address falls out of the record, the reports stop and nothing announces it.
- The message itself still passes. Only 89% of the messages we test clear a full deliverability check, with 9% drawing a warning and 2% failing outright, and authentication is only part of that score.
Getting all three records right is the highest-leverage work available in deliverability, because it is the only part a receiver checks before it reads a single word you wrote. If the records are beyond what you want to handle in-house, an email deliverability consultant can take the rollout. Otherwise, run a free spam test on a real message and read the authentication results next to the content ones, which is the fastest way to see what a receiver sees.
