What this code means
The submission server permanently refused the attempt because access to the message content requires a configured trust relationship with a third-party server. Do not retry the same unchanged attempt.
Technical meaning
The standard X.7.14 pattern means that the submission server requires a configured trust relationship with a third-party server in order to access the message content. It replaces the prior use of X.7.8 for this condition; code 5.7.14 applies this detail in class 5.
Delivery status
The leading digit 5 denotes a permanent failure of the current attempt. An unchanged retry will not establish the required trust relationship; the code alone identifies neither the third-party server, the required configuration, nor the owner of the fault.
- Class
- Permanent failure
- Retry
- Do not retry unchanged
- Suppression
- Check the full context
Retry decision
Operational guidance: stop automatic and manual retries of the same unchanged attempt. Consider a new, controlled attempt only after confirming the proper trust relationship or correcting its configuration; check suppression again first.
Suppression decision
Operational guidance: do not automatically suppress the address or domain based on 5.7.14 alone. Inspect the complete response, the systems involved in the attempt, their configuration, and the event history, then make the suppression decision according to the confirmed cause and applicable policy.
Common causes
- The trust relationship required between the submission server and the third-party server for access to the message content was not configured.
Diagnostic steps
- Inspect the raw SMTP response and confirm that the enhanced code is exactly 5.7.14 and that the basic reply is in the 5xx class; retain the complete response text.
- Correlate the response with the attempt time, submission server, and third-party server used to access the content; inspect safe logs and the trust-relationship configuration instead of inferring those details from the code alone.
- Stop unchanged retries; before one controlled attempt, confirm that the required relationship was established or corrected, check suppression again, and compare the result.
Actions by owner
Sender
- Do not manually retry the same attempt; give the administrator the complete response and event time without exposing message content or secrets.
Sender administrator
- Use logs and configuration to identify the submission server, third-party server, and required trust relationship, then coordinate the correction with the owner of the relevant system.
- After a verified correction, check suppression again and make one controlled attempt instead of repeating the unchanged submission.
Recipient administrator
- If you manage a server involved in content access, inspect its logs and trust-relationship configuration for the specified attempt, then correct only a confirmed problem.
Provider
- If you operate the submission server or third-party server, inspect the expected trust relationship and safely identify a confirmed gap or configuration requirement for the administrators; do not trigger automatic suppression from the code alone.
Sources and verification
The canonical Tier-0 meaning of X.7.14, its replacement of the prior X.7.8 use for this condition, and the class-5 application of code 5.7.14 were verified against the IANA registry, RFC 2034, and RFC 5248 as of July 17, 2026. Diagnostic, remediation, retry, and suppression recommendations are separate operational guidance; this record contains no provider-specific practice.
- iana-smtp-enhanced-status-codesT0 source
Enumerated Status Codes / X.7.14
- rfc5248T0 source
Section 2.1: registry fields and non-exclusive Associated Basic Status Code
- rfc2034T0 source
Section 4: enhanced status class agrees with SMTP reply class
Last verified:
