TL;DR
Permanent relay failure: a REQUIRETLS message could not be forwarded because no next-hop server supports it. Enable REQUIRETLS on the path or change routing before retrying. TLS policy gaps block secure delivery and can hurt reputation. Do not retry unchanged.
What this code means
When no eligible next-hop SMTP server advertises REQUIRETLS, a REQUIRETLS-required message cannot be relayed; registry pattern X.7.30 returns that break as code 5.7.30. Permanent-failure class framing comes from the leading digit in the enhanced status register. The subcode describes a TLS policy continuity break on the forwarding path, not recipient address rejection. The code alone does not identify which hop lacks REQUIRETLS support, whether routing or server configuration must change, or whether the REQUIRETLS requirement should remain on the message.
Provider examples
550 5.7.30 This message was blocked because it didn’t pass DKIM authentication. Gmail requires bulk email senders to authenticate their email with DKIM. Authentication results: DKIM = did not pass To set up DKIM for your sending domains, visit Set up DKIM. To learn more about Gmail requirements for bulk email senders, visit Email sender guidelines. - gsmtpTechnical meaning
Messages received with a REQUIRETLS requirement that cannot be forwarded because none of the SMTP servers to which they should be forwarded supported REQUIRETLS match X.7.30. Code 5.7.30 assigns the result to the permanent-failure class through its leading digit.
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
These sources define what this enhanced status code means, mainly through the IANA registry and related RFCs. When provider examples appear on the page, they come from that provider's published documentation. Follow the links to read the original wording in context.
- SMTP Enhanced Status Codes — IANA registry of enhanced mail system status codes.
- RFC 5248 — A Registry for SMTP Enhanced Mail System Status Codes — Creates and governs the IANA enhanced status code registry.
- RFC 2034 — SMTP Service Extension for Returning Enhanced Error Codes — Defines how SMTP returns enhanced status codes to clients.
- RFC 8689 — SMTP Require TLS Option — SMTP option requiring TLS for message delivery.
- Gmail SMTP errors and codes — Official Gmail Help table of SMTP error messages and status codes.
Last verified:
