Forum Discussion
ARC verification fail (40) on specific Exchange Online frontends - recurring issue
Hello,
We are observing recurring arc=fail (40) errors on messages forwarded through Exchange Online, caused by specific frontend servers. The same messages pass ARC verification correctly on other providers (Google, etc.).
Affected frontends identified so far:
- CH2PEPF0000013F.namprd02.prod.outlook.com - build 15.20.9700.17 (March 14, 2026)
- CH3PEPF0000000B.namprd04.prod.outlook.com - build 15.20.9769.17 (April 6, 2026)
Both share the same build suffix .17. The signing implementation on our side has been cryptographically verified as correct and RFC 6376 compliant. The issue has also been reported on the IETF ietf-smtp mailing list with full technical analysis.
Cryptographic analysis shows the failing servers append a spurious trailing \r\n to the last header before computing the verification hash, violating RFC 6376 Section 3.7.
Is there a pattern with .17 frontend builds and ARC verification?
Reagards
Vittorio
2 Replies
darkglobe did you find more information on this? Asking only out of curiosity.
What tools or methods did you use to narrow down your discovery? For example were you analyzing Fiddler traces or using something different?
Hi, thanks for the interest.
The analysis was done entirely in Python using the cryptography library. The process was:
- Extracted the exact header values from syslog (the milter logs the canonicalized input at signing time)
- RSA raw decryption of the ARC-Seal i=2 signature to extract the embedded SHA-256 hash
- Recomputed the SHA-256 hash from the canonicalized input without trailing \r\n on the last header - it matched the embedded hash exactly, confirming the signature is fully RFC 6376 compliant
- Since the signature is valid and the failing servers return error code 40 (signature verification failure), the only explanation consistent with the evidence is that those frontends append a trailing \r\n before computing the verification hash, producing a different hash that does not match the signature
So to be precise: what we proved is that our signature is correct. The \r\n hypothesis on Microsoft's side is the logical inference from that proof, not a directly observed fact.
No Fiddler or network traces needed - everything was derived from the email headers and syslog output alone. The full technical discussion is also on the IETF ietf-smtp mailing list.
Regards
