SMTP error 5.7.30 REQUIRETLS support required

What SMTP error 5.7.30 means

The message was submitted carrying a REQUIRETLS flag, an explicit instruction that it must only travel over TLS to servers supporting that extension, and the next hop does not support it. Rather than quietly downgrade, the server refuses and returns 550 5.7.30. You are unlikely to meet this in normal business mail: REQUIRETLS is barely deployed and none of the mainstream platforms turn it on by default.

Security or policy status
Sent by A relay, or the receiving server, unable to meet a TLS requirement attached to the message
Rare

What SMTP error 5.7.30 REQUIRETLS support required actually means

Ordinary SMTP encryption is opportunistic. If the far end offers STARTTLS the connection is encrypted, and if it does not, the message goes anyway in the clear. RFC 8689 lets a sender declare that this is unacceptable for a particular message and that failing to encrypt should produce a bounce instead of a plaintext delivery. That is a genuinely valuable property for sensitive material, and it only works where every hop implements it, which most do not. Registered as permanent only, which is the point: the whole design is to fail rather than degrade. If your actual goal is guaranteed encryption between two organisations, the mechanisms in real use are MTA-STS, DANE and a forced TLS connector between named domains.

This indicates that the message was not able to be forwarded because it was received with a REQUIRETLS requirement and none of the SMTP servers to which the message should be forwarded provide this support.
— RFC 8689

How 5.7.30 appears in a bounce

A server reporting this condition sends it alongside a three-digit reply code, and a bounce prints the two together. The registry lists 550 5.7.30 as the pairing for this status.

The leading 5 is the server's verdict rather than part of the code's identity: it marks this as a permanent failure, which means the sending server has given up and returned the message.

What causes SMTP error 5.7.30 on a business phone system

A sending client or gateway setting the requirementSomething in the submission path is adding REQUIRETLS, usually a specialist secure messaging product or a deliberately configured connector. Ordinary mail clients do not do this on their own.
A relay in the path without support for the extensionThis is the overwhelming reason. Adoption is thin, so the first intermediary that does not implement it has no lawful option other than to refuse the message and say so.
A receiver offering STARTTLS but not REQUIRETLSEncrypting the connection and supporting the requirement are two separate capabilities. A receiver can accept a perfectly good TLS session and still be unable to honour the guarantee the sender asked for.
A security gateway that terminates and re-originatesWhere a hosted filtering service breaks the connection and creates a new one, the requirement can be lost or become impossible to carry forward. The message then fails at a point that looks unrelated to where it was set.
A distribution list expanding to an unsupported recipientOne address behind an older server is enough. The list expands, one branch cannot meet the requirement, and that branch bounces while the rest deliver normally.

How to fix SMTP error 5.7.30

Confirm something really is setting the requirementCheck the submission path and the headers of a failing message before assuming anything. Given how rarely this is enabled, finding what turned it on is most of the work.
Use a forced TLS connector between the two organisationsWhere you need guaranteed encryption to one named partner, a connector configured to require TLS with certificate validation is supported everywhere and does the job. This is what a Microsoft 365 tenant would normally use.
Publish MTA-STS and TLS reporting for inbound mailMTA-STS is the mechanism senders actually honour when you want to insist that mail to you is encrypted, and TLS-RPT gives you reports on what happened. Both are DNS and a policy file rather than a product.
Encrypt the message rather than the transport for genuinely confidential materialTransport encryption protects the hop, not the content at rest. Message-level encryption or a secure portal gives a guarantee that does not depend on what every intermediate server supports.
Turn the requirement off where delivery matters moreIf a business process is bouncing because of a flag nobody knowingly enabled, remove it and rely on opportunistic TLS plus MTA-STS. Failing closed is only useful when it is a decision somebody made deliberately.

Fixing the underlying problem

This page explains the code. These guides walk through the fix in detail.

Questions about SMTP error 5.7.30

Does this mean our email went out unencrypted?

The opposite. The server refused to send it at all rather than send it without the encryption guarantee it was asked for. Nothing left in the clear, which is exactly the behaviour the sender requested when the flag was set.

Should we enable REQUIRETLS across our mail?

No. Deployment is too thin for it to be practical on general business correspondence and you would spend your time investigating bounces. Use MTA-STS for inbound and a forced TLS connector for the specific partners who need one.

How does this differ from 5.7.10?

They sit at different points in the conversation. 5.7.10 is a submission-time response saying a privacy layer must be established before that authentication mechanism can be used. This one concerns relaying a message onwards and the next server's inability to honour a requirement already attached to it.

Related SMTP status codes

Source. SMTP error 5.7.30 REQUIRETLS support required is defined in RFC 8689 and registered in the IANA SMTP Enhanced Status Codes registry. The causes and fixes above are drawn from our own experience supporting UK business email systems.

All Email delivery & SMTP codes