ARC Header Validator

Validate the syntax and required tags of Authenticated Received Chain (ARC) headers.

Our ARC Checker inspects the Authenticated Received Chain on a domain, retrieving the ARC sealing key published in DNS and explaining how intermediaries preserve authentication results. ARC is what keeps DMARC from breaking when mail passes through mailing lists and forwarders.

What is ARC?

ARC (Authenticated Received Chain) is a standard, defined in RFC 8617, that lets an intermediary mail server record the authentication results it observed and cryptographically vouch for them.

The problem it solves is well known. When a mailing list receives your message and forwards it with a modified subject line or an appended footer, your DKIM signature breaks and SPF no longer matches the connecting server. The final recipient sees a message that fails DMARC even though it was perfectly legitimate when it left you.

ARC adds three headers at each hop: ARC-Authentication-Results records what the intermediary saw, ARC-Message-Signature signs the message as received, and ARC-Seal signs the chain itself. A receiving server that trusts the intermediary can then use those preserved results instead of rejecting the message outright.

Preserves authentication results across forwarding and mailing lists
Adds three headers per hop, forming a verifiable chain
Defined in RFC 8617
Implemented by Google, Microsoft and most major mailing list software
Trust in the chain is at the receiver discretion, not automatic

Why ARC Matters

ARC is the reason a strict DMARC policy does not destroy legitimate mailing list traffic. Without it, every organisation moving to p=reject discovers that their users posts to industry lists start bouncing, and the usual reaction is to weaken the policy rather than fix the underlying issue.

For anyone running a forwarder, a list server or a security gateway that rewrites messages, implementing ARC is what lets downstream receivers distinguish your legitimate modifications from an attacker tampering with mail in transit.

Prevents legitimate mailing list mail from failing DMARC at the final hop
Lets organisations reach p=reject without breaking user workflows
Essential for anyone operating a forwarder or list server
Gives receivers evidence about what happened before the message reached them
Reduces the pressure to keep DMARC at a weak policy indefinitely

How This ARC Checker Works

The tool looks for the ARC sealing key a domain publishes and reports on its configuration.

Validates the domain input against format and SSRF safety checks
Queries DNS for the ARC selector key under _domainkey
Parses the published key material and algorithm
Reports whether the domain is configured to seal ARC chains
Explains how the chain would be evaluated by a receiving server

How to Use the ARC Checker

Enter the domain you want to inspect in the input field
Run the check to query the published ARC configuration
Review whether a sealing key is present
To inspect a specific message, view its full headers and read the ARC-Seal lines
Check the cv= tag on the outermost seal — it reports the chain validation state

Understanding ARC Results

ARC works through three headers added at each hop. Here is what each one does:

Field / Value	Meaning
`ARC-Authentication-Results`	Records the SPF, DKIM and DMARC results the intermediary observed when it received the message. This is the evidence the final receiver relies on.
`ARC-Message-Signature`	A DKIM-style signature over the message as the intermediary received it, before any modification. It proves what the message looked like at that hop.
`ARC-Seal`	Signs the ARC headers themselves, chaining this hop to the previous ones. It is what makes the chain tamper-evident rather than merely informative.
`i= instance number`	Each hop increments this counter, starting at 1. It orders the chain so a receiver can walk it from the original sender forwards.
`cv=none`	On the first hop, meaning no prior chain existed. Correct for the first intermediary to handle the message.
`cv=pass`	The chain up to this point validated successfully. The receiver may choose to trust the preserved authentication results.
`cv=fail`	The chain is broken. Some hop modified the message or headers in a way that invalidated a prior seal, and the chain provides no assurance.

Common Problems & How to Fix Them

The list modified the message — usually a subject prefix or a footer — which broke your DKIM signature, while SPF no longer matches because the list server is now the sender.

If you run the list, implement ARC so downstream receivers can see the original authentication results. If you do not, the practical options are for the list to rewrite the From header to its own domain, or for the list operator to adopt ARC.

A hop in the chain modified the message or the ARC headers in a way that invalidated an earlier seal.

Identify which instance number breaks by examining the headers in order. The most common cause is an intermediary that reorders or rewrites headers after sealing, or a gateway that applies content modification without ARC awareness.

ARC does not compel a receiver to trust anything. Each receiver decides which intermediaries it considers trustworthy, usually based on reputation.

There is no configuration that forces acceptance. A new forwarder building reputation should expect its chains to be treated cautiously at first, and should ensure it is otherwise well-behaved so that reputation accrues.

Messages passing through it lose their authentication evidence entirely, so anything modified in transit fails DMARC at the destination with no way to recover.

Enable ARC sealing in your mail software. Recent versions of Mailman, Exim, Postfix with OpenARC, and most commercial gateways support it. The domain doing the sealing needs its own key published in DNS.

Best Practices

Implement ARC sealing on any server that forwards or modifies mail
Publish the ARC sealing key in DNS exactly as you would a DKIM key
Use 2048-bit keys for ARC sealing, matching DKIM practice
Preserve the existing chain when adding a new seal — never strip prior headers
Avoid modifying messages at all where it can be helped, since an unmodified message needs no ARC
Monitor DMARC aggregate reports for failures that originate at known forwarders
Do not weaken a DMARC policy to accommodate forwarding; address it with ARC instead

Security Recommendations

Remember ARC asserts what an intermediary claims to have seen, so its value rests entirely on that intermediary being trustworthy
Never treat a cv=pass chain as authentication in its own right — it is a statement by a third party, not proof from the originating domain
Protect ARC sealing keys as carefully as DKIM private keys, since either allows forging assertions in your name
Be cautious about trusting chains from unknown intermediaries, as an attacker can seal a chain that vouches for their own forged results
Continue to enforce DMARC rather than relaxing it, using ARC to handle the legitimate forwarding cases
Log ARC evaluation outcomes so that chains you rejected can be reviewed rather than silently discarded

Frequently Asked Questions

ARC is a standard that lets an intermediary mail server record and cryptographically sign the authentication results it observed. It allows the final recipient to see that a message passed SPF and DKIM before a forwarder or mailing list modified it.

Mailing lists commonly add a subject prefix or a footer, which breaks the original DKIM signature. SPF also fails because the list server, not your server, is now making the connection. Without ARC the final recipient sees only those failures.

Only if you operate infrastructure that forwards or modifies mail — a mailing list, a forwarding service or a security gateway. An ordinary sending domain does not publish ARC; it benefits from intermediaries that implement it.

It means the chain validated successfully up to that hop. The receiver may then choose to rely on the preserved authentication results rather than the results it can compute itself. It is an invitation to trust, not a guarantee.

No. It supplements them. SPF and DKIM still perform the original authentication, and DMARC still sets policy. ARC only preserves the evidence of that authentication across hops that would otherwise destroy it.

Google and Microsoft both evaluate ARC chains, and most current mailing list software can seal them. Support among smaller receivers is less consistent, and every receiver applies its own trust judgement regardless of technical support.

An attacker can certainly seal a chain asserting whatever results they like. This is why receivers weigh ARC chains by the reputation of the sealing domain rather than accepting them automatically. A chain from an unknown domain carries little weight.