SPF, DKIM and DMARC explained without the jargon
The three DNS records behind email authentication, what each one actually proves, and how they work together to stop people forging your domain.
Three DNS records decide whether the rest of the internet trusts email that claims to be from your domain. SPF and DKIM each check one thing. DMARC ties them together, sets the rule for what happens on a failure, and sends you reports. Here is what each one does, in plain language.
The problem all three are solving
Plain email lets anyone write your address in the From line. The receiving mail server has no built-in way to know whether a message really came from you or from a scammer sitting on a server in another country. These three records give receivers something to check.
DNS is the public address book for your domain. Anyone can look up what you publish there, which is exactly the point: you publish proof, and receiving servers read it.
An analogy runs through all three. Picture a private event where staff on the door have to decide who gets in.
SPF: the approved-sender guest list
SPF stands for Sender Policy Framework. It is a list, published in DNS, of the mail servers allowed to send email for your domain. When a message arrives, the receiver looks at which server actually delivered it and checks whether that server is on your list.
In the analogy, SPF is the guest list at the door. If the server that turned up is named on the list, SPF passes. If it is not, SPF fails.
An SPF record is a single line that looks like v=spf1 include:_spf.google.com include:sendgrid.net -all. Each include pulls in the servers of a provider you use, and the -all at the end means “nobody else”. There is a catch worth knowing early: SPF is limited to 10 DNS lookups. Stack up too many providers and the record quietly breaks, so it needs tidying rather than endless growth.
The important limitation: SPF only checks the delivering server. It says nothing about whether the message was tampered with, and it breaks the moment mail is forwarded, because the forwarding server is not on your list.
DKIM: the tamper-proof wax seal
DKIM stands for DomainKeys Identified Mail. When your mail server sends a message, it adds a cryptographic signature using a private key that only you hold. You publish the matching public key in DNS. The receiver uses that public key to check the signature.
DKIM is the wax seal on a letter. The seal proves two things at once: the letter came from someone holding your seal, and nobody broke it open and changed the contents on the way. If a single character of the signed message is altered in transit, the signature no longer matches and DKIM fails.
The signature carries a tag written as d=yourdomain.com, which names the domain that signed the message. Remember that tag, because it matters for the third record. Unlike SPF, DKIM usually survives forwarding, since the signature travels with the message rather than depending on which server relayed it.
The limitation here mirrors SPF’s: DKIM proves a valid signature exists, but on its own it does not tell the receiver what to do if the signature is missing or broken.
DMARC: the instruction and the reporting
SPF and DKIM are both checks. Neither one, by itself, tells a receiver to act. A message can fail both and still land in the inbox, because nothing instructed the receiver otherwise. That gap is what DMARC fills.
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It does three jobs:
- It sets the rule. A
p=tag tells receivers how to treat mail that claims to be from you but fails the checks:p=nonechanges nothing and just monitors,p=quarantinesends failing mail to spam, andp=rejectrefuses it outright. Only quarantine and reject actually stop impersonation. - It requires alignment. This is the piece people miss. It is not enough for SPF or DKIM to pass for some domain. The domain that passed has to match the domain your reader sees in the From line. We cover this in detail in what DMARC alignment really means, and it is the single most common reason a domain “has all three records” but still lets mail through that should be blocked.
- It reports. Your DMARC record includes a
rua=mailto:...address, and receiving providers send you daily summaries of every message that claimed to be from your domain, whether it passed or failed. That is how you see forgeries, and how you spot your own systems that are not yet authenticated properly.
In the door analogy, DMARC is the written instruction handed to the staff: “check the guest list and the seal, and if the name on the invitation does not match either one, turn them away, then send me a log of everyone who tried.”
How they combine
A message from a scammer on their own server cannot appear on your SPF list, and they cannot forge your DKIM seal. So both checks fail, alignment fails, and if your DMARC policy is p=reject, the receiver throws the message away before it reaches anyone. A genuine message from your properly configured mail system passes at least one check with alignment intact, so it goes through.
The order matters. Publishing DMARC at p=none first lets you read the reports and confirm your real mail is authenticating before you turn on enforcement. Move to p=reject too early, before your newsletters, invoicing tools and booking systems are lined up, and you can block your own mail.
Where to start
If you want to see what your domain publishes today and whether it is actually protected, run the free DMARC checker. It analyzes your live records and tells you in plain terms where you stand. For the full picture of how the standard works, read what is DMARC. The three records are simpler than the acronyms suggest: a list, a seal, and an instruction with a paper trail.