SPF, DKIM and DMARC Explained: A Pre-Send Authentication Checklist
By Eric Dieperink · Published September 18, 2026 · Last reviewed September 18, 2026
SPF says which servers may send for your domain, DKIM signs each message so it cannot be altered undetected, and DMARC tells receivers what to do when the first two fail, and sends you a report about it. They are three separate mechanisms that only work as a set, and both Google and Yahoo now require all three from bulk senders. This is the checklist to run before your next campaign, not after the first deliverability dip.
Key takeaways
SPF authorizes sending servers by IP, but only covers the SMTP envelope sender, and a domain may have only one SPF record.
DKIM cryptographically signs messages; the signature survives forwarding, which SPF does not.
DMARC aligns the From: domain with SPF/DKIM results and lets you set a policy: none, quarantine, or reject.
All three are checked by mailbox providers; Google and Yahoo require them for bulk senders, plus one-click unsubscribe and a spam rate below 0.3%.
Authentication proves the mail is really from you. It does not prove the content is wanted; that is what list hygiene is for.
What each mechanism actually checks
| Mechanism | RFC | What it verifies | Blind spot |
|---|---|---|---|
| SPF | RFC 7208 | The connecting server’s IP is authorized for the envelope sender’s domain | Breaks on forwarding; says nothing about the visible From: header |
| DKIM | RFC 6376 | A cryptographic signature over selected headers and the body, verified via a DNS public key | A valid signature only means the mail was not modified since signing, not that the sender is trustworthy |
| DMARC | RFC 7489 | That SPF or DKIM passes and aligns with the visible From: domain, plus reporting and a failure policy | Only as good as the SPF/DKIM underneath it |
The pre-send checklist
SPF
Find your current record: it is a TXT record at the domain root starting with v=spf1.
List every service that actually sends for you (ESP, CRM, helpdesk, billing) and include each with the right mechanism.
Check the 10-DNS-lookup limit: too many include: mechanisms make the record invalid. Flatten or consolidate if needed.
End with -all (hard fail) only when you are sure the list is complete; otherwise ~all (soft fail) is the safer intermediate step.
One SPF record per domain: duplicates are an error, and merging is required, not optional.
DKIM
Enable DKIM signing in your ESP and publish the public key it gives you as a TXT record.
Use a key of at least 1024 bits (2048 is the common recommendation today).
Rotate keys periodically. A key that never changes is a standing risk.
Send a test message to an inbox you control and verify the signature validates (view original / show headers).
DMARC
Publish a TXT record at _dmarc.yourdomain.com starting with v=DMARC1.
Start with p=none and rua= reporting, so you can observe legitimate mail flows before enforcing anything.
Read the aggregate reports until every legitimate source passes alignment; fix or remove the sources that fail.
Then tighten stepwise: p=quarantine (with pct if cautious), eventually p=reject.
Check the visible From: domain you actually send from. DMARC aligns against that, not against the return-path.
A note on order
The mechanisms only work as a set: DMARC without SPF/DKIM has nothing to align, and SPF/DKIM without DMARC leaves receivers guessing how strictly to treat failures. The practical order is SPF and DKIM first, then DMARC in monitor mode, then enforcement. Skipping the monitoring phase is the classic mistake. It is how legitimate mail ends up quarantined.
What authentication does not do
SPF, DKIM and DMARC answer “is this mail really from this domain, unmodified?”. They say nothing about whether the recipients wanted the mail. A perfectly authenticated campaign to a stale, uncleaned list will still generate bounces and complaints, and both mailbox providers weigh those heavily regardless of authentication. Authentication and list hygiene are complements, not substitutes; the hygiene side is covered in how to clean an email list.
Keep reading
How to clean an email list · Hard bounce vs soft bounce
Authentication plus a clean list
ListGuard handles the list side of deliverability: clean the file, remove bounces-in-waiting, keep your suppression matches out of every send. How we handle your data or create a free account.
Sources
RFC 7208: Sender Policy Framework (SPF) · RFC 6376: DomainKeys Identified Mail (DKIM) · RFC 7489: DMARC · Google: Email sender guidelines · Yahoo Sender Hub: Best practices