SMTP error 5.7.29 ARC validation failure

What SMTP error 5.7.29 means

ARC is the mechanism that lets a forwarder or a mailing list record that a message authenticated correctly when it arrived, so that the eventual receiver can take that into account after forwarding has broken SPF and DKIM. This code says the receiver examined that chain and did not trust it. It comes back as 550 5.7.29, and the problem sits with the intermediary far more often than with whoever wrote the message.

Security or policy status
Sent by The receiving mail server, evaluating the ARC chain added by a forwarder in the path
Rare

What SMTP error 5.7.29 ARC validation failure actually means

Every hop that takes part in ARC adds a set of headers sealing what it observed, and sealing the seals of the hop before it. The chain is only worth something if each link verifies and no intermediary has modified the message without resealing. When it fails, the receiver falls back to judging the message on the SPF and DKIM results it can see for itself, and after forwarding those are usually failures, so an ARC failure tends to be the last step before a rejection on DMARC grounds rather than the whole story. Most UK businesses meet this through a discussion list, an association mailing list or an external forwarding arrangement left over from an old address. Registered as permanent only, and the sender rarely has any way to influence it.

This status code may be returned when a message fails ARC validation.
— RFC 8617

How 5.7.29 appears in a bounce

A server reporting this condition sends it alongside a three-digit reply code, and a bounce prints the two together. The registry lists 550 5.7.29 as the pairing for this status.

The leading 5 is the server's verdict rather than part of the code's identity: it marks this as a permanent failure, which means the sending server has given up and returned the message.

What causes SMTP error 5.7.29 on a business phone system

A forwarder that modifies the message without sealing correctlyThe intermediary appends a footer or rewrites a subject, then either seals the wrong version or seals it after another component has changed it again. What arrives no longer corresponds to what was signed.
The chain broken by a hop that does not implement ARCOne participant in the middle handling the message without adding its own seal marks the chain as failed for everyone downstream. A single non-participating relay is enough to spoil an otherwise valid chain.
The intermediary's signing key missing from DNSARC uses the same key mechanics as DKIM but with its own selector, so it can be rotated or removed independently. If the forwarder's key does not resolve, none of its seals verify.
A receiver that does not trust the sealerTrusting an ARC chain is a decision each receiver makes about each intermediary. A perfectly valid chain sealed by a small list server the receiver has never heard of may simply not be credited.
Clock skew on the sealing hostSeals carry timestamps, and a host whose clock has drifted can produce a chain that looks inconsistent or prematurely aged. It is uncommon and it is worth ruling out when nothing else explains the failure.

How to fix SMTP error 5.7.29

Work out which system is doing the forwardingRead the Received headers from the bottom upwards and identify every hop between the author and the final destination. You cannot fix an intermediary you have not identified, and there is often more than one.
Read the chain validation resultThe ARC-Authentication-Results and ARC-Seal headers carry a cv= tag whose value states whether the chain was none, pass or fail at that hop. That tells you where the chain broke rather than merely that it did.
Take the forwarding out of the path where you canAn old address forwarding to an external mailbox is the most common trigger and the easiest to remove. Convert it into a real mailbox or an alias inside your own tenant, and the message never leaves one platform.
Raise it with the list or gateway operatorIf the intermediary is a supplier or an industry mailing list, they are the only party who can correct their sealing. Send them the full headers of a failed message, since the cv= values point straight at their configuration.
Resist the urge to change anything at the original senderTightening your own SPF or DKIM will not help, because forwarding invalidates both regardless of how well they are configured. That is the entire reason ARC exists, and effort spent at the origin is effort wasted.

Fixing the underlying problem

This page explains the code. These guides walk through the fix in detail.

Questions about SMTP error 5.7.29

Do we need to publish ARC records for our domain?

Only if you forward or relay other organisations' mail onwards. An ordinary business sending its own email is never the sealer, so there is nothing to publish and nothing to maintain.

Will getting SPF and DKIM right prevent this?

No. Forwarding changes the connecting address and often changes the content, so both checks fail at the final destination however carefully you configured them. ARC exists precisely to carry the earlier result across that gap.

Why do our forwarded messages work to some recipients and not others?

Because supporting ARC and trusting a particular sealer are two different decisions, and receivers make them independently. The large providers implement it and generally trust each other, while smaller receivers may not evaluate the chain at all.

Related SMTP status codes

Source. SMTP error 5.7.29 ARC validation failure is defined in RFC 8617 and registered in the IANA SMTP Enhanced Status Codes registry. The causes and fixes above are drawn from our own experience supporting UK business email systems.

All Email delivery & SMTP codes