5.7.30: REQUIRETLS not supported by the next server
The message was sent with a REQUIRETLS requirement, and none of the servers it had to go through next supports that requirement, so it was returned.
- Standard
- Provider
- Permanent (5xx)
- Class
- Sources checked
- Author
At a glance
- Code
- 5.7.30
- Provider
- Standard SMTP codes
- Temporary or permanent
- PermanentRefused for good: the message comes back to the sender, and resending it gets the same answer.
- Who has to act
- The sender. The fix is on the sending side: your domain, your server or your list.
- What the server says
5.7.30 REQUIRETLS support required
What it means
REQUIRETLS (RFC 8689) lets a sender demand that a message travel only over TLS-protected connections, to servers that also honour the requirement. If none of the next servers supports REQUIRETLS, the message cannot go on, and RFC 8689 says the non-delivery notice should use 5.7.30. If a TLS-protected session could not be set up at all, the code is 5.7.10 instead. The sender can resend without REQUIRETLS, where the content allows it, or reach the recipient another way.
Common causes
- The recipient's mail servers do not offer the REQUIRETLS extension.
- A relay on the path does not support REQUIRETLS.
How to fix it
- 01Decide whether the content needs REQUIRETLS; if not, resend without it.
- 02Ask the recipient whether their provider supports REQUIRETLS.
- 03If you run the relay, enable REQUIRETLS support or route these messages another way.
Sources
What this page rests on, checked on 20 Oct 2026. The explanation is ours; the reply text is the server's.
Related codes
5.7.30 at other providers
Further reading
All 105 standard codesEvery code in the wikiPaste your own bounce