Read the ARC chain
Forwarded mail, Google Groups, Microsoft 365 rules and mailing lists all add ARC sets. A message delivered directly usually has none.
How it works
Collect
All three ARC header types are read and grouped by instance number. Folded headers are unfolded first.
Order
Instances must run 1…N with no gaps, each with a seal, a signature and a results header. The first seal must be cv=none, every later one cv=pass.
Keys
For each sealer, the selector._domainkey record is fetched — a seal nobody can verify is decorative.
Read
The table shows who sealed each hop and what they attested. The notes say whether a receiver could use the chain.
What ARC is for
DMARC breaks on forwarding. A message that passed SPF and DKIM at Google fails SPF when Google forwards it to a Microsoft mailbox, because Google is now the envelope sender, and often fails DKIM too if a footer or subject tag was added. Under p=reject that means forwarded mail is refused. ARC is the fix: each intermediary records the authentication results it saw, signs them, and signs the chain of everything before it. The final receiver can then decide to trust the first hop's verdict instead of its own failed one.
Reading the three headers
Each hop adds a set of three. ARC-Authentication-Results is what that hop saw — its own SPF, DKIM and DMARC verdicts, copied from its Authentication-Results. ARC-Message-Signature is a DKIM-style signature over the message as it left that hop. ARC-Seal signs the whole chain so far and carries cv=: none for the first hop, pass if the previous chain validated, fail if it did not. Instance numbers must be contiguous. A gap, a missing header, or a cv=fail anywhere means the chain cannot be used.
Why it matters for cold email
You do not add ARC yourself; providers do. It matters because when a prospect's mail is forwarded — a shared inbox routed to an assistant, a company that migrated and forwards old addresses, a Google Group — ARC is the only reason your p=reject message arrives. When someone tells you a reply bounced with a DMARC error after forwarding, this tool shows whether the chain was there and where it broke. It is also the quickest way to see which providers a message passed through, because each sealer names itself.
Trust is the receiver's decision
An intact chain sealed by a domain the receiver does not trust does nothing. Google, Microsoft, Yahoo and the large gateways trust one another; a chain sealed by a small hosting company is usually ignored. That is by design — anyone can add ARC headers claiming the message once passed DKIM. So the question is not just "is the chain valid" but "would the final receiver believe the sealer", and the notes flag sealers outside the usual list.
Frequently asked questions
What does cv=none, cv=pass and cv=fail mean?
cv is the chain validation status. The first hop always writes cv=none because there is no earlier chain. Each later hop validates everything before it and writes pass or fail. A fail anywhere invalidates the rest.
Does ARC fix DMARC failures on forwarded mail?
It lets the final receiver override its own DMARC failure with the first hop's verdict, if it trusts the sealer. Google and Microsoft both do this for each other. It is not a guarantee.
Can I add ARC headers to my own outbound mail?
There is no point — ARC is added by intermediaries, not senders. Your job is to have SPF and DKIM aligned so the first hop records a pass.
Why does the tool look up DKIM keys for the sealers?
ARC seals are verified with the sealer's DKIM key at selector._domainkey.domain. If that key is not published, no receiver can verify the seal, and the chain is useless.
No ARC headers were found — is that a problem?
No. Directly delivered mail rarely has any. ARC appears when a message has been forwarded, relayed through a gateway, or passed through a mailing list.
Last reviewed
What to run next
The checks that most often follow this one.
More in this category
Guides that go deeper
When the tools tell you something is wrong
The diagnostics here are free and always will be. When the fix is bigger than a DNS record, this is the work I do.
Deliverability rescue
Mail landing in spam, replies gone quiet, or a domain suddenly blocked. I find the actual cause rather than guessing, and fix it.
- Authentication and alignment failures
- Blocklist delistings and reputation repair
- Gateway and filter-level blocks
- A written report on what broke and why
Email & sending infrastructure
Sending domains, inboxes, authentication and warmup, built to survive volume instead of burning down in a month.
- Domain and inbox fleets at any scale
- SPF, DKIM, DMARC and tracking domains
- Google Workspace — Silver Partner
- Handover documentation you actually own
Domain, DNS & migration
Changing registrar, mail provider or host without a day of downtime or a week of mail silently failing.
- Registrar and nameserver moves
- Workspace and Microsoft 365 migrations
- MX, SSL and subdomain cutover
- Staged rollout with rollback at every step
Monitoring & retainer
Infrastructure drifts. Records get edited, certificates expire, domains get listed. Ongoing eyes on the fleet.
- Scheduled checks across every domain
- Alerts before your clients notice
- Monthly reporting
- Priority response when something breaks
Start with a call
Bring a domain and the symptom. I will tell you what is actually wrong and whether you need me at all — plenty of people leave that call able to fix it themselves.
Thirty minutes, no pitch
We will run the checks together on your actual domains, and you will leave knowing what is broken, what it takes to fix, and what it should cost. If that is a job you can do in-house, I will say so.