SPF, DKIM and DMARC for founders
Three DNS records, in plain language. What each proves, what to set, and how to check it is actually working.
These three records answer one question for the receiving mail server: is this message really from who it claims to be? Without them, modern inbox providers filter you by default. With them, you are merely allowed to compete.
What each one actually does
| Record | What it proves | Minimum setup |
|---|---|---|
| SPF | These servers are allowed to send for my domain | One TXT record listing your sending service |
| DKIM | This message was not altered in transit, and it came from my domain | A key your email provider publishes for you |
| DMARC | Here is what to do when a message fails, and where to send reports | A TXT record at _dmarc, starting at p=none |
The setup, in order
1. SPF
A single TXT record on your domain listing every service allowed to send as you. Two rules people break: you may only have one SPF record per domain, and it may trigger at most 10 DNS lookups. Chaining several providers with include: statements blows past ten quietly, and then SPF fails without any obvious error.
2. DKIM
Your provider gives you a key to publish, usually at a named selector. The thing to check is alignment: the DKIM signing domain should match the domain in your From address. A message can pass DKIM and still fail DMARC if those differ.
3. DMARC
Start at p=none with a reporting address. That publishes a policy and starts the reports flowing without rejecting anything. Once reports show your legitimate mail passing consistently, tighten to p=quarantine, then p=reject. Going straight to reject before you understand your own mail flow is how founders accidentally block their own invoices.
How to test it properly
Trust the headers, not the badges. Send yourself a message and open the original: you want to see SPF pass, DKIM pass, and DMARC pass, with the DKIM domain aligned to your From domain.
Online checkers are useful but noisy. Most red crosses are the tool guessing a default DKIM selector that is not yours, or flagging that your DMARC is p=none rather than reject. Neither of those stops you launching. The received headers are the source of truth.
The failures that bite quietly
- Two SPF records. Common after adding a second provider. Both become invalid; merge into one.
- Over 10 SPF lookups. Silent failure, no error anywhere.
- Unaligned DKIM. Signing domain does not match the From domain, so DMARC fails despite DKIM passing.
- DMARC left at p=none forever. Fine to launch on, but you are publishing a policy of "do nothing", which offers no protection against spoofing.
- Authenticating only the primary domain. Every cousin sending domain needs its own three records.
Perspective: authentication gets you to the starting line, not the finish. A perfectly authenticated domain still lands in spam if you send unverified lists at high volume. Records first, then behaviour.
- SPF authorises senders, DKIM proves integrity and origin, DMARC sets policy and reporting.
- One SPF record per domain, maximum 10 DNS lookups.
- DKIM must be aligned with the From domain or DMARC fails anyway.
- Start DMARC at p=none, tighten to quarantine then reject once reports are clean.
- Real message headers are the source of truth, not third-party badge checkers.
Frequently asked questions
Do I really need all three records?
Yes. Google and Microsoft both enforce authentication for bulk senders, and unauthenticated cold email is filtered by default. It is three DNS records; there is no case for skipping them.
Why do online checkers show a red X when my headers say pass?
Almost always because the tool is checking a default DKIM selector that is not yours, or flagging that DMARC is set to p=none rather than reject. Trust the received headers on a real message.
What should my DMARC policy be?
Start at p=none with a reporting address so you can see your own mail flow. Move to p=quarantine once reports are clean, then p=reject. Jumping straight to reject risks blocking your own legitimate mail.
Do I need separate records for my cold email domain?
Yes. Every sending domain needs its own SPF, DKIM and DMARC. This is one reason cold outreach belongs on cousin domains rather than your primary.