SMTP error 5.7.10 Encryption Needed

What SMTP error 5.7.10 means

You attempted to authenticate over an unencrypted connection and the server declined to accept a password in the clear. It comes back as 523 5.7.10, and the answer is nearly always to switch STARTTLS on in the client rather than to change anything on the server. Old printers, alarm panels and bespoke applications written when port 25 with no encryption was normal are the usual candidates, along with anything whose TLS support has fallen behind what the server will now negotiate.

Security or policy status
Sent by The submission server, refusing AUTH before a TLS layer has been established
Occasional

What SMTP error 5.7.10 Encryption Needed actually means

A submission server has two ways of protecting a password: refuse to advertise plain mechanisms until a privacy layer exists, or advertise them and then refuse to act on them. This code is the second. It is telling the client to establish encryption and try again, or to pick a mechanism that does not expose the password in the first place. The important practical point is that the credential was not transmitted. Whatever else has gone wrong, the password did not cross the network in the clear, so no rotation is needed on account of this failure. Where the mechanism itself is the objection rather than the missing encryption, servers use 5.7.9, and 5.7.11 is the older and narrower variant of the same encryption requirement.

This indicates that external strong privacy layer is needed in order to use the requested authentication mechanism. This is primarily intended for use with clear text authentication mechanisms. A client which receives this may activate a security layer such as TLS prior to authenticating, or attempt to use a stronger mechanism.
— RFC 5248

How 5.7.10 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 523 5.7.10 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.10 on a business phone system

STARTTLS switched off in the client configurationOn most devices this is a single checkbox or a dropdown offering none, TLS or SSL. Anything set to none, or to an automatic option that quietly falls back, will produce this. It is the first thing to look at and it is right most of the time.
The wrong port for the encryption mode chosenPort 587 expects the session to start in the clear and be upgraded with STARTTLS, whilst 465 expects TLS from the first byte. A device set to 465 with STARTTLS, or to 587 with implicit TLS, fails in ways that look like an encryption refusal.
The device only supports a TLS version the server has retiredA great many multifunction printers top out at TLS 1.0. Microsoft 365 requires 1.2 as a minimum. The handshake fails, the client falls back to an unencrypted session and the server then refuses the password, so the visible symptom is an encryption error rather than a version error.
A firewall stripping STARTTLS from the greetingSMTP inspection on some firewalls removes the STARTTLS capability from the server's EHLO response so it can read the session. The client never learns encryption was available and submits in the clear. This is worth suspecting whenever the same device works from a mobile hotspot and not from the office.
A client set to use encryption only if offeredOpportunistic settings are meant to be helpful and instead hide the failure. If nothing appears to be offered, for any of the reasons above, the client silently proceeds without it rather than stopping and telling anybody.

How to fix SMTP error 5.7.10

Set the client explicitly rather than automaticallyChoose port 587 with STARTTLS required, not an automatic or opportunistic option. Being explicit means a failure produces an error you can see instead of a silent downgrade you cannot.
Test the session from the same network by handRun openssl s_client with the starttls smtp option against the submission host from a machine on that network. If the capability appears there and not on the device, the network is fine and the device is the limitation. If it is missing from both, look at the firewall.
Turn off SMTP inspection on the firewallMail-aware inspection on a small business firewall causes far more problems than it solves now that almost all mail is encrypted in transit. Disable it for the submission port and retest before changing anything on the device.
Check what TLS version the device can actually negotiateLook for a firmware update first; many manufacturers added TLS 1.2 in a late release for hardware they no longer sell. If none exists, the device cannot be made to work with a modern submission service, and no amount of configuration will change that.
Stop authenticating the devices that cannot be brought up to standardDirect send to your tenant MX for internal-only recipients, an IP-restricted connector for external ones, or a small local relay that holds the credential on the device's behalf. All three remove the requirement for the old hardware to speak modern TLS.

Fixing the underlying problem

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

Questions about SMTP error 5.7.10

Does this mean our email is not encrypted?

It means this one submission hop was not, and the server refused to proceed because of it. Encryption between mail servers on the onward journey is a separate question with a separate answer. What this code confirms is that the server protected you: it would not take a password over a connection anybody could read.

Was our password exposed before the server refused it?

No. The refusal happens in response to the AUTH command, before any credential is sent. There is nothing to rotate as a result of this specific failure, although it is worth asking how long the device had been configured that way against a server that was more permissive.

Can we just relax the requirement at the server?

On Microsoft 365 or Google Workspace you cannot, and that is the correct outcome. On an on-premise server you technically could, and you should not. Accepting cleartext passwords on a submission service is the sort of thing that turns a printer with a stored credential into a compromised tenant.

Related SMTP status codes

Source. SMTP error 5.7.10 Encryption Needed is defined in RFC 5248 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