SPF, DKIM and DMARC, explained in plain English
The three DNS records that decide whether providers trust your mail — what each one actually does, how they fit together, and the mistakes that quietly break them.
Deliverability · 3 min read · updated
The problem all three exist to solve
The From address on an email is a claim, not a fact. The protocol lets anyone put anything there, which is why your bank's name appears on mail your bank never sent. SPF, DKIM and DMARC are three DNS records that let a receiving server check the claim — and since 2024, the major providers require all three from any serious sender.
They answer different questions, which is why you need all of them rather than any one.
SPF: who may send for this domain
A TXT record listing the servers allowed to send mail claiming your domain. A receiver checks the connecting IP against the list. Simple — with two sharp edges.
- The ten-lookup limit. Every include: costs DNS lookups, and past ten the whole record fails permanently. Old vendor includes you forgot about are the usual culprit — audit the record when you leave a provider, not just when you join one.
- Forwarding breaks it. When someone forwards your mail, it arrives from the forwarder's IP, which is not on your list. This is expected — it is why SPF alone was never enough and DKIM exists.
DKIM: proof the message wasn't altered
A cryptographic signature added to every message, checked against a public key you publish in DNS. Unlike SPF it survives forwarding, because the signature travels inside the message rather than depending on which server delivered it.
Use a 2048-bit key, and rotate keys periodically — a leaked signing key means someone else can sign as you, and you would have no way to know.
DMARC: the policy and the reports
DMARC ties the other two together. It tells receivers what to do when a message fails — and, crucially, it requires that the domain that passed matches the domain in the visible From line. That check is called alignment, and it is the part everyone gets wrong: a vendor signing with its own domain passes DKIM but fails alignment, and therefore fails DMARC.
The policy ladder is p=none (deliver anyway, send me reports), p=quarantine (spam-folder failures) and p=reject (refuse them). Start at none, read the reports until the legitimate sources all pass, then climb. Jumping straight to reject silences whichever internal system you forgot was sending mail.
The mistakes that quietly break everything
- Two SPF records. The standard allows exactly one. A second one — usually added by a new vendor's setup wizard — makes both invalid. Merge them into one record.
- Reject before reading reports. The reports exist precisely to show you what would break. Weeks at p=none costs nothing; a premature p=reject costs real mail.
- Forgetting subdomains. DMARC applies to subdomains via the sp tag. An attacker who cannot spoof example.com will happily spoof anything.example.com if you left it open.
- Treating the reports as readable. Raw DMARC reports are XML sent by the thousand. Use an aggregator; nobody reads them by hand twice.
Common questions
Do I really need all three?
For bulk sending, yes — Google, Yahoo and Microsoft have required SPF, DKIM and DMARC with alignment from high-volume senders since 2024–2025. For any sender, they are the difference between a provable identity and an unverifiable claim.
Does p=none do anything at all?
It changes nothing about delivery — its value is the aggregate reports, which show every source sending as your domain, including the ones you forgot and the ones that are attackers.
My SPF and DKIM pass — why does DMARC fail?
Alignment. The domain that passed must match the visible From domain. A vendor authenticating with vendor.com on mail sent as you@yourbrand.com passes its own checks and fails yours. Fix it with a custom DKIM domain or a return-path on your domain.
Check your addresses now
The free InkPigeon checker runs syntax, DNS, disposable, typo and role-account analysis on any address — instantly, no signup.