SPF, DKIM and DMARC, explained by what a receiver actually does

SPF, DKIM and DMARC are three DNS records that together let a receiving mail server decide whether a message really came from your domain. Here is SPF, DKIM and DMARC explained in the order a receiver applies them: SPF checks the connecting server’s IP address against a list you publish, DKIM checks a cryptographic signature carried inside the message, and DMARC checks whether either of those results belongs to the same domain your reader sees in the From header, then tells the receiver what to do when neither does.

Why there are three records and not one

Each record closes a hole the previous one leaves open. SPF authorises machines, so it says nothing about the content and breaks the moment a message is forwarded. DKIM authorises the message, so it survives forwarding, but it says nothing about which domain the reader sees. DMARC is the only one of the three that looks at the From header at all, and the only one that carries a policy telling the receiver to reject or quarantine anything.

Read alone, each is close to useless against spoofing. Read together, in that order, they are what every large mailbox provider now expects.

SPF: which servers may send for your domain

SPF is a TXT record at your domain root listing the hosts allowed to send mail for it:

example.com.  IN TXT  "v=spf1 include:_spf.example-esp.com ip4:203.0.113.7 ~all"

The critical detail: the receiver evaluates that record against the envelope sender, the address in the SMTP MAIL FROM command that ends up in Return-Path. That is not the From: address your reader sees. Someone spoofing you can put anything in From: and still collect an SPF pass on a domain they control.

Two operational traps. First, RFC 7208 limits evaluation to 10 DNS lookups, and every include: counts. Chain three providers together and you go over, which produces a permerror, not a pass. Second, ~all (softfail) and -all (hardfail) are treated very differently by receivers, and a record ending in ?all tells the world you do not care either way.

DKIM: a signature the message carries

DKIM signs selected headers plus the body with a private key and publishes the matching public key in DNS at <selector>._domainkey.<domain>. The receiver reads the DKIM-Signature header, fetches that key, and recomputes the hash.

Two tags in that header matter. d= is the signing domain, the identity DKIM actually asserts. s= is the selector, which is what lets you run several keys at once and rotate them without an outage. When you configure a new sending platform, the thing to verify is not “is DKIM on” but “what is in d=”. Plenty of platforms sign with their own domain by default, which passes DKIM and does nothing at all for you.

DMARC: alignment plus a policy

The DMARC record lives at _dmarc.example.com:

_dmarc.example.com.  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

DMARC passes when SPF or DKIM passes and the domain that passed is aligned with the domain in the From header. RFC 7489 calls this identifier alignment, and it is the entire point of the protocol. Relaxed alignment (the default) accepts an organisational domain match, so mail.example.com aligns with example.com. Strict alignment (aspf=s, adkim=s) demands an exact match.

The p= tag takes none, quarantine or reject. Deploy at p=none with an rua address, read the aggregate reports until every legitimate source is authenticating in alignment, then tighten. There is no prize for reaching reject early and a real cost for getting there blind.

The failure that catches everyone: an unaligned pass

The most common confusion in this area looks like a contradiction. The headers say spf=pass, the record is valid, and DMARC still fails.

What happened is that your provider used its own bounce domain in the Return-Path. SPF passed, correctly, for bounce.provider.net. Your From header says example.com. Those are different organisational domains, so DMARC discards the SPF result and falls back to DKIM. If the provider also signs with its own d=, there is nothing left to align and the message fails.

The fix is a DKIM key with d=example.com, or a custom Return-Path subdomain, or both. This is also why “we checked our DNS with an online tool” proves less than it seems: the tool sees your records, not the mail your application actually emits. That distinction is the one worth applying when you compare email testing tools by what they actually check, since a DNS lookup and a delivered message answer different questions.

Reading the verdict in Authentication-Results

The receiving server stamps its findings into a header:

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=bounce.provider.net;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

Trust only the header added by your own boundary. Anything stamped further upstream is unverified text and can be forged by whoever sent the message.

Test all three before your users do

Because this is a property of real received mail, the honest test is to receive real mail. An email testing API with SPF, DKIM and DMARC assertions hands you a disposable inbox, takes your application’s mail, and reports what the receiving hop concluded. Every message exposes authResults with a value for spf, dkim and dmarc, and you can assert on them directly:

const run = await client.assertEmail(inbox.id, [
  { type: 'auth', check: 'spf', expect: 'pass' },
  { type: 'auth', check: 'dkim', expect: 'pass' },
  { type: 'auth', check: 'dmarc', expect: 'pass' },
]);

console.log(run.passed, run.results);

If a mechanism produced no result at all, the assertion fails rather than quietly passing, which is what you want in CI: “no DKIM result” and “DKIM pass” are not the same finding. The same three checks run through the assert endpoint if you would rather call HTTP directly, and the WordPress deliverability test runs them against wp_mail output without any code at all.

Wire it into the suite that already covers your password reset flow. A signup mail that arrives fast, reads correctly and fails DMARC is still a broken mail. Catch it on the branch, not in a spam folder.