What this code means
The message was received with a REQUIRETLS requirement but could not be forwarded because none of the destination SMTP servers provided that support. Code 5.7.30 denotes a permanent failure of the current attempt.
Technical meaning
The standard X.7.30 pattern means that a message received with a REQUIRETLS requirement could not be forwarded because none of the SMTP servers to which it should be forwarded supported REQUIRETLS. In code 5.7.30, the leading digit assigns the result to the permanent-failure class.
Delivery status
The leading digit 5 denotes a permanent failure of the current attempt. Without a confirmed change to handling or routing, another identical attempt will encounter the same lack of REQUIRETLS support.
- 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 message and route. Consider a new, controlled attempt only after confirming that the corrected forwarding path supports REQUIRETLS and checking suppression again.
Suppression decision
Operational guidance: do not automatically suppress the recipient address or domain based on 5.7.30 alone. Inspect the complete response, event scope, forwarding path, and delivery history, then base the suppression decision on the confirmed cause and applicable policy.
Common causes
- The message carried a REQUIRETLS requirement, and none of the SMTP servers available for forwarding it provided that support.
Diagnostic steps
- Inspect the raw SMTP response or nondelivery report, confirm the exact 5.7.30 code and a basic reply in the 5xx class, and retain the complete response text.
- Correlate the response with the intended message, attempt time and stage, system that returned the code, and planned next forwarding step.
- Use logs and configuration to confirm that the message was received with a REQUIRETLS requirement and determine whether the SMTP servers available for forwarding actually support it; do not attribute a specific provider failure from the code alone.
- Stop unchanged retries. After a confirmed routing or support correction, check REQUIRETLS and suppression again, then make at most one controlled attempt.
Actions by owner
Sender
- Do not manually retry the same unchanged message; confirm that the protection requirement remains intended, then give the sender administrator the complete response and attempt time.
Sender administrator
- Retain the complete response, trace the forwarding stage, and use available logs and configuration to confirm the REQUIRETLS requirement and support across possible next-hop servers.
- Make only a confirmed routing or support correction, check REQUIRETLS and suppression again, and verify the result with one controlled attempt.
Recipient administrator
- If you manage the system that returned the code or the receiving next hop, inspect route selection and REQUIRETLS support for the specified attempt; correct a confirmed problem or safely give the sender the context needed for remediation.
Provider
- If you operate a managed forwarding layer, inspect its logs, route selection, and REQUIRETLS support, correct a confirmed problem in that layer or give the appropriate administrators precise diagnostic context, and do not trigger suppression from the code alone.
Sources and verification
The standard meaning of X.7.30 and its class-5 application were verified against the IANA registry and RFC 2034, RFC 5248, and RFC 8689 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.30
- 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
- rfc8689T0 source
IANA registry reference for X.7.30
Last verified:
