The message requires mandatory TLS encryption for delivery (REQUIRETLS), but the next hop in the delivery chain does not support it. The message cannot be delivered without guaranteed encryption.
What Does Error 5.7.30 Mean?
Enhanced status code 5.7.30 indicates the message has been tagged with REQUIRETLS (RFC 8689), which mandates that every hop in the delivery chain must use TLS encryption. If any server in the path does not support TLS, the message cannot be delivered and bounces with this code.
REQUIRETLS is used for highly sensitive messages where unencrypted transmission is unacceptable. It is more restrictive than opportunistic TLS (STARTTLS) because it refuses to deliver if TLS is unavailable at any hop, rather than falling back to unencrypted delivery.
Common Causes
- REQUIRETLS flag set but receiving server does not support TLS
- An intermediary relay in the delivery path does not support TLS
- TLS certificate issue on the receiving server
- MTA-STS policy conflict with REQUIRETLS requirements
How to Fix Error 5.7.30
- Verify the recipient server supports TLS
- If mandatory encryption is not needed, send without the REQUIRETLS flag
- Contact the recipient to confirm their server supports TLS
- Check for intermediary relays that might lack TLS support
Frequently Asked Questions
Error 5.7.30 means the email was sent with a REQUIRETLS directive (as defined in RFC 8689), but one or more servers in the delivery path do not support the REQUIRETLS SMTP extension. REQUIRETLS enforces mandatory TLS encryption for the entire delivery chain -- unlike opportunistic STARTTLS, it guarantees the message is never transmitted in plaintext. When a downstream server lacks REQUIRETLS support, the message is rejected rather than delivered insecurely.
STARTTLS is opportunistic -- it attempts TLS encryption but falls back to plaintext if the other server does not support it, leaving messages vulnerable to downgrade attacks. REQUIRETLS (RFC 8689) is mandatory -- it ensures TLS encryption is enforced at every hop in the delivery chain and will not permit plaintext fallback. If any server in the path cannot establish TLS, the message bounces with 5.7.30 rather than being sent unencrypted. REQUIRETLS provides stronger security guarantees but requires all servers involved to support the extension.
If you are the sender, remove the REQUIRETLS requirement from the message if end-to-end mandatory TLS is not critical for your use case. If you need REQUIRETLS, verify that the recipient's mail server supports the extension -- most servers do not yet support RFC 8689. If you are the mail server administrator, ensure your server supports TLS 1.2 or later, has a valid SSL certificate, and has the REQUIRETLS extension enabled. Check that all intermediate relay servers in your delivery path also support REQUIRETLS.
REQUIRETLS adoption remains limited as of 2026. Most major consumer email providers (Gmail, Microsoft 365, Yahoo) support STARTTLS and MTA-STS for mandatory TLS enforcement, but full RFC 8689 REQUIRETLS support is not widespread. For organizations requiring guaranteed TLS, MTA-STS (RFC 8461) and DANE (RFC 7672) are more widely deployed alternatives that enforce TLS without requiring the sending server to use the REQUIRETLS extension. Check your recipient's server capabilities before relying on REQUIRETLS.