MailDingo

arc=fail

arc=fail

The message carries ARC records from servers that relayed it, but they don't check out, so they can't be used as evidence.

arc=fail means the message arrived with ARC headers, but when the receiver checked them, the chain didn't hold together. A seal didn't verify, the newest message signature didn't match, or the headers were incomplete or out of order. A failed chain is worth nothing as evidence: the receiver treats the message as if it had no ARC at all.

What the RFC says

RFC 8617 §4.4 defines fail as a chain whose validation failed. §5.2 lists the ways it can fail:

  • more than 50 ARC sets;
  • the newest ARC-Seal already says cv=fail;
  • a set missing one of its three headers, or instance numbers that skip or repeat;
  • a seal with the wrong cv= value (i=1 must say none, later ones pass);
  • the newest ARC-Message-Signature failing to verify;
  • any ARC-Seal failing to verify.

§5.2.1 adds a strict rule: every error is permanent, including DNS failures. There is no "arc=temperror". The same section says a failed chain must be treated like no chain.

Authentication-Results: mx.example.org;
       dkim=fail header.d=example.com;
       dmarc=fail header.from=example.com;
       arc=fail (signature failed)
ARC-Seal: i=2; a=rsa-sha256; d=fwd.example.net; s=s1; cv=pass; b=...
ARC-Seal: i=1; a=rsa-sha256; d=lists.example.org; s=a1; cv=none; b=...

Why chains break

  1. Something changed the message after the last seal. A gateway that rewrites links or adds a banner but doesn't seal will break the newest ARC-Message-Signature. RFC 8617 §5.1 requires sealers to finish all their own edits before sealing for exactly this reason.
  2. A sealer's key couldn't be fetched. Because DNS errors count as permanent, a brief outage at one intermediary's DNS fails the whole chain.
  3. Implementation bugs: wrong instance numbering, duplicate sets, or a sealer that sets cv= wrongly.
  4. Deliberate tampering: someone forging or replaying ARC headers to slip past a receiver that trusts ARC.

Once a chain has failed, it can't be repaired. Later intermediaries may add a set marked cv=fail (§5.1.2), but the chain stays broken (§5.1.3).

If you received this message

The fail is not a verdict on the sender. It just removes the second chance ARC might have given a message that failed DMARC after forwarding. Judge the message on its SPF, DKIM and DMARC results and on the Received chain. Some receivers reject at delivery with SMTP code 5.7.29 for ARC failures (§5.2.2).

If you run an intermediary

Seal after all your modifications. Make sure your ARC selector's DNS is reliable, and check that you aren't adding a second set with an instance number that already exists. If downstream systems you control modify mail after sealing, move the seal to the last hop. Paste a sample into the analyser to see the ARC headers explained one by one.

See it in your own message

Paste the headers into the analyser to see which domain ARC checked and whether it lines up with the From address.

Open the analyser