Skip to content
Standard SMTP codes · permanent error

5.7.14: trust relationship required

The submission server needs a configured trust relationship with another server to fetch the message content, and none is in place.

Standard
Provider
Permanent (5xx)
Class
Sources checked
Author

At a glance

Code
5.7.14
Temporary or permanent
PermanentRefused for good: the message comes back to the sender, and resending it gets the same answer.
Who has to act
The sender. The fix is on the sending side: your domain, your server or your list.
What the server says
5.7.14 Trust relationship required

What it means

This code comes from the BURL extension (RFC 4468), where a submission server fetches a message body from an IMAP server instead of having the client upload it. If the submission server has no configured trust with that IMAP server, it cannot fetch the content. RFC 4468 originally used X.7.8 for this, and RFC 5248 registered X.7.14 to replace that use. The registry associates it with replies 535 and 554. It is a configuration matter between the two servers, and ordinary senders rarely meet it.

Common causes

  • The IMAP server named in the BURL request is not one the submission server trusts.
  • A client using BURL with servers that belong to different providers.

How to fix it

  1. 01Resend so that the client uploads the message directly.
  2. 02Use the submission server and the IMAP server of the same provider.
  3. 03Mail admins: configure the trust between the submission and IMAP servers (URLAUTH access).

Sources

What this page rests on, checked on 20 Oct 2026. The explanation is ours; the reply text is the server's.

  1. 5.6.6Message content not available.During submission, the server had to fetch the message content from another system, such as an IMAP server, and could not get it.StandardPermanent
  2. 535 5.7.8Login failed: invalid credentials.The SMTP server rejected the login because the username, password or token was wrong or not sufficient, so it will not accept mail from this session.StandardPermanent

5.7.14 at other providers

  1. 534 5.7.14Sign in through a web browser first.Google refused your client's SMTP sign-in and wants the account owner to sign in through a web browser before the client tries again.GmailPermanent

All 105 standard codesEvery code in the wikiPaste your own bounce

Beat · paid monitoring

A heartbeat for your email.

Beat runs every check on this site on a schedule: 41 checks, 33 blacklists and real inbox placement. The moment something breaks, it tells you what broke, why it matters, and the exact fix.

example.comWatching
  • SPFpass
  • DKIMpass
  • DMARCp=none
  • Blacklists0 of 33

Illustrative. Your domain, every few hours.

Also from us:Pulse: your own sending infrastructureConsulting: $65/hr, no retainer