SPF, DKIM, DMARC, and ARC: The Complete Authentication Stack
Email authentication is no longer optional. Here's how the four protocols work together — and why ARC is critical for anyone who forwards mail.
The Authentication Triad
Three protocols form the authentication foundation that every major mailbox provider now requires.
SPF (Sender Policy Framework, RFC 7208) publishes a DNS record listing the IP addresses authorized to send mail for a domain. A strict SPF record ending in -all (hard fail) tells receiving servers to reject mail from unauthorized sources. The weaker ~all (soft fail) is common but provides less protection.
DKIM (DomainKeys Identified Mail, RFC 6376) adds a cryptographic signature to outbound messages. The receiving server retrieves the public key from DNS and verifies that the message was not modified in transit. DKIM signing should be configured for every domain that sends mail, not just the primary domain.
DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) ties SPF and DKIM together with a policy that tells receiving servers what to do when authentication fails. A DMARC policy of p=reject provides the strongest protection against domain spoofing. A policy of p=none provides no protection and exists only for monitoring.
The Edge Cases That Break DKIM
A critical implementation detail that most default configurations miss: DKIM signing must handle edge cases specific to forwarding and bounce handling.
Bounce messages (null sender / empty envelope-from) should be signed. Many DKIM implementations skip these, which means bounces go unsigned and are more likely to be flagged as spam. The configuration parameter is typically allow_envfrom_empty = true.
SRS-rewritten forwarded mail should be signed even when the envelope sender no longer matches the From header. Without allow_hdrfrom_mismatch = true, forwarded mail goes out with no DKIM signature at all — a deliverability disaster.
ARC: Solving the Forwarding Problem
Email forwarding breaks DKIM. When a message is forwarded, the forwarding server may modify headers or the message body, invalidating the original DKIM signature. SPF also fails because the forwarding server's IP is not in the original sender's SPF record.
The Authenticated Received Chain (ARC), defined in RFC 8617, solves this by having each intermediary record a snapshot of the authentication results it observed, then cryptographically sign that snapshot. When the message reaches its final destination, the receiving server can examine the ARC chain to determine whether the original authentication was valid before the message was modified by forwarding.
Google explicitly recommends ARC for forwarding services and mailing lists (Google Workspace Admin Help). The ARC specification describes it as a "chain of custody" for authentication results — each hop in the forwarding chain adds a signed link.
Without ARC, forwarded mail from domains with strict DMARC policies will be rejected by Gmail, Outlook, and Yahoo — regardless of how well the forwarding server is configured.
Configuration Principle
ARC configuration should mirror the DKIM signing configuration exactly: same keys, same domain mappings, same forwarding-friendly settings. The two protocols work in tandem — DKIM proves the message was signed by the forwarding domain, and ARC proves that the original authentication was valid before forwarding occurred.