Enhanced Status Code 5.7.30: REQUIRETLS Support Required

Permanent failure Medium severity Security RFC 8689

What it means

Enhanced Status Code 5.7.30 means “REQUIRETLS Support Required.” 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.

At a glance

Code5.7.30

Bounce typeHard (permanent)

SeverityMedium

CategorySecurity

What to doSuppress the address; do not retry

StandardRFC 8689

What it looks like in your mail logs

550 5.7.30 REQUIRETLS is required, but the next hop does not support the REQUIRETLS SMTP extension; message not relayed.

What does 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.

How 5.7.30 plays out

Your server attempts delivery

The recipient server returns a permanent 5.7.30 rejection

This is a hard bounce: the message will not be accepted as sent

Suppress the address and fix the root cause before resending

Where 5.7.30 sits: soft vs hard bounce

	Soft bounce (4xx)	Hard bounce (5xx)
Nature	Temporary	Permanent
SMTP class	`4xx`	`5xx`
What to do	Let it retry	Suppress the address
Recoverable?	Often	No
5.7.30 is		✓ this code

Common causes of 5.7.30

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 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

What does error 5.7.30 "REQUIRETLS support required" mean?

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.

What is REQUIRETLS and how is it different from STARTTLS?

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.

How do I fix a 5.7.30 REQUIRETLS error?

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.

Which email providers 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.

Related bounce codes

Sources & further reading

RFC 8689 · The standard that defines this reply code

Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← All bounce codes