All posts
June 8, 20266 min read

SPF, DKIM, and DMARC explained: the three records that keep your email out of spam

If mail from your domain lands in spam, or worse, gets dropped silently, three DNS records are almost always the reason: SPF, DKIM, and DMARC. They are not interchangeable. Each proves a different thing, and mailbox providers want all three before they trust you.

What each record proves

SPF (Sender Policy Framework) is a list of the servers allowed to send mail for your domain. It lives in a TXT record and looks like v=spf1 include:_spf.google.com ~all. When a receiving server gets a message, it checks whether the connecting server is on your list. SPF authenticates the envelope sender, not the visible From address, which is why it is necessary but not sufficient on its own. Build one with the SPF Generator.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every message. Your mail server signs outgoing mail with a private key; the matching public key sits in a DNS TXT record under a selector like selector._domainkey.example.com. The receiver verifies the signature, which proves the message was not altered in transit and really came from your domain. Set up the published record with the DKIM Generator.

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties the other two together. It tells receivers what to do when a message fails SPF or DKIM, and where to send reports. A policy looks like v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com. Crucially, DMARC checks alignment: the domain that passed SPF or DKIM must match the visible From domain. That alignment is what actually stops spoofing. Generate a policy with the DMARC Generator.

The order to set them up

  1. Publish SPF first. List every service that sends mail as you: your mail host, your marketing platform, your ticketing system. Missing one means its mail fails.
  2. Add DKIM next. Turn on signing in your mail platform and publish the public key it gives you.
  3. Start DMARC at p=none. This monitors without affecting delivery. Read the aggregate reports for a week or two to confirm your real mail passes.
  4. Move to p=quarantine, then p=reject. Only tighten the policy once the reports show legitimate mail is aligned. Jumping straight to reject can blackhole your own newsletters.

Debugging delivery problems

Most "email goes to spam" issues trace back to one of these records being missing, malformed, or out of alignment. Check what is actually published for a domain with the MX Lookup tool, and run a full pass with the Email Health checker, which inspects MX, SPF, DKIM, and DMARC together. If you want the wider picture of how these records sit alongside A, CNAME, and NS records, see DNS records explained.

Authentication is the price of the inbox now. Set up all three, watch the reports, and tighten the policy only when the data says it is safe.