What SPF, DKIM, and DMARC actually do
Think of the three as one chain with three links. SPF authorizes the servers allowed to send for your domain. DKIM attaches a cryptographic signature so a receiver can tell the message was not altered on the way. DMARC ties both back to the domain a reader actually sees in the From: line and publishes a policy for what to do when the check fails. Put plainly: SPF checks the envelope, DKIM checks the content, and DMARC checks that either one lines up with the name your recipient reads.
SPF: which servers may send for your domain
An SPF record is a single DNS TXT entry that starts with v=spf1 and lists the hosts and includes allowed to send for the domain, ending in an all mechanism. Two rules catch people out. First, a domain may publish only one v=spf1 record; a second one makes evaluation return permerror and authentication effectively fails (RFC 7208, section 4.5). Second, SPF may perform at most ten DNS-lookup mechanisms — include, a, mx, ptr, exists, and the redirect modifier — during evaluation; exceed ten and the result is again permerror (section 4.6.4). The final qualifier is the policy: ~all is a softfail (accept but mark), -all is a hardfail (reject unlisted senders), and +all would pass everything, which is why you never publish it. One structural limit to know: SPF authenticates the hidden Return-Path domain, not the visible From:, and it breaks on forwarding, because the forwarding server's IP is not in your record — which is exactly why DMARC does not rely on SPF alone.
DKIM: a signature nothing can quietly change
DKIM signs each outgoing message with a private key held by your sending system and publishes the matching public key in DNS. The signature covers chosen headers and the body, so if anything is altered in transit the signature no longer validates. Receivers find the key using a selector: a DKIM-Signature header carries s= (the selector) and d= (your domain), and the verifier queries selector._domainkey.yourdomain for the public key (RFC 6376, section 3.6.2.1). Selectors also let you run several keys at once, which is what makes rotation clean — publish a new selector, move signing to it, then retire the old one (an empty key value marks it revoked). On key length, RFC 6376 requires at least 1024-bit RSA keys for long-lived use and verifiers must handle keys up to 2048 bits; 2048-bit is the sensible modern default, and rotating keys periodically limits the damage if one ever leaks.
DMARC: the policy that ties it together
DMARC is the record that makes SPF and DKIM mean something for the domain your recipient reads. Its central idea is alignment. A message passes DMARC only when SPF or DKIM produces a pass and that pass is based on an identifier aligned with the visible From: domain (RFC 7489, section 4.2). This is why a message can pass raw SPF yet fail DMARC: if your ESP sends with its own Return-Path domain, SPF passes for the ESP, but that domain is not aligned with your From:, so the SPF side of DMARC fails. Alignment comes in two modes — relaxed, which accepts a matching organizational domain (mail.yourco.com aligns with yourco.com), and strict, which demands an exact match. Because either aligned mechanism is enough, DKIM alignment usually carries mail that SPF cannot, such as forwarded messages. The record itself reads v=DMARC1; p=none; rua=mailto:reports@yourco.com; the p tag sets the policy (none, quarantine, or reject), rua names where aggregate reports are sent, and sp sets a separate policy for subdomains — which defaults to your p value if you omit it.
Why this became mandatory in 2024
Authentication used to be optional hygiene. In February 2024 it became a gate. Gmail and Yahoo now require bulk senders — Google counts anyone sending more than 5,000 messages a day to Gmail — to authenticate with SPF and DKIM and to publish a DMARC record, which may start at p=none. Marketing and subscribed mail must also carry one-click unsubscribe: the List-Unsubscribe header (RFC 2369) plus List-Unsubscribe-Post: List-Unsubscribe=One-Click, the one-click mechanism from RFC 8058, so a recipient's client can unsubscribe with a single HTTPS POST. You can read the full Gmail and Yahoo rules in the deliverability overview. Two things worth noting: enforcement has tightened since 2024, so build to the rule even under 5,000 a day, and keeping spam complaints low sits alongside authentication as a requirement, not a nice-to-have.
Common mistakes that silently break authentication
- Publishing +all on your SPF record, which authorizes the entire internet to send as you — the opposite of the point.
- Running more than one v=spf1 record on the same domain, which returns permerror and voids SPF.
- Blowing past the ten-DNS-lookup limit as you add vendor includes, which also returns permerror.
- A DKIM key that is too short or never rotated, so a leaked or brute-forced key keeps signing indefinitely.
- Jumping straight to p=reject before reading a single aggregate report, which blocks legitimate mail you forgot you send.
- Forgetting sp= for subdomains, so a lax subdomain policy leaves marketing.yourco.com open to spoofing.
- A third-party sender — an ESP, an invoicing tool, a help desk — that you never brought into SPF and DKIM alignment, so its mail fails DMARC.
Where authentication fits your stack
Authentication is the foundation everything else sits on. If you self-host, you own the DNS and the signing keys outright, which is the strongest version of controlling your own sender identity. A customer-engagement platform should surface authentication and alignment status for every sending domain rather than hide it, so you can see at a glance which sources pass. Route transactional and marketing mail on separate streams and, ideally, separate subdomains, so a marketing complaint spike never threatens password-reset delivery. And sequence the work correctly: authentication and alignment come first, before warming the domain — a warm-up on an unauthenticated domain just teaches providers to distrust you faster.