Enhanced Status Code 5.7.14: Trust Relationship Required
Enhanced Status Code 5.7.14 means “Trust Relationship Required.” The submission server will not accept this message without a configured trust relationship with a third party. In practice most people meet this as Gmail asking you to sign in through a browser before an application is allowed to send.
534 5.7.14 Please log in via your web browser and then try againWhat does 5.7.14 mean?
Enhanced status code 5.7.14 means a trust relationship is required. RFC 5248 registers it for a submission server that requires a configured trust relationship with a third-party server before it will relay, typically as part of an authorization step that has not been completed.
The form nearly everyone actually encounters is Gmail returning 534 5.7.14 with a message asking you to log in through your web browser and try again. That is Google interrupting an authentication that looked automated or unfamiliar and demanding an interactive step: approving a new device, completing a security challenge, or moving the application to OAuth 2.0 rather than a raw password. The message is not rejected because it is unwelcome, it is rejected because the trust between your application and the account has not been established yet.
The practical fix is nearly always to stop authenticating with a bare account password. Applications that hold a user password are exactly what this challenge exists to stop, and both Google and Microsoft have been steadily removing that path. Moving to OAuth 2.0, or to a purpose-built relay or app password where OAuth is not available, removes the class of failure rather than clearing it once.
How 5.7.14 plays out
5.7.14 rejectionWhere 5.7.14 sits: soft vs hard bounce
| Soft bounce (4xx) | Hard bounce (5xx) | |
|---|---|---|
| Nature | Temporary | Permanent |
| SMTP class | 4xx | 5xx |
| What to do | Let it retry | Suppress the address |
| Recoverable? | Often | No |
| 5.7.14 is | ✓ this code |
What each provider means by 5.7.14
A registered code does not oblige a provider to use it that way, and the large ones diverge. Match the wording in your own bounce, not the definition above.
Common causes of 5.7.14
- An application is authenticating with a raw account password rather than OAuth 2.0
- Google has flagged the sign-in as unfamiliar and is demanding an interactive challenge
- A new device, host or IP address is authenticating against the account for the first time
- The account has two-step verification enabled and the application is not using an app password
- A submission server requires a trust relationship with a third-party service that is not configured
- The authorization was granted once and has since been revoked or expired
How to fix 5.7.14
- Move the application to OAuth 2.0 rather than storing an account password
- Sign in to the account through a browser once to clear the pending challenge
- Where OAuth is not available, issue an app password instead of using the account password
- Send through a dedicated relay or transactional provider rather than a personal mailbox
- Check the account security activity log for a blocked or unverified sign-in
- Confirm the sending host is stable, since a rotating IP repeatedly looks like a new device