An RFC-grounded technical reference for the five email authentication standards, with DNS examples, troubleshooting, and a scenario-based implementation checklist.
SMTP, the protocol that moves email across the internet, has no built-in way to verify who actually sent a message. Anyone can claim to be anyone. Email authentication is the layered system mailbox providers now use to answer three questions: was the message authorized by the sending domain, was the content unaltered in transit, and what should happen if either check fails.
Five standards cover those answers today. SPF (RFC 7208) authorizes sending IPs. DKIM (RFC 6376) cryptographically signs headers and body. DMARC (RFC 7489) tells receivers what to do when SPF or DKIM fails and publishes alignment requirements. BIMI (IETF draft) lets authenticated senders display a logo in the inbox. ARC (RFC 8617) preserves authentication results across legitimate forwarders.
SPF is a TXT record at the root of your sending domain that lists the IPs or hostnames authorized to send mail using that domain in the Return-Path (bounce) address. Receivers look up the record during SMTP negotiation and compare the actual sending IP to the published list.
DNS record (TXT at the apex):
v=spf1 include:_spf.google.com include:amazonses.com ~all
The qualifier at the end tells receivers what to do with mail from non-listed IPs: ~all means soft-fail (deliver to spam), -all means hard-fail (reject), ?all is neutral, and +all authorizes everyone (never use this).
The most common SPF failure is the ten-DNS-lookup limit defined by RFC 7208 §4.6.4. Each include:, a, mx, exists, redirect, and ptr mechanism counts, and they stack recursively through every included record. Records exceeding the limit return PermError, which most receivers treat as a fail. Validate your record with the SPF checker before going live.
DKIM attaches a cryptographic signature to every outgoing message. The sending server signs a canonicalized subset of headers plus the body using a private key, and publishes the matching public key in DNS under a selector name. Receivers fetch the public key, verify the signature, and reject or flag mismatches.
DNS record (TXT at <selector>._domainkey.example.com):
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...
The signature itself lives in a DKIM-Signature header on every message and identifies which selector to look up. RFC 6376 recommends 2048-bit RSA keys; 1024-bit keys still work but Google now marks them as weak. Rotate selectors every 6 to 12 months to limit exposure if a private key leaks.
Verify your active selector with the DKIM checker. The most common failure is forgetting to publish the key before the sending service starts signing.
SPF and DKIM tell receivers whether a message authenticated. DMARC tells them what to do about failures, requires header-from alignment, and collects reports so you can see who is sending under your domain.
DNS record (TXT at _dmarc.example.com):
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100
Policies escalate: p=none only reports (monitoring mode), p=quarantine sends failures to spam, and p=reject tells receivers to bounce them. Google and Yahoo's 2024 bulk-sender rules require at least p=none with a valid rua address; most teams progress to quarantine or reject within 4 to 8 weeks of reviewing aggregate reports.
Alignment is what makes DMARC stricter than SPF or DKIM alone. A message passes DMARC only if the domain that authenticated (via SPF Return-Path or DKIM d=) aligns with the visible From header domain. Strict mode (adkim=s, aspf=s) requires an exact match; relaxed mode allows the organizational domain.
Validate your policy with the DMARC checker, and pipe rua reports into a parser so you can see which third-party senders (calendar tools, CRM, ticketing) need their own DKIM setup before you can safely enforce.
BIMI lets authenticated senders display their logo next to messages in supporting inboxes (Gmail, Yahoo, Fastmail, Apple Mail on iOS 16+). Two hard requirements: DMARC must be enforced at p=quarantine or p=reject, and the logo must be an SVG Tiny 1.2 file hosted on HTTPS. Gmail and Apple additionally require a Verified Mark Certificate (VMC) or Common Mark Certificate (CMC) issued by a certificate authority (DigiCert or Entrust today).
DNS record (TXT at default._bimi.example.com):
v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem
Legitimate forwarding (mailing lists, catch-all aliases, automatic forwards) breaks SPF because the forwarder is not in your SPF record, and can break DKIM if the forwarder modifies the body (footer insertion, subject prefix). ARC, defined in RFC 8617, lets each intermediary add a signed chain of authentication results so the final receiver can trust the results from before the forwarding happened.
ARC is a receiver-and-forwarder standard, not something the original sender configures. You do not publish a DNS record. What matters is whether the forwarders in your path (Google Groups, corporate mail gateways) sign ARC headers correctly. Gmail does; most consumer forwarders do not.
New domain, cold outreach only:
~all.p=none with rua= pointing to a monitored inbox.p=quarantine once reports show no legitimate sources failing.Existing domain with mixed transactional, marketing, and outreach:
go.example.com) so a warmup misstep cannot damage your main domain.Multiple sending services on one domain: add each service's SPF include and publish a separate DKIM selector per service. Use distinct selectors (like ses1, gsuite, hubspot) so rotating one key does not affect the others.
When a deliverability issue shows up, check the headers of a failing message first. Most mail clients let you view source. Look for the Authentication-Results header; it reports the pass/fail verdict for each standard.
ip4: / ip6: entries.Keep reading