SPF, DKIM, and DMARC Explained

If you send email and you have never touched your DNS records, your messages are probably landing in spam more often than they should. SPF, DKIM, and DMARC are the three records that tell receiving servers your mail is genuine. They are not optional anymore. Gmail and Yahoo now reject or junk a lot of unauthenticated mail outright, and every serious mailbox provider treats these checks as a baseline. Here is what each one actually does, in plain English, and how they work together.

The problem they solve

Email was built in the 1980s with no way to prove who sent a message. The "From" address is just text. Anyone can type your domain into it, the same way you can write any return address on a paper envelope. That is why phishing works. SPF, DKIM, and DMARC are three layers added on top of plain email to close that gap. Each answers a slightly different question, and you want all three.

• SPF asks: is this server allowed to send for this domain?
• DKIM asks: was this message actually signed by the domain, and was it tampered with on the way?
• DMARC asks: if the first two checks fail, what should I do, and who do I tell?

SPF: who is allowed to send

SPF (Sender Policy Framework) is a list. You publish a TXT record in your DNS that names every server allowed to send mail from your domain. When a receiving server gets your email, it checks the sending server's IP address against that list. On the list, SPF passes. Not on the list, SPF fails.

A simple SPF record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

That says: Google and SendGrid may send for me, and treat anything else as suspicious. The ~all at the end is a soft fail (mark it, don't reject); -all is a hard fail.

Two things trip people up. First, SPF has a hard limit of 10 DNS lookups. Stack too many include: statements and the whole record breaks silently. Second, SPF checks the hidden envelope sender (the return-path), not the visible "From" you see in your client. That gap is exactly why DMARC exists.

DKIM: a tamper-proof seal

DKIM (DomainKeys Identified Mail) is a cryptographic signature. Your sending server signs each message with a private key. You publish the matching public key in DNS. The receiving server uses that public key to verify the signature.

This proves two things at once. The mail genuinely came from your domain, and nothing in the signed parts (the headers and body) was changed in transit. If a forwarder or an attacker alters the content, the signature no longer matches and DKIM fails.

Unlike SPF, DKIM survives most forwarding, because the signature travels with the message rather than depending on which IP relayed it. That makes it the more durable of the two checks.

DMARC: the policy and the report

SPF and DKIM each produce a pass or fail, but on their own they do not say what a receiver should do with a failure, and they do not check the visible "From" address. DMARC ties the loose ends together.

DMARC does two jobs:

1. Alignment. It requires that the domain SPF or DKIM checked matches the domain in the visible "From" address. This is the piece that actually stops someone spoofing your "From" line.
2. Policy plus reporting. You tell receivers what to do when a message fails (none, quarantine, or reject), and you get daily reports showing who is sending under your name.

A starter DMARC record:

v=DMARC1; p=none; rua=mailto:[email protected]

Start with p=none so you only monitor. Read the reports for a few weeks, fix any legitimate sender that is failing, then tighten to quarantine and finally reject. A message passes DMARC if either SPF or DKIM passes and aligns, so you do not need both to pass every time, but you want both configured.

How they fit together

Record	Question it answers	Survives forwarding?
SPF	Is this server allowed to send?	Often no
DKIM	Is the message authentic and unchanged?	Usually yes
DMARC	What to do on failure, and does "From" align?	Depends on the two above

Think of it as identity (SPF), integrity (DKIM), and enforcement (DMARC). Skip any one and you leave a gap an attacker or a spam filter will find.

Why this matters for deliverability

Authentication is not just anti-fraud. It is now a ranking signal. Since 2024, Gmail and Yahoo require SPF, DKIM, and an aligned DMARC policy from anyone sending in volume, and they reject or junk mail that fails. Even at low volume, a clean trio of records is one of the cheapest deliverability wins available. It tells the mailbox provider you are a real, accountable sender rather than a drive-by spammer.

Authentication gets your mail accepted, but it does not fix a bad list. If you are sending to dead addresses and spam traps, you will still get throttled no matter how perfect your DNS is. Authentication and list quality work together. Clean your list, keep your records tight, and watch your bounce rate drop. For the wider picture, see our notes on improving email deliverability and steady email list hygiene. If you want to scrub a list before your next send, the free email verifier gives you 100 checks to start.

FAQ

Do I need all three records, or is one enough?

You need all three. SPF and DKIM each prove a different thing, and DMARC is the only one that protects your visible "From" address and tells receivers what to do on failure. Major providers now expect the full set from bulk senders, so one or two is no longer enough.

Will turning on DMARC break my email?

Not if you start with p=none. That mode only monitors and reports; it changes nothing about delivery. Watch the reports, fix any genuine sender that is failing alignment, then raise the policy to quarantine and reject in stages. Jumping straight to reject before checking reports is the one mistake that bites people.

How long do DNS changes take to apply?

Usually minutes to a couple of hours, occasionally up to 48 hours, depending on the TTL set on the record. Lower the TTL before a planned change if you want faster propagation, then raise it again once things are stable.