SMTP error 5.7.7 Message integrity failure

What SMTP error 5.7.7 means

A server that was supposed to be able to validate this message could not, because what arrived does not match what was signed. IANA lists no associated reply code, so the three-digit number you actually see varies between implementations. In business email the practical cause is nearly always something in the path modifying a message that carried a cryptographic signature: a disclaimer being appended, a link being rewritten by a filtering gateway, or an S/MIME message being repackaged on its way through. Malicious tampering is possible but it is a long way down the list.

Security or policy status
Sent by A system entitled to verify the message, which found it had been altered
Rare

What SMTP error 5.7.7 Message integrity failure actually means

Signing a message fixes its content at a moment in time. Any later change, however well intentioned, breaks the arithmetic, and a verifier can only report that the integrity check failed. It cannot tell the difference between an attacker rewriting an invoice and a transport rule adding a legal footer, which is why the honest reading of this code is that the message is no longer identical to what was signed. Unusually, the registry allows a 2, a 4 or a 5 in the leading position, so this can appear as a warning attached to a message that was nonetheless delivered, not just as a refusal. Keep it apart from X.7.5, where the verifier lacked a usable key, and X.7.6, where it lacked the algorithm; here the material was all present and the content simply did not match.

A transport system otherwise authorized to validate a message was unable to do so because the message was corrupted or altered. This may be useful as a permanent, transient persistent, or successful delivery code.
— RFC 3463

How 5.7.7 appears in a bounce

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. The same condition reported as 4.7.7 or 2.7.7 is the other verdict on the identical problem, so a log showing that form has not produced a bounce yet.

RFC 3463 is explicit about which verdicts this code can carry: “This may be useful as a permanent, transient persistent, or successful delivery code.”

What causes SMTP error 5.7.7 on a business phone system

A disclaimer or signature applied after signingAn organisation-wide footer stamped on by a transport rule changes the body after the signature was calculated. It is the single most common way businesses break their own outbound signatures, and it only becomes visible when a recipient starts verifying properly.
Link rewriting by a filtering platformSafe Links in Microsoft Defender, and the equivalent URL protection in Mimecast and Proofpoint, rewrite every hyperlink so clicks can be checked at the time they happen. That is a body modification, and any signature covering the body no longer verifies afterwards.
A mailing list altering headers or the subjectLists that prefix the subject with a tag, add unsubscribe headers or append a footer break signatures on every message they handle. This is precisely the problem ARC was designed to work around, and 5.7.29 covers the ARC failure case separately.
Content conversion at a gatewayDowngrading eight-bit content to seven-bit, re-encoding an attachment or reflowing long lines all change bytes the signature covered. Gateways bridging to older systems do this quietly and consider it correct behaviour.
Genuine corruption or truncation in transitUncommon on modern networks but not impossible, particularly where a message passes through an antivirus scanner that rebuilds attachments. If the failure is intermittent on large messages only, this is worth investigating before the policy explanations.

How to fix SMTP error 5.7.7

Establish whether only signed mail is affectedSend a signed and an unsigned message on the same route to the same recipient. If only the signed one fails, you have confirmed the problem is modification in transit rather than anything about the route itself.
Reorder your transport rules so nothing edits a signed messageApply disclaimers and footers before signing, or exempt signed messages from them entirely. In Exchange Online this means an exception on the rule rather than removing the rule, so the rest of the organisation is unaffected.
Exempt the affected correspondents from URL rewritingWhere a partner sends you S/MIME signed contracts, a targeted Safe Links exclusion for that sender preserves verification without weakening protection for everyone else. Document why the exclusion exists so a later reviewer does not remove it.
Compare copies of the same message at two hopsExport the message as it left your tenant and as it arrived, then diff the raw source. Whatever differs is your answer, and it is usually a single added block of text.
Agree the path with any partner requiring end-to-end signingA rewriting gateway and genuine end-to-end integrity are hard to reconcile. Where a legal or finance counterparty insists on verifiable signatures, decide deliberately which protection matters more on that route rather than discovering the conflict during a deal.

Fixing the underlying problem

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

Questions about SMTP error 5.7.7

Does this mean somebody tampered with our message?

It means the content changed after it was signed. In practice that is nearly always your own footer rule or a security gateway doing its job, not an attacker. Investigate the boring explanations first, but do not dismiss it entirely if the affected messages are financial and the modification cannot be accounted for.

Why does adding a company disclaimer break signatures?

Because a signature is a calculation over the exact bytes of the message. Appending anything changes those bytes, so the calculation no longer matches and the verifier reports a failure. The fix is sequencing: everything that edits the message has to happen before it is signed.

Can this code appear on a message that was actually delivered?

Yes, which makes it unusual. The registry permits a 2 in the leading position, so a system can accept and deliver a message whilst noting that it could not confirm integrity. If you see the success form, treat it as a warning worth chasing rather than an incident.

Related SMTP status codes

Source. SMTP error 5.7.7 Message integrity failure is defined in RFC 3463 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