Field note · 2026-10-15 · DME Computer Services
SPF vs DKIM vs DMARC explained
Three different checks. SPF names the servers. DKIM signs the message. DMARC tells receivers whether either of those matches the address a person sees, and what to do if not.
People bundle the three names because a finished domain uses all of them. They answer different questions. Mixing them up is how a domain ends up with p=reject and a signature that still says d=vendor.com.
| SPF | DKIM | DMARC | |
|---|---|---|---|
| Question it answers | Is this server on the list of hosts allowed to send for the envelope domain? | Did this message get signed, and does the signature still match? | Does a passing SPF or DKIM domain match the From address, and what should a receiver do if not? |
| Where it lives | One TXT record on the domain, starting with v=spf1. | A TXT or CNAME at selector._domainkey, and a signature header on the message. | One TXT record at _dmarc. |
| What breaks it | Forwarding. The forwarder's server is not in your list. Also a second SPF record, or more than 10 DNS lookups. | A mailing list that rewrites the body, or a signature whose d= is the vendor, not you. | Publishing reject before the legitimate senders align. p=none, which asks for reports and does not ask for rejection. |
| Spec | RFC 7208 | RFC 6376 | RFC 7489 |
SPF is a list of servers
The receiver looks up the TXT record and checks the IP of the server that handed it the message. The domain it checks is the envelope sender, often called the Return-Path, not the From line in the mail client. RFC 7208 is the spec. One record. Two records are a permanent error. The mechanisms that trigger extra DNS lookups are capped at 10, including nested includes.
-all means hosts you did not list should fail. ~all is a soft fail, which many receivers file as spam rather than refuse. +all authorizes the rest of the internet. ?all tells receivers to stay neutral.
DKIM is a signature
The sending system signs selected headers and the body. The public key is in DNS under the selector name. RFC 6376 describes the signature. Forwarding does not break it, unless the forwarder changes the signed parts.
The tag DMARC cares about is d=. That is the domain that takes responsibility for the signature. If your newsletter tool signs as itself, DKIM can pass and still do nothing for your domain's DMARC.
DMARC is the policy and the reports
RFC 7489 says a message passes DMARC when either SPF or DKIM passes and is aligned with the From domain. Aligned, in the default relaxed mode, means the same organizational domain, so a subdomain can still count. Strict mode (aspf=s or adkim=s) requires an exact match.
The policy tag is p=. none asks for reports. quarantine asks receivers to treat failures as suspicious. reject asks them to refuse the message. Receivers are allowed to ignore the request. You still publish it, because the ones that honor it are the ones a spoof has to get past.
rua is where aggregate reports go. Those reports are how you see sources you did not know about. Without that address, monitor mode tells you nothing.
What a header line is telling you
Receivers add an Authentication-Results header. RFC 8601 defines it. You want the one your mail provider added, not a copy the sender put in the message. Look for spf=, dkim=, and dmarc=.
A useful combination on a message you sent yourself: spf=pass, dkim=pass with d= equal to your domain, and dmarc=pass. Anything else is a reason to read the setup note before you change a policy.
The order of work is in How to set up DMARC. How to read a suspicious message is in Is my email domain being spoofed?
Sources
Free check · nothing stored
See the records you have now
The checker reads MX, SPF, DMARC, and five common DKIM selectors once. It does not send a message, it does not read DMARC reports, and it does not keep the domain.
From the directory
Checkers and report readers from the directory. The free-tier note on each listing is dated from that vendor's page.
- CategoryDMARC, SPF, and DKIMTools that read DMARC reports or help you publish SPF, DKIM, and DMARC so other people cannot send mail as your domain.
- CategoryFree checkersTools with a check or a plan you can use without paying. Trials are not listed here unless a lasting free tier was on the vendor page.
- ToolMXToolboxPublic DNS and mail lookups, including MX records and blacklist checks.
- ToolEasyDMARCDMARC monitoring with public record checkers and printed prices for the paid plans.
- TooldmarcianDMARC deployment and monitoring, with a 30-day trial and a public domain check.
- ToolPostmark DMARCA free weekly DMARC email from Postmark, plus a paid digest at $14 a domain.
The other two notes
- How to set up DMARC (step by step)Publish one SPF record and DKIM first. Then a DMARC record at p=none, read the reports, and only then move to quarantine and reject.
- Is my email domain being spoofed? How to tellRead Authentication-Results on a real message and, if you asked for them, the DMARC reports. A DNS lookup alone does not prove an attack today.
Questions
Short answers to the questions this note is for. The paragraphs above are the longer version.
- Do I need all three?
- You want all three if the domain sends mail. SPF and DKIM are the checks. DMARC is the policy that ties a passing check to the From address people see, and it is how you get reports. DMARC can pass on either aligned SPF or aligned DKIM. Publishing only SPF leaves you exposed when mail is forwarded, because forwarding breaks SPF.
- Why can SPF pass and DMARC still fail?
- SPF checks the envelope sender, the Return-Path, not the From address in the message. Those can be different domains. DMARC fails the SPF result unless that authenticated domain aligns with the From domain. RFC 7489 section 3.1 is the rule.
- Why can DKIM pass and DMARC still fail?
- A signature can pass for the vendor's domain. DMARC looks at the d= domain in the DKIM signature. If that is not your From domain, and SPF is not aligned either, DMARC fails. The message was signed. It was not signed as you.
- Does any of this encrypt the message?
- No. SPF, DKIM, and DMARC are about who is allowed to send as the domain and what to do when that check fails. Encryption in transit is TLS. Encryption of the message body is a different system. Do not treat a DMARC pass as a private message.
- Where is the setup order?
- SPF, then DKIM, then DMARC at p=none, then quarantine, then reject. The step-by-step note on this site is How to set up DMARC.