ARC Readiness Checker

ARC (Authenticated Received Chain), defined in RFC 8617, preserves email authentication results across intermediaries such as mailing lists, forwarders, and security gateways. Each hop adds a signed record of the results it saw, so the final receiver can trust that a message authenticated correctly before forwarding broke SPF or DKIM.

This checker tests ARC readiness: it reads your DMARC policy at _dmarc.<domain>, detects whether your mail provider is ARC-aware from your MX records (Google Workspace, Microsoft 365, Proofpoint, Mimecast, and others), and probes well-known ARC/DKIM selectors such as arcselector9901 for published keys.

Each intermediary adds one ARC set of three headers: ARC-Authentication-Results (the authentication results observed at that hop), ARC-Message-Signature (a DKIM-like signature over the message), and ARC-Seal (a signature binding all previous ARC sets, carrying the cv= chain-validation status).

No. SPF, DKIM, and DMARC authenticate the original sender; ARC preserves those results when legitimate intermediaries break them. A receiver can use a valid ARC chain to accept forwarded mail that would otherwise fail DMARC — direct mail is evaluated exactly as before.

Forwarding changes the sending IP, so SPF no longer matches, and mailing lists that rewrite the subject or add footers invalidate the DKIM signature. Under a p=quarantine or p=reject policy, receivers then reject legitimate forwarded mail. ARC (RFC 8617) hands receivers the pre-forwarding results so they can override that failure.

There is no dedicated ARC record type. ARC signatures are verified with DKIM public keys published under _domainkey, using whatever signing domain and selector the intermediary that adds the ARC headers chooses. As a domain owner, your job is keeping DKIM and DMARC healthy — which is exactly what this checker verifies.