SPF, DKIM, and DMARC — How They Fit Together
These three protocols each do something different. SPF lists who can send. DKIM signs the message. DMARC ties both together and enforces a policy. You need all three working together to fully protect your domain.
Why they exist separately
Email was designed in an era that assumed senders were who they claimed to be. No authentication was built in. SPF, DKIM, and DMARC were each developed afterward to fill different gaps in that original design — which is why they're three separate standards rather than one.
SPF: who is allowed to send
SPF (Sender Policy Framework) is a DNS TXT record that lists every mail server authorized to send email for your domain. When a receiving server gets a message claiming to be from your domain, it checks the SPF record to see if the sending server is on the list.
What SPF does well: it's simple, widely supported, and easy to set up.
What SPF doesn't do: it checks the envelope sender (the Return-Path), not the visible From: address. It also breaks on email forwarding, because the forwarding server isn't on your approved list.
DKIM: a tamper-proof signature on the message
DKIM (DomainKeys Identified Mail) cryptographically signs outgoing messages. Your mail server adds a DKIM-Signature header containing a hash of parts of the message, signed with a private key. The corresponding public key lives in DNS.
When the receiving server gets the message, it fetches your public key, verifies the signature, and confirms the message wasn't altered in transit.
What DKIM does well: the signature travels with the message, so it survives forwarding. It also proves message integrity.
What DKIM doesn't do alone: a message can be DKIM-signed under a vendor's domain, not yours. The signature is valid, but it doesn't prove the message came from you specifically.
DMARC: alignment and enforcement
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the layer that ties SPF and DKIM together and adds enforcement. A DMARC record in DNS tells receiving servers two things:
- What policy to apply when a message fails authentication — do nothing, quarantine it, or reject it.
- Where to send reports about what they're seeing from your domain.
DMARC adds one critical check that neither SPF nor DKIM provides on its own: alignment. It verifies that the domain that passed SPF or DKIM is actually the same domain as the visible From: address. That's the check that blocks spoofing.
How a message passes DMARC
DMARC passes when at least one of these is true:
- SPF passes and the SPF-authenticated domain aligns with the
From:domain. - DKIM passes and the DKIM signing domain aligns with the
From:domain.
Failing both means DMARC fails, and your policy applies. Passing either one is sufficient.
The full picture
| Protocol | What it checks | Where it lives | Survives forwarding? |
|---|---|---|---|
| SPF | Is this server allowed to send for this domain? | DNS TXT on your domain | No |
| DKIM | Was this message signed by the domain it claims? | DNS TXT on your domain + signing key on mail server | Usually yes |
| DMARC | Does the authenticated domain match the From address? | DNS TXT at _dmarc.yourdomain.com | Depends on DKIM |
Why you need all three
SPF alone doesn't prevent spoofing of the visible From: address. DKIM alone doesn't prevent a vendor's domain from passing while impersonating yours. DMARC without SPF and DKIM has nothing to align against. Together, they close the gaps that each leaves individually.
Google and Yahoo now require all three for bulk senders. Even for low-volume domains, the combination protects your brand, your customers, and your deliverability.