5.7.30 bounce: REQUIRETLS support required
5.7.30REQUIRETLS support requiredPermanent: retrying will not help
550 5.7.30 REQUIRETLS support required
What it means
RFC 8689 (SMTP Require TLS Option) registered X.7.30, “REQUIRETLS support required”. A sender can mark a message with the REQUIRETLS parameter on MAIL FROM, meaning it must travel only over TLS with a validated certificate on every hop. If no next-hop server supports that promise, the message cannot be forwarded and is returned with 5.7.30.
Delivery needs two things: each MTA on the path must advertise REQUIRETLS in EHLO, and each hop must find the next server through DNSSEC-validated MX or MTA-STS and verify its certificate. One missing piece is enough to stop the message.
Few servers support REQUIRETLS today, so 5.7.30 mostly appears for senders who enabled it on purpose. The RFC also defines a TLS-Required: No header, which does the opposite and asks hops to deliver even if their TLS policy would otherwise block it.
Likely causes
- The recipient’s MX does not advertise the REQUIRETLS extension.
- An intermediate relay or filtering service that does not support REQUIRETLS, even if the final server does.
- The recipient domain lacks MTA-STS and DNSSEC, so the next hop cannot be authenticated as RFC 8689 requires.
- A certificate on the next hop that does not validate for its MX name.
How to fix it
- Check whether the recipient’s MX hosts list REQUIRETLS in their EHLO reply.
- If they do not, decide whether the message really must use REQUIRETLS; if not, resend without it, using normal STARTTLS.
- If you run the receiving side and want such mail, enable REQUIRETLS on every inbound hop and publish MTA-STS or DNSSEC-signed MX records.
- Fix any certificate name or expiry problem on the receiving MX so TLS verification can pass.
Checks that apply
- SMTP Diagnostics Shows the receiving server’s EHLO extensions and certificate, including whether REQUIRETLS is advertised.
- MTA-STS Check Checks the recipient’s MTA-STS policy, one way the next hop can be authenticated for REQUIRETLS.
- DNSKEY Lookup Shows whether the recipient zone is DNSSEC-signed, the other route to an authenticated MX.
FAQ
- Did I turn on REQUIRETLS by accident?
- Possibly, if your client or gateway has a “require TLS for this message” option. Plain STARTTLS settings do not set REQUIRETLS.
- Is 5.7.30 the same as a TLS failure?
- No. TLS may work fine; 5.7.30 says the next server cannot promise to keep TLS for every later hop.