SPF, DKIM and DMARC: how email authentication actually works

Almost every deliverability problem we get called about turns out, one layer down, to be an authentication problem wearing a different costume. Mail lands in spam, a provider defers a whole range, a report shows a stranger sending under your name — and the fix is nearly always the same three records, configured to agree with each other rather than merely to exist.

The three get lumped together because they travel together, but they answer different questions and fail in different ways. This is the practitioner's version: what each one is, what it actually proves, the failure mode we see most, and why a domain can pass SPF and DKIM and still get foldered because DMARC alignment quietly failed. We close with how we wire all three for the sending operations we run.

01What is SPF, and what does it prove?

SPF is a DNS record that lists which mail servers are allowed to send email for your domain. Sender Policy Framework lives in a single TXT record at your domain root; it names IP ranges directly with ip4 and ip6 mechanisms and pulls in third-party senders with include. When a receiver accepts a connection, it reads that record and checks whether the connecting server is on the list.

Two things trip people constantly. SPF authenticates the envelope-from domain — the hidden Return-Path address that bounces go to — not the From address your recipient actually reads, so SPF can pass while the visible sender is a stranger. And SPF breaks the moment a message is forwarded, because the forwarding server was never on your list. There is also a hard ceiling of ten DNS lookups; chain enough include statements and the record stops evaluating and returns permerror, which most receivers treat as no SPF at all.

02What is DKIM, and what does it prove?

DKIM is a cryptographic signature that lets a receiver confirm a message was authorised by a domain and has not been altered in transit. DomainKeys Identified Mail signs a set of headers and the body with a private key held on the sending server; you publish the matching public key in DNS under a named selector, and the receiver uses it to verify the signature. A valid signature proves two things at once: the signing domain vouched for the message, and nobody changed the signed parts along the way.

The failure we see most is a signing key that only reached some of the servers. Generate a keypair on one node, forget to ship it to the second node in the pool, and half your mail goes out signed with a selector the DNS has never heard of — the receiver looks it up, finds nothing, and treats the signature as broken. Body modification breaks it too: a mailing list that appends a footer changes the bytes DKIM signed, so the signature no longer verifies even though nothing malicious happened.

03What is DMARC, and what does it prove?

DMARC is a policy record that ties SPF and DKIM to the visible From address and tells receivers what to do when neither aligns with it. Domain-based Message Authentication, Reporting and Conformance lives in a TXT record at _dmarc.yourdomain and does two jobs: it publishes a policy — p=none, p=quarantine or p=reject — for mail that fails, and it asks receivers to send aggregate reports about everyone sending under your name.

The word that matters is alignment. DMARC does not re-run SPF and DKIM from scratch; it checks whether the domain those mechanisms authenticated matches the domain a human sees in the From header. SPF aligns when its envelope-from domain matches the From domain; DKIM aligns when its d= signing domain matches the From domain. DMARC passes when at least one of the two both passes and aligns. That link — from an authenticated domain to the visible one — is the entire reason DMARC exists, because SPF and DKIM on their own never look at the address your recipient reads.

04SPF vs DKIM vs DMARC: what each one covers

Here is the whole comparison on one screen. Read the third and fourth columns first — the failure modes and the alignment rules are where deliverability actually lives.

Put plainly: SPF and DKIM are the two ways to prove a message is authentic, and DMARC is the rule that says the proof has to be about the domain your recipient can see. A message can carry a perfectly valid signature and a passing SPF result and still fail DMARC, because both were true about someone else's domain.

05Why do SPF and DKIM pass but the mail still lands in spam?

This is the scenario that generates the most confused tickets: every check shows green, and the mail still goes to spam. SPF passed. DKIM passed. DMARC failed anyway — because passing is not the same as aligning.

Take the most common setup, sending through an email platform. SPF passes, because the envelope-from is the platform's own bounce domain and the platform's IPs sit in the platform's SPF record. DKIM passes, because the platform signs with its own d= domain. Both mechanisms are green. But both authenticated the platform's domain, and neither matches the yourdomain.com your recipient sees in From — so alignment fails on both, and a p=quarantine or p=reject policy does exactly what you told it to do.

The fix is to make one of the two align with your From domain. For SPF, that means a custom return-path: a subdomain of yours that points at the platform, so the envelope-from sits under your organisational domain and SPF alignment holds. For DKIM, it means the platform signs with a selector delegated under your domain, so d= reads your domain rather than theirs. You only need one of the two to align for DMARC to pass — but aligning both is what survives a forward, because forwarding breaks SPF and leaves DKIM carrying alignment alone.

One more distinction saves hours: strict versus relaxed alignment. Relaxed, the default, counts a match at the organisational domain, so mail.yourdomain.com aligns with yourdomain.com. Strict demands an exact match. Unless you have a specific reason, relaxed is the sane setting; strict alignment is a good way to fail your own subdomains.

06In what order should you deploy all three?

Authentication is not three switches you flip at once. There is an order, and skipping it is how people block their own mail on a Friday afternoon.

1. Publish SPF first. List every legitimate source, keep it under the ten-lookup limit, and end it with ~all (soft fail) before you tighten to -all.
2. Turn on DKIM and verify the public key resolves for every selector on every sending node — not just the one you tested from.
3. Publish DMARC at p=none with an rua reporting address. This blocks nothing; it only asks for data.
4. Read the aggregate reports for a week or two. Confirm that every legitimate stream — your platform, your helpdesk, your invoicing tool, your calendar invites — passes and aligns.
5. Move to p=quarantine, then to p=reject, once the reports are clean.

The reports at p=none are the point of the exercise. They name every source sending as your domain: the ones you forgot you had and the ones you never authorised. You do not tighten the policy until every legitimate source aligns, because p=reject on an incomplete picture blocks your own invoices, not just the spoofers. This step is no longer optional for anyone sending in volume — the Gmail and Yahoo bulk-sender rules now require a published DMARC policy outright.

07How we configure all three for the operations we run

For the sending operations we run — clients including EMG and Relentia — authentication is not a task someone does once and forgets. It is state the control plane holds and keeps true across every server in the fleet.

Mailflow, the platform behind that work, generates an OpenDKIM keypair per domain, publishes the selector record, writes the SPF record, and ships the private key to every node that will sign with it — in one operation, so the failure mode from section two, a key that reached one server and not the other, cannot happen. Reverse DNS and the matching forward record are set in the same pass, because a coherent identity across SPF, DKIM and rDNS is what receivers actually reward.

That is how it runs at EMG, whose sending infrastructure we have operated remotely since January 2025: Mailflow automates DKIM, SPF and reverse DNS across every server before a single message leaves. At Relentia, where we have run the sending since January 2024, the per-ISP reporting reads Gmail's SPF, DKIM and DMARC pass rates directly, so an alignment problem shows up as a number instead of a hunch. When we trained both teams on PowerMTA 5, diagnosing a signature the receiver distrusts — the section-five problem — became something the operator on shift reads from the per-domain authentication state, not a screenshot forwarded to us.

Get the three records right and aligned and you have removed the single most common reason good mail lands in spam. After that the work moves to the parts authentication does not cover: warming the IP that sends the mail and measuring where it actually lands rather than trusting a 250. Authentication is the price of entry. The inbox is everything after it.