DKIM SPF DMARC explained: the three records that decide whether your mail arrives

Email authentication is the set of DNS records that let a receiving server decide whether a message claiming to come from your domain really did. There are three of them, they were designed at different times to solve different halves of the problem, and they only work as a set. Here is DKIM SPF DMARC explained in one paragraph each, before the detail.

• SPF is a list of who may send. You publish the servers allowed to send mail for your domain, and a receiver checks the connecting server against that list.
• DKIM is a signature. Your sending service signs each message with a private key and publishes the public half in DNS, so a receiver can check that the message it is holding is the one that was signed.
• DMARC is the policy and the feedback loop. It says what a receiver should do when neither check passes in a way that lines up with your From address, and it asks receivers to report what they saw.

None of the three says a message is wanted. They say it is not forged. That is the floor rather than the ceiling, and the deliverability guide covers what decides placement once you are over it.

An SPF record is a single TXT record at your domain listing the sources permitted to send mail for it. A receiving server takes the domain from the envelope sender, looks up that record, and checks the connecting IP address against it.

acme.example.        TXT   "v=spf1 include:_spf.example.net -all"

The terms are read left to right. include: pulls in another domain’s record, which is how you authorise a sending service without knowing its addresses. The last term is the catch-all: -all means anything not matched so far fails, and ~all means it soft-fails. Prefer -all once you are confident the record is complete, because a soft fail is an instruction to accept the message anyway.

DKIM puts a cryptographic signature in the message headers. Your sending service holds a private key; the public half lives in a TXT record under a selector, which is just a label so that a domain can hold several keys at once. Every domain you add to Rasket gets its own 2048-bit key, published under the rasket selector.

rasket._domainkey.acme.example.   TXT   "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQ..."

The signature itself rides along with the message. It names the domain, the selector and the headers it covers, plus a hash of the body.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;  d=acme.example; s=rasket; h=from:to:subject:date:message-id;  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;  b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSb...

A receiver reads d= and s=, fetches the public key at selector._domainkey.domain, recomputes the hashes over the signed headers and the body, and compares. If they agree, the message arrived exactly as it was signed, by somebody holding your key. Because none of that depends on who is connecting, a DKIM signature usually survives a forwarding hop that SPF does not.

Publish 2048 bits. RFC 8301 raised the floor from 1024, and the only practical cost is that the value is long enough that some DNS panels split it into two quoted strings, which is normal and resolves correctly. Rotating a key means publishing a second record under a new selector, signing with it, and removing the old record once nothing still in flight refers to it.

SPF and DKIM each produce a result. Neither says what a receiver should do with it, and neither tells you what happened. A DMARC policy is the record that does both.

_dmarc.acme.example.   TXT   "v=DMARC1; p=none; rua=mailto:dmarc@acme.example; adkim=s; aspf=s"

rua is where aggregate reports are sent: a daily XML summary from each receiver saying how much mail it saw claiming your domain, from where, and whether it passed. Those reports are the entire value of p=none. Reading them by hand is unpleasant, and several services will parse them for you, but do read them — the usual discovery is a marketing tool or an old invoicing system nobody remembered was sending as you.

pct lets you apply a policy to a fraction of your mail, which is a gentler way into quarantine than switching everything at once. And a subdomain policy tag lets a strict parent domain coexist with a subdomain you are still working on.

This is the concept that makes DMARC more than a wrapper. A DMARC pass needs SPF or DKIM to pass and the domain that passed to line up with the domain in the visible From header. A message can pass SPF perfectly and still fail DMARC, because the domain that passed was the sending service’s rather than yours.

• SPF alignment compares the envelope sender’s domain with the From domain. This is why a sending service gives you a return path on your own subdomain rather than using its own: without it, SPF passes and aligns with nothing.
• DKIM alignment compares the d= domain in the signature with the From domain. Signing with your domain rather than the service’s is what makes this work.

Strict mode (adkim=s, aspf=s) requires an exact match; relaxed mode, the default, accepts a subdomain of the same organisational domain. Relaxed is the right starting point, because it lets send.acme.example align with acme.example and that is the shape most senders actually have. Only one of the two has to align for DMARC to pass, which is why publishing both records is worth the effort: each covers a case the other loses.

This stopped being optional. Google’s sender guidelines require authentication for everybody who sends to Gmail, with more asked of bulk senders: SPF and DKIM on the sending domain, a DMARC record on the organisational domain, alignment on at least one of the two, a valid forward and reverse DNS record for the sending host, TLS in transit, and one-click unsubscribe on subscribed mail. Microsoft publishes its own requirements for senders to Outlook.com along similar lines.

Two consequences follow for anyone building a product that sends. First, there is no volume small enough to skip this: the baseline applies to every sender, and the extra requirements start at a threshold a growing product will cross without noticing. Second, the requirements are checked continuously rather than once, so a record that gets dropped during a DNS migration is a deliverability incident rather than a tidy-up task.

Adding a domain generates the set it needs: the DKIM key to publish as TXT, and the two records at the sending subdomain that give it its own return path — which is what makes SPF align and what makes bounces come back to us rather than to your mail server. Each record is checked as soon as you add the domain and re-checked on a schedule, so nothing has to poll, and a record that verified and later stopped resolving is reported as drifted rather than quietly ignored.

DMARC is the one record nobody generates for you, and that is deliberate: it is a policy about your whole domain, not about one sending service, and publishing it on your behalf would be making a decision that is yours. Add it yourself at p=none, read the reports, and tighten from there.

One warning if your domain already publishes a strict policy: publish the new records and let verification pass before you start sending from it, or mail can be rejected in the window where the records exist but alignment does not. The domain verification walkthrough has the step-by-step, including the panel behaviour that catches nearly everybody, and the domains reference documents every field the API returns for a record.