SPF, DKIM, and DMARC explained (with the alignment rule everyone misses)

SPF publishes a list of servers authorised to send mail on behalf of a domain. When a receiving server accepts a connection, it takes the domain from the SMTP envelope sender — the MAIL FROM address, also called the return path — looks up that domain’s SPF record, and checks whether the connecting IP is authorised.

The critical detail is that this is the envelope sender, not the From: header the recipient sees. Those are usually different. Most email providers rewrite the return path to their own bounce-handling domain so that bounces come back to them, which means SPF authenticates the provider’s domain, not yours — and that is exactly why SPF alone cannot satisfy DMARC.

DKIM attaches a cryptographic signature to each message. The sending server hashes a canonicalised copy of the body and a chosen set of headers, signs the hash with a private key, and adds a DKIM-Signature header. The receiver fetches the corresponding public key from DNS and verifies.

Because the signature travels inside the message, DKIM usually survives forwarding and mailing lists in a way SPF does not — a forwarded message arrives from a different IP, which breaks SPF, but the signature still verifies as long as the signed content was not modified. That durability is why DKIM is the identifier reputation systems lean on.

Selectors are what make key rotation practical. Because the record name includes the selector, you can publish a second key under a new selector, switch signing to it, and remove the old record once no in-flight mail depends on it — all without a window where verification fails.

Use at least a 1024-bit RSA key; Yahoo requires that as a minimum and 2048-bit is the recommended default for new deployments. The constraint on longer keys is historical DNS TXT record limits rather than anything cryptographic, and modern providers handle 2048-bit keys without difficulty.

SPF and DKIM each authenticate a domain, but neither is required to be the domain the recipient sees. A spammer can pass both while displaying your brand in the From: header — authenticating their own domain perfectly while impersonating yours.

DMARC closes that gap with one rule: authentication only counts if the authenticated domain aligns with the domain in the From: header. It then lets the domain owner publish what receivers should do when nothing aligns, and asks receivers to report back on what they saw.

This is the concept that breaks otherwise-correct configurations, so it is worth stating exactly. DMARC passes if either of these is true:

Under relaxed alignment, "aligns" means the two share an organisational domain — mail.yourdomain.com aligns with yourdomain.com. Under strict alignment, they must match exactly.

Now consider the common setup. Your From: is noreply@yourdomain.com. Your provider rewrites the return path to bounces@provider.example, so SPF passes for provider.example — which does not align. If DKIM signs with the provider’s domain rather than yours, that does not align either. Both checks pass individually, DMARC fails, and the sender is left insisting their SPF is correct. It is. It simply is not aligned.

Publishing p=reject on day one is the fastest way to discover, painfully, that your billing system sends from an unauthenticated source nobody remembered. The rollout exists to find those before they start failing.

BIMI is worth a specific note because it is frequently sold as a deliverability feature. It is not — it does not improve placement. What it does is display your brand logo beside authenticated messages in supporting clients, which is a recognition and anti-phishing benefit rather than a filtering one. It also requires DMARC at enforcement, which means the work it depends on is the work that actually helps.

It is worth being precise about what passing all three checks actually buys you, because the gap between the common expectation and the reality is where a lot of wasted debugging happens. SPF, DKIM, and DMARC establish who a message is from. They say nothing about whether that sender is worth trusting. A phishing campaign operated from a domain the attacker genuinely controls can pass SPF, DKIM, and DMARC with full alignment — that is not a flaw in the standards, it is the point of them. They make identity reliable so that reputation can be attached to something stable.

Which means authentication is a gate, not a score. Failing it gets you filtered regardless of everything else, so it is genuinely non-negotiable, and since Gmail and Yahoo began enforcing bulk sender requirements in February 2024 and Microsoft followed in May 2025, it is enforced rather than merely advisable. But passing it only earns you the right to be evaluated on the thing that actually decides placement: the sending history attached to your domain and to the IP addresses your mail leaves from.

Adding a sending domain generates the full record set: an ownership TXT record, a DKIM public key under a selector on your domain, a return-path CNAME so SPF aligns with your From: header, the SPF include, and a starter DMARC record. Signing happens under your domain rather than ours, so DKIM alignment works from the first message.

That covers the identity half. The reputation half is the infrastructure the mail leaves from, and it is the part you cannot fix with a DNS record — which is why we operate our own mail servers rather than reselling someone else’s. Production sending runs on a network that carries paying transactional customers only, with no free tier, no marketing blasts, and no cold outbound sharing your IP ranges. When isolation matters more than that, Dedicated gives you your own mail servers and addresses, which we provision, warm through the full ramp, and manage — so both halves of the problem are handled before your first production send.