SPF, DKIM, and DMARC Explained

Email was designed in an era when everyone on the network was trusted. The protocol that moves mail between servers, SMTP, will happily accept a message that claims to be from anyone. Nothing in the original design checks whether the sender is telling the truth about who they are. That gap is why phishing and spoofing work, and why every serious mailbox provider now leans on three add-on records to close it: SPF, DKIM, and DMARC.

People often treat these as interchangeable acronyms or three competing options. They are neither. They are three layers that do different jobs, and they only reach their full strength when all three are in place and pointing at each other. This guide explains what each one actually checks, and — the part most explainers skip — how alignment is the idea that turns them from three separate signals into a single, enforceable policy.

The problem all three solve#

When a mail server receives a message, it sees two different "from" values. There's the envelope sender (also called the return-path or MAIL FROM), used by servers to route bounces, and there's the header From — the friendly address a human reads in their inbox. A spammer can set both to anything. Without extra checks, a message can claim billing@yourbank.com while originating from a server that has no connection to that bank at all.

SPF, DKIM, and DMARC each attack a slice of that problem: SPF checks which servers are allowed to send, DKIM checks whether the message was altered and who signed it, and DMARC checks whether either of the first two lines up with the visible From address, and tells receivers what to do when they don't. Take them one at a time.

SPF: which servers may send for you#

Sender Policy Framework is a published list of the servers permitted to send email for your domain. You add a single TXT record to your DNS, and it looks something like this:

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

Read left to right, that says: Google Workspace and SendGrid are authorised senders, and anything else should be treated with suspicion (~all is a soft fail). When a receiving server gets a message, it looks at the envelope sender's domain, fetches that domain's SPF record, and asks a simple question: did this message arrive from one of the IP addresses this record blesses? If yes, SPF passes. If no, it fails.

SPF's main limitation is baked into how it works. It authorises servers, not messages, so it says nothing about whether the content was tampered with. It also breaks when mail is forwarded — the forwarding server isn't on your allow-list, so a legitimately forwarded message can fail SPF through no fault of yours. And there's a hard ceiling most people trip over eventually: an SPF record may trigger at most ten DNS lookups during evaluation. Chain together enough include: statements for various sending services and you blow past ten, at which point SPF returns a permerror and stops working entirely. A quick pass through our SPF checker counts those lookups for you and walks the whole include chain, which is the fastest way to catch a record that's quietly over the limit.

DKIM: a signature that travels with the message#

Where SPF vouches for the sending server, DomainKeys Identified Mail vouches for the message itself. When your mail server sends an email, it computes a cryptographic signature over the headers and body and attaches it as a DKIM-Signature header. The matching public key lives in your DNS, published at a location derived from a label called the selector — something like selector1._domainkey.yourdomain.com.

A receiving server pulls that public key, verifies the signature, and learns two things at once: the message wasn't modified in transit, and it was signed by someone holding the private key for your domain. Because the signature is carried inside the message, DKIM survives forwarding in a way SPF does not — the signature keeps verifying no matter how many hops the mail takes, as long as nothing rewrites the signed headers or body.

The details that matter in practice are key strength and rotation. A DKIM key should be at least 2048-bit RSA; older 1024-bit keys are considered weak. And because a private key that leaks lets an attacker sign as you, keys should be rotated periodically. Our DKIM lookup probes dozens of common selectors automatically and reports the key type and length, so you can confirm your published key is both present and strong without knowing the exact selector name in advance.

DMARC: the policy that ties it together#

SPF and DKIM each produce a pass or fail, but on their own they leave two questions unanswered. First: what should a receiver actually do with a failing message — junk it, reject it, or shrug? Second, and more subtly: a message can pass SPF or DKIM for some domain while still showing a forged address in the From line a human reads. Domain-based Message Authentication, Reporting and Conformance answers both.

A DMARC record is one more TXT entry, published at _dmarc.yourdomain.com:

v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com; adkim=s; aspf=s

The p= tag is the policy — what receivers should do with mail that fails DMARC. It has three settings, and they're meant to be climbed like a ladder:

• p=none — monitor only. Nothing is blocked; you just collect reports. This is where every domain should start, so you can see what's sending as you before you turn on enforcement.
• p=quarantine — failing mail goes to the spam folder. The intermediate step, once your reports show all your legitimate senders passing.
• p=reject — failing mail is refused outright at the server. The end goal: a forged message never reaches the inbox at all.

The rua= address is where receivers send daily aggregate reports — XML summaries of who's sending mail claiming to be you, and whether it passed. Those reports are the whole reason to move slowly: they turn "I think we set this up right" into a list of every source actually using your domain, including the forgotten marketing tool nobody remembered to authorise.

Alignment: the piece that makes DMARC matter#

Here's the concept that separates a domain with real protection from one that just has three records sitting in DNS. DMARC doesn't only ask "did SPF or DKIM pass?" It asks whether the domain that passed matches the domain in the From address the reader sees. That match is called alignment, and it's what closes the spoofing loophole.

Consider why it's needed. A spammer can register evil-sender.com, set up a perfectly valid SPF record and DKIM key for it, and send you mail that passes both checks — for evil-sender.com. If the From line still reads ceo@yourcompany.com, those passing checks are worthless without alignment, because they vouch for the attacker's domain, not yours. DMARC requires that the SPF-authenticated domain or the DKIM-signing domain line up with the visible From domain. A message passes DMARC only when at least one of the two both passes and aligns.

The aspf and adkim tags control how strict that match must be. In relaxed mode (the default), a subdomain counts as aligned with its parent — mail.yourcompany.com aligns with yourcompany.com. In strict mode (s), the domains must match exactly. Relaxed is the right default for most organisations; strict is for those who want to lock down subdomain use entirely.

How the three run on a single message#

Put together, here's the sequence a receiving server runs when your mail lands, in order:

• It reads the envelope sender, fetches your SPF record, and checks whether the sending IP is authorised. Pass or fail is recorded.
• It reads the DKIM-Signature header, fetches the public key at the selector, and verifies the signature. Pass or fail is recorded.
• It fetches your DMARC record and checks alignment: does a passing SPF or DKIM result belong to a domain that matches the From address?
• If neither passes-and-aligns, the receiver applies your DMARC policy — none, quarantine, or reject — and files an aggregate report to your rua address.

That's the full picture. SPF and DKIM are the evidence; DMARC is the judge that weighs the evidence against the name on the envelope and issues the verdict. Miss any one layer and the system has a gap: SPF alone breaks on forwarding, DKIM alone doesn't tell receivers what to do, and DMARC without aligned SPF or DKIM has nothing to enforce.

What to check on your own domain#

If you're setting this up or auditing what's already there, a short checklist covers the common failure modes:

• SPF exists and stays under ten lookups. Every sending service you use should be in the record, and the record shouldn't permerror. If you're building a fresh one, our SPF record generator keeps the syntax valid and the lookup count honest.
• DKIM is published and the key is 2048-bit. Confirm the selector your provider uses actually resolves, and that the key isn't a weak 1024-bit leftover.
• DMARC exists, and you're climbing toward enforcement. A record stuck at p=none for a year is monitoring nobody reads. Read the reports, then move to quarantine, then reject.
• Alignment actually holds. This is the one people miss — a domain can pass all three checks individually and still fail DMARC because the passing domain doesn't match the From address.

Rather than run four separate checks by hand, the domain health report pulls SPF, DKIM, DMARC, DNSSEC, SSL, and WHOIS into one view with an honest per-section status, which is the quickest way to see all three email records — and whether they agree — in a single pass.