The four usual causes
- No shared protocol version. Current servers refuse TLS 1.0 and 1.1, while older peers cannot do TLS 1.2. If no version is left, the handshake ends immediately. This is now the single most common cause.
- No shared cipher suite. Rarer, but possible when one side is limited to modern AEAD suites and the other offers only old CBC ones.
- An incomplete certificate chain. The server sends only its own certificate without the intermediate. Some clients fill that in themselves, others abort. A test that works locally but not from outside almost always points here.
- A middlebox interferes. Firewalls with SMTP inspection mangle the
EHLOresponse or theSTARTTLScommand in order to read along. Recognisable when the server offers no STARTTLS from outside but does so on the machine itself.
Reproducing it yourself
The handshake can be tested on its own, without sending a message:
openssl s_client -starttls smtp -connect mx.example.com:25 -crlf
Worth reading in the output:
Protocol / Cipher → what was negotiated
Verify return code → 0 (ok) or a chain error
Certificate chain → does it include the intermediate?
If there is no output at all, the peer does not support STARTTLS or something in between strips it. A plaintext EHLO shows whether 250-STARTTLS is announced in the first place.
When TLS is mandatory
The message “TLS is required, but was not offered” is a different case: here your side has configured mandatory TLS while the peer offers none. That may be a deliberate policy — or an MTA-STS policy or DANE record demanding encryption while the target server currently fails to provide it.