The Complete Email Authentication Guide (2026)

Why Authentication Exists

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 (Sender Policy Framework)

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 (DomainKeys Identified Mail)

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.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

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 (Brand Indicators for Message Identification)

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

ARC (Authenticated Received Chain)

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.

Implementation Checklist by Scenario

New domain, cold outreach only:

1. Publish SPF with only the sending service's include (Google, AWS SES, etc.) and ~all.
2. Publish a 2048-bit DKIM key under a fresh selector.
3. Publish DMARC at p=none with rua= pointing to a monitored inbox.
4. Warm the domain for 2 to 4 weeks before scaling volume.
5. Advance to p=quarantine once reports show no legitimate sources failing.

Existing domain with mixed transactional, marketing, and outreach:

1. Send outbound cold email from a sending subdomain (for example go.example.com) so a warmup misstep cannot damage your main domain.
2. Give the subdomain its own SPF, DKIM, and DMARC record independent of the apex.
3. Leave the apex DMARC untouched until subdomain reports are clean.

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.

Troubleshooting

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.

• SPF permerror: you exceeded ten DNS lookups. Flatten includes or move to ip4: / ip6: entries.
• DKIM temperror: the selector DNS record is missing or the receiver could not fetch it. Re-check propagation.
• DMARC fail with SPF pass and DKIM pass: alignment failure. The authenticated domain differs from the visible From header domain. Fix by sending from an aligned subdomain.
• Messages fine on Gmail, spam on Outlook: Outlook weighs content and sending history more heavily than headers. The authentication is probably passing; run the infrastructure grader to see what else might be off.

References

• RFC 7208, Sender Policy Framework (SPF)
• RFC 6376, DomainKeys Identified Mail (DKIM) Signatures
• RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 8617, The Authenticated Received Chain (ARC) Protocol
• BIMI Group, Implementation Guide
• Gmail bulk sender requirements (2024)

Related Resources

• SPF Record Checker
• DKIM Record Checker
• DMARC Checker
• Full Deliverability Grader
• Email Warmup Guide 2026