Guides

SPF, DKIM and DMARC: three records, one decision

Last updated 2026-09-10

SPF says which servers may send mail for your domain. DKIM puts a signature on each message so the receiver can check nothing changed on the way. DMARC is the third one, and it's different in kind. It's the only one that tells the receiver what to do.

SPF and DKIM each produce an answer, pass or fail. On their own those answers go into a header and nothing happens. DMARC turns them into a decision, and it adds the rule that makes the decision mean something: the domain that passed has to be the domain the reader sees.

Do I need all three? Yes. Google and Yahoo require SPF and DKIM and DMARC from bulk senders, and everyone else gets one free pass at most before forwarding or a mailing list breaks it.

Set them up in this order

1. List every service that sends mail with your domain in the From address. Your mail platform, your CRM, your invoicing tool, the website's contact form, the newsletter tool. This list is always longer than you think.
2. Publish one SPF record at your domain that includes each of them. SPF record syntax has the shape, and the record has to stay under ten DNS lookups.
3. Turn on DKIM in each service and publish the record it gives you. Make sure it signs with your domain, not its own.
4. Publish a DMARC record at p=none with a rua= address. Nothing changes for your mail yet. Reports start arriving.
5. Read the reports for a few weeks. Fix whatever they show failing. Then move to p=quarantine, then p=reject. DMARC setup is the long version.

SPF: a list of servers, checked against the return path

SPF is a TXT record at your domain listing the servers allowed to send for it:

When a server connects to deliver a message, the receiver looks at the domain in the return path, the address bounces would go to, and fetches that domain's SPF record. If the connecting IP is in the record, SPF passes. The ~all at the end says what to do with an IP that isn't: soft fail. -all says hard fail.

Two things to know about it. The return path domain is often not your domain. A sending service usually puts its own domain there so it can collect the bounces, and then SPF passes for the service's domain, which does you no good under DMARC. And SPF breaks on forwarding. When a message is forwarded, the forwarding server's IP is the one connecting, and it isn't in your record.

DKIM: a signature, checked against a key in DNS

DKIM adds a header to each message with a signature over the body and the important headers, made with a private key the sending service holds. The header says which domain signed and which selector to look up:

The receiver fetches the public key from google._domainkey.example.com and checks the signature. If it verifies, DKIM passes for example.com. The IP that delivered the message doesn't matter, so DKIM survives forwarding. What it doesn't survive is edits. A mailing list that adds a footer or rewrites the subject breaks the signature.

Watch the d= tag. Many services sign by default with their own domain, and that passes DKIM without helping you. Each one has a setting to sign with yours, and it hands you a CNAME or TXT record to publish when you turn it on.

DMARC: the rule that uses both

DMARC is a TXT record at _dmarc under your domain:

The receiver runs SPF and DKIM as above, then applies DMARC's one rule. The message passes DMARC if SPF passed for a domain that matches the From header, or DKIM passed for a domain that matches the From header. If neither, the message fails, and p= says what happens to it. none delivers it as normal. quarantine sends it to spam. reject refuses it.

The rua= address is where receivers send a daily report of every server that sent as your domain and how each one did. It's the only feedback you get, and it's how you find the senders you forgot before you set the policy to reject. What is DMARC goes deeper on the record itself.

Alignment is where the three meet

Every message carries three domains. The return path domain, which SPF checks. The d= domain, which DKIM checks. And the From header domain, which the reader sees and which neither SPF nor DKIM looks at. DMARC's rule is that one of the first two has to match the third. That match is called alignment.

A worked example. You send a newsletter through a service. The return path is bounces.service.com, so SPF passes for service.com. You turned on DKIM, so the signature says d=example.com. The From is news@example.com.

Check	Domain it passed for	Matches From?
SPF	service.com	No
DKIM	example.com	Yes
DMARC	Pass, on DKIM

Turn DKIM off and the same message fails DMARC, even though SPF passed. That's the case that surprises people: both checks green, DMARC red, because the green ones were for the wrong domain. DMARC alignment covers the relaxed and strict modes and the subdomain cases.

Which one fails when

	SPF	DKIM	DMARC
Checks	The connecting IP against a list	A signature against a key	Whether either passed for the From domain
Domain used	Return path	d= tag	From header
Breaks on	Forwarding	Edits in transit, mailing lists	Both failing, or neither aligned
On failure	A header note	A header note	Whatever p= says
Reports	None	None	Daily, to rua=

Read across the breaks-on row and the reason for all three is there. SPF and DKIM fail in different situations, so having both means a forwarded message still passes on DKIM and a mailing-list message still passes on SPF, sometimes. DMARC needs only one of them.

Reading the result in a header

Every receiver writes its verdict into the delivered message. Open a message you sent to yourself, view the headers, and find the line starting Authentication-Results:

Three results, three domains, and the last line is the one that decided anything. Compare the domain after smtp.mailfrom and the one after header.i with the one after header.from, and you can see which check aligned.

The reports are where you find out

Headers show one message. The rua= reports show every one: each server that sent as your domain, the SPF and DKIM result for it, whether it aligned, and what the receiver did. That's where the forgotten invoicing tool turns up, failing quietly, before you set p=reject and it starts bouncing. Our weekly digest reads those reports and lists each sender and its result, and on a paid plan we email you the day an unfamiliar sender first fails. Your first domain is free.

DomainCanary is a DMARC monitoring service that protects your domain from email spoofing without blocking your own mail.