SMTP error 5.7.14 Trust relationship required

What SMTP error 5.7.14 means

The submission server required an established trust with another system in order to reach the message content, and no such trust is configured. Reported as 535 5.7.14 or 554 5.7.14, it is a narrow condition from the message submission world and it replaced an earlier, overloaded use of 5.7.8 for the same situation. There is a separate reason people land here: Google uses the same digits for something entirely different, a prompt to sign in through a browser, which is not the registered meaning and is why searches for this code so often lead somewhere confusing.

Security or policy status
Sent by A submission server that needs a configured relationship with a third-party system
Rare

What SMTP error 5.7.14 Trust relationship required actually means

Ordinarily a client hands a complete message to a submission server. There is an alternative design in which the client points at content already held elsewhere, typically in an IMAP store, and asks the submission server to fetch and send it. That only works if the two systems have been introduced to one another, and this code is the submission server reporting that they have not. Very few deployments use the mechanism, which is why the code is genuinely rare rather than merely unfashionable. If you have arrived here from a Google client error using the same digits, that is Google's own use of the number and it means the account needs an interactive browser sign-in to prove who you are; it has nothing to do with a configured trust between servers.

The submission server requires a configured trust relationship with a third-party server in order to access the message content. This value replaces the prior use of X.7.8 for this error condition. thereby updating [RFC4468].
— RFC 5248

How 5.7.14 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 these pairings for this status: 535 5.7.14, 554 5.7.14. Which one you get depends on the point in the conversation at which the server refused.

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.14 on a business phone system

A submission service with no relationship to the content storeWhere a client submits by reference rather than by value, the submission server must be able to authenticate to the store holding the message. Missing or expired configuration between the two produces this, and it fails for every message rather than intermittently.
A gateway asked to use a key or signing service it is not enrolled withEncryption and signing appliances sometimes depend on a separate key service. If enrolment lapses or a certificate is not renewed, the gateway can authenticate the user perfectly and still be unable to act on the message.
Google's unrelated use of the same digitsA client signing in from an unfamiliar location, or one Google does not recognise, may be told to complete a browser sign-in. It uses this number for that purpose. Registered meaning and observed meaning simply differ here, and no amount of server configuration is relevant.
A bespoke integration built against the submission extensionDocument management and case management systems occasionally implement submission by reference to avoid copying large attachments. When one of those integrations breaks, this is how it reports.

How to fix SMTP error 5.7.14

Work out which system actually produced the replyThe hostname in the response settles immediately whether you are dealing with the registered condition or with Google using the number its own way. Everything else follows from that one fact.
For a Google client, complete a browser sign-in on the accountSign in from a browser as that user, satisfy whatever verification is presented, then retry the client. If the client is doing this repeatedly, move it to OAuth rather than continuing to approve it by hand.
For a genuine submission trust, configure both endsThe submission server needs credentials or a certificate for the content store, and the store needs to accept them. Check expiry dates first, since a lapsed certificate produces this without anybody having changed a setting.
Where nobody can account for it, treat it as an undefined security failureFall back to the approach for 5.7.0: capture the full reply line, identify the software at the far end, and search on its wording rather than on the number. An unexpected sighting of this code usually means a vendor has reused it.

Fixing the underlying problem

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

Questions about SMTP error 5.7.14

Google told our client to log in via a web browser — is that this code?

Those are the same digits used for a completely different purpose. The registered meaning is about a trust relationship between servers, whilst Google is asking a human to verify the account interactively. Follow Google's instruction and ignore everything about server trust configuration.

Should we ever expect this on Microsoft 365?

Practically never. The submission mechanism it describes is barely deployed anywhere, and Exchange Online reports authentication and authorisation problems through 5.7.8 and 5.7.13 instead. Seeing it on a 365 tenant would be genuinely unusual and worth a closer look at what is actually in the path.

Is the failure permanent?

The registry only permits the permanent class for it, so the sending client should not keep retrying. In the Google case the underlying situation clears the moment somebody completes the verification, even though the reply itself was reported as permanent.

Related SMTP status codes

Source. SMTP error 5.7.14 Trust relationship required is defined in RFC 5248 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