SPF, DKIM and DMARC explained without the jargon

Every guide to email authentication says the same three sentences: SPF lists your senders, DKIM signs your mail, DMARC ties them together. Then you go to fix something and none of it helps, because the part that decides whether your mail passes is the part those sentences leave out.

Here is the full model.

SPF: which servers may send as you

SPF is a TXT record on your domain listing the IP addresses and services allowed to send mail using it.

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

A receiver takes the IP that connected to it, looks up your SPF record, and asks: is this IP in the list? The answer is pass, fail, softfail, or an error.

Three things routinely go wrong:

The ten-lookup limit. Every include:, a, mx, ptr and redirect in your record costs a DNS lookup, and so does everything those includes pull in behind them. Past ten, evaluation stops with a permanent error and SPF fails for every message you send — with a record that looks perfectly fine to the eye. This is the single most common silent SPF failure, and it is why our DNS checker actually counts them rather than just reading the syntax.

+all. This says "any server on the internet may send as this domain". It is the opposite of the record's purpose. It appears surprisingly often, usually pasted from a support article.

Which domain SPF actually checks. SPF validates the envelope sender (the MAIL FROM, also called the Return-Path), not the From address your recipient sees. Those are frequently different domains — most ESPs use their own bounce domain. Your SPF can pass perfectly while the From address is completely unrelated to the domain that passed. Which brings us to the part that matters.

DKIM: a signature on the message itself

Your sending server signs each outgoing message with a private key and adds a DKIM-Signature header. The matching public key is published in DNS at <selector>._domainkey.yourdomain.com. The receiver fetches the key, verifies the signature, and now knows two things: which domain claimed responsibility, and that the signed parts of the message were not modified in transit.

The selector is an arbitrary name chosen by whoever generated the key — google, selector1, k1, s1024, mandrill. DNS gives no way to list a domain's selectors, which is why a checker cannot definitively tell you that you have no DKIM. It can only tell you that none of the selectors it tried answered. (We probe more than fifty that real providers use, and you can type your own.)

Unlike SPF, DKIM survives forwarding — the signature travels with the message. That property is why DKIM is the one to get right if you can only get one right.

DMARC: the policy, and the reason the other two are not enough

DMARC does two jobs.

The first is a published policy at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1

p= is what receivers should do with mail that fails: none (deliver anyway, just tell me), quarantine (spam folder) or reject (refuse it). rua= is where the daily aggregate reports go.

The second job is the one that makes DMARC more than a summary of the other two: alignment.

Alignment, the part everyone skips

DMARC does not ask "did SPF pass?". It asks: did SPF pass for a domain that matches the From address the human sees?

That means a message passes DMARC if either:

• SPF passes and the MAIL FROM domain aligns with the From domain, or
• DKIM verifies and the signing domain (d=) aligns with the From domain.

"Aligns" means the same organisational domain by default (relaxed), so mail.example.com aligns with example.com. Set aspf=s or adkim=s and it must be an exact match.

This is why a message can show SPF: pass in its headers and still fail DMARC. The ESP's bounce domain passed SPF; your From domain was never checked by it. Nothing is broken — it is working exactly as specified, and the fix is to get DKIM signing with your own domain rather than the ESP's.

Once you internalise alignment, most confusing authentication results explain themselves.

The records to publish

SPF — one record, at the domain root, listing every service that sends as you, ending in ~all or -all:

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

Never publish two SPF records. Two records is a permanent error, not a merge.

DKIM — turn signing on at each sending service, then publish the key it gives you at the selector it names. Paste the key as one value and let your DNS provider split it; a 2048-bit key does not fit in a single 255-byte DNS string, and one split by hand in the wrong place is the classic reason a published key never verifies.

DMARC — start here, and only here:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1

p=none changes nothing about how your mail is delivered. It only asks for reports. Read them for a few weeks, find the systems sending as you that you had forgotten about, fix their authentication, and then tighten the policy. We wrote a full rollout guide for that part, and built a DMARC fixer that reads your current record, tells you exactly what is wrong with it, and generates each stage of the rollout for you.

How to verify all three

Records being present is not the same as authentication passing. Check both halves:

1. The DNS checker reads what is published and grades it — no signup, no sending.
2. The deliverability test scores a real message you send, so you can see SPF evaluated from your actual sending IP, your DKIM signature verified, and DMARC alignment resolved the way a receiver resolves it.

The first tells you the records are right. Only the second tells you your mail passes.