5.7.10: encryption required but the connection could not use TLS

What the bounce means

5.7.10 reports a security requirement the connection could not meet: encryption was required, and the TLS session either failed or was never on offer. In the canonical case the receiving server requires an encrypted connection that could not be established. You will also see the code in bounces generated on the sending side, when a forced-TLS policy at your own gateway refuses to hand mail to a destination that cannot do TLS. Either way, the message was not sent in the clear; it was refused. Because this is a generic code rather than one provider's string, the three-digit reply in front of it varies by server; it usually appears as 550 5.7.10 or 554 5.7.10, and the enhanced code is the part to trust.

The leading 5 makes it permanent for this message: retries against the same broken TLS path fail the same way until someone fixes the path.

Why it happens

• An expired or invalid certificate on the receiving MX. The server offers STARTTLS, but its certificate has lapsed or does not match, and a sender that insists on valid TLS refuses to proceed. This is the most common cause, and it is entirely on the receiving side.
• A forced-TLS policy at the sender. Many organizations require TLS for specific partner domains (common in finance, legal, and healthcare). When the destination cannot negotiate it, the sending gateway bounces the message rather than downgrade to plaintext.
• An old server with no STARTTLS at all. A legacy or misconfigured MX that never advertises STARTTLS cannot satisfy anyone's encryption requirement, so every TLS-requiring sender bounces against it.

How MTA-STS raises the stakes

SMTP's original sin is that TLS on the mail path was opportunistic: if the handshake failed, senders quietly fell back to plaintext. MTA-STS (RFC 8461) exists to close that hole. A domain that publishes an MTA-STS policy in enforce mode is telling every sender: do not deliver to me over an unencrypted or invalidly-certified connection, refuse instead. That turns a certificate lapse on the receiving MX from a silent downgrade into hard bounces, which is exactly the failure 5.7.10 describes. Our plain-English guide to MTA-STS and TLS-RPT covers how the policy works, and the free MTA-STS validator shows any domain's policy, its mode, and whether its MX certificates match.

How to check and fix

• Test the receiving MX's STARTTLS. Connect to the recipient's MX on port 25 and check whether STARTTLS is advertised and whether the handshake completes. If it is not offered, or the session fails, the receiving server needs fixing before any sender requiring TLS can deliver.
• Check the certificate. Look at the MX certificate's expiry date and whether its name matches the host the MX record points at. An expired or mismatched certificate fails strict senders and every MTA-STS-enforcing path even though casual connections still work.
• If the bounce came from your own gateway, the forced-TLS policy is yours. Confirm the destination genuinely cannot do TLS before relaxing anything; the better outcome is usually the recipient repairing their MX.
• If you run the receiving domain, enable TLS-RPT. TLS-RPT gives you daily reports from senders about TLS failures against your MX, so a lapsed certificate shows up in data instead of as other people's bounces you never see.

Frequently asked

What does 5.7.10 mean?

One side of the delivery required an encrypted (TLS) connection and the connection could not provide one, so the message was refused rather than sent in the clear. Canonically the receiving server requires encryption that could not be established; the same code also shows up when a forced-TLS policy on the sending side refuses to deliver without TLS.

Is 5.7.10 my problem or the recipient's?

Usually the receiving side: an expired or invalid certificate on their MX, or an old server that does not offer STARTTLS. But verify before you act. If your organization enforces a forced-TLS policy for that destination, your own gateway may be generating the bounce, and relaxing or scoping that policy is a sending-side decision.

What does MTA-STS have to do with 5.7.10?

A domain that publishes an MTA-STS policy in enforce mode tells senders to refuse any delivery path that cannot do valid TLS: no encryption, and no certificate that does not match the policy. That converts what used to be a silent downgrade to plaintext into a hard refusal, which is exactly the failure 5.7.10 reports.

How does TLS-RPT help with these failures?

TLS-RPT lets a receiving domain publish an address where senders report their TLS failures. If you run the receiving domain, enabling it gives you daily reports showing who could not negotiate TLS with your MX and why, so an expired certificate or a broken STARTTLS response surfaces in data instead of in missing mail.