A WordPress operator forwarding mail from external senders (a domain’s inbox routed to Gmail via Cloudflare Email Routing, ImprovMX, or any of the other forwarders a small site uses) sometimes finds messages silently disappearing on the way to the final inbox. The sender gets no notification; the operator sees nothing in any log; the message is just gone. ARC is one of two schemes forwarders implement to prevent that, and the one that handles the harder case.
The harder case is a forwarded message from a sender publishing strict DMARC (banks, Google notifications, work accounts on p=reject) where something along the forwarding hop breaks the message’s DKIM signature. DMARC fails at the receiver, the policy says reject, and the message is dropped. ARC lets the forwarder record, in cryptographically signed form the receiver can verify against the forwarder’s DNS, that the authentication was valid when the message was accepted at the forwarder’s edge. A receiver that trusts the forwarder’s chain accepts the attestation and delivers the message.
What the headers look like
ARC adds three headers to a forwarded message. The forwarder adds them before relaying; a chain of forwarders can each add their own set, numbered sequentially.
ARC-Authentication-Results: i=1; mx.google.com; spf=pass [email protected]; dkim=pass header.d=bank.com; dmarc=pass
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.net; s=arc20230926; h=from:to:subject:date; bh=...; b=...
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=cloudflare.net; s=arc20230926; b=...The three roles: ARC-Authentication-Results captures the authentication state the forwarder saw at its inbound edge (SPF pass, DKIM pass, DMARC pass, each with the identity that produced the result). ARC-Message-Signature is a DKIM-style signature over the message as the forwarder received it, scoped to the forwarder’s own domain. ARC-Seal signs the sequence of ARC headers themselves, including the chain-validity state of any earlier hop’s ARC set.
RFC 8617 is the specification. The RFC is Experimental track rather than Standards track; the deployment reality (Gmail honours it, large mailbox providers increasingly do, Microsoft 365 has partial support) has outrun the formal status.
How the chain is read
A receiver evaluating ARC walks the chain from the lowest i= (the oldest hop) to the highest (the most recent forwarder). For each hop, it verifies the ARC-Message-Signature against the message as it existed at that hop, and the ARC-Seal against the chain state at that hop. The cv= tag on each seal records the chain-validity verdict the hop made: none for the first hop, pass for a hop that validated the previous chain, fail for a hop that found a break.
A chain with a cv=fail anywhere invalidates the chain for every subsequent hop. A chain that terminates in cv=pass with the most recent seal verifying tells the receiver: this entire forwarding path can be cryptographically reconstructed, and the authentication story at the first hop was what the first ARC-Authentication-Results says it was.
The receiver then applies trust. A valid ARC chain from a forwarder the receiver does not trust buys nothing; a valid chain from a trusted forwarder is accepted as the authoritative pre-forward authentication state. Gmail maintains an internal reputation signal for forwarders whose chains it validates; a chain from Cloudflare Email Routing, Fastmail, or Google Workspace itself tends to be honoured, while a chain from a brand-new forwarder with no reputation is not.
Where ARC matters, and where it does not
The use case is specific: a forwarded message from a sender publishing p=reject, where DKIM broke somewhere in transit (a subject rewrite, a footer injection, a MIME re-encoding), and the receiver would otherwise drop the message because DMARC fails. If the forwarder added ARC headers at the point when DKIM was still valid, a trusting receiver accepts the forwarder’s attestation and delivers the message.
The use case does not cover: forwarding mail from a sender with no DMARC policy (DMARC does not drop; no ARC needed), forwarding mail where DKIM survives intact (DMARC passes on DKIM alignment; no ARC needed), or forwarding across hops the receiver does not individually trust (ARC chain is cryptographically valid but politically ignored).
For a WordPress operator picking a forwarder, ARC is the capability that matters when a lot of forwarded inbound comes from strict-DMARC senders: banks, corporate workaccounts on p=reject, Google’s own notifications. For an operator whose inbound is mostly newsletters and personal correspondence from senders at p=none, ARC never fires because the receiver has no reason to drop the message in the first place.
Who publishes ARC today
Explicitly documented ARC on the forwarding side: Forward Email (all plans, explicit in the FAQ). Documented at the parent product line but not the specific forwarding product: Cloudflare’s Email Service documentation describes ARC without an Email Routing-specific statement; Google Workspace’s forwarding path adds ARC when it relays mail onward. Most other forwarders either implement ARC without documenting it (the signature appears in forwarded headers but no vendor page describes the feature) or do not implement it at all.
On the receiver side: Gmail documents ARC-aware evaluation and uses it in production. Microsoft 365 has partial support, with less transparent weighting than Gmail. Yahoo supports it. Smaller mailbox providers and self-hosted Postfix/Dovecot setups typically do not evaluate ARC without additional milter configuration (OpenARC is the common implementation; it is not installed by default on any major distribution).
The capability matrix in how email forwarding works for WordPress names which forwarders nanoPost tracks implement ARC and which only implement SRS.
What ARC does not do
ARC is a trust system, not an authentication system. A valid ARC chain tells a receiver what the chain says happened; whether the receiver believes the chain depends on reputation the forwarder has built with that receiver separately. A chain signed by a brand-new domain with no deliverability history buys very little even when it is cryptographically perfect.
ARC does not change the sender’s authentication records. The original From: domain still publishes its SPF, DKIM, and DMARC; ARC exists to carry a snapshot of how those records evaluated at the forwarder’s inbound edge, not to substitute for them.
ARC does not solve forwarding for an operator whose forwarder does not implement it. The practical fallbacks are the same as before ARC existed: pick a forwarder that implements both SRS and ARC, pick a mailbox provider that does not re-forward and holds the mail in storage instead, or accept that strict-DMARC senders will have an elevated drop rate on the forwarded path.
For the first part of the forwarding authentication story, see SRS for forwarded WordPress mail. For the signature method ARC extends and signs over, see DKIM for WordPress email. For the receiver-side policy that creates the forwarded-mail drop risk ARC exists to mitigate, see DMARC for WordPress email. The companion architecture guide is how email forwarding works for WordPress.