Something is wrong with mail and a port is closed. Before changing anything, work out which direction of mail flow that port is even involved in, because the answer is often neither.
Receiving mail and sending mail are separate services on separate ports. They fail independently, and a closed port on one side tells you nothing about the other.
The three ports
| Port | Direction | Encryption | Who connects |
|---|---|---|---|
| 25 | Inbound delivery | STARTTLS, opportunistic | Other mail servers, sending you mail |
| 465 | Outbound submission | Implicit TLS, encrypted from the first byte | Your users and applications |
| 587 | Outbound submission | STARTTLS | Your users and applications |
So:
- Port 587 or 465 closed: your clients cannot send through this server. Inbound mail is unaffected.
- Port 25 closed or refusing: you are not receiving mail. This is the one that loses you messages.
- Port 25 open with no STARTTLS: you receive mail, but some of it arrives unencrypted across the internet.
Many hosting providers block outbound port 25 from their networks by default to limit spam, which is a frequent and entirely separate source of confusion when an application cannot send mail.
Check what is actually listening
# Inbound delivery, and whether it offers STARTTLS
openssl s_client -starttls smtp -connect mx.example.com:25 -crlf </dev/null 2>&1 | head -20
# Submission, implicit TLS
openssl s_client -connect mail.example.com:465 -crlf </dev/null 2>&1 | head -20
# Submission, STARTTLS
openssl s_client -starttls smtp -connect mail.example.com:587 -crlf </dev/null 2>&1 | head -20Find your receiving hosts first, and check every one of them rather than only the first:
dig +short MX example.comCheck every MX, not just the primary
Backup MX hosts are where TLS quietly rots. They are configured once, rarely tested, and then a sending server fails over to one during an incident and delivers your mail over an unencrypted connection, or to a host presenting an expired certificate.
If a domain has four MX records, all four are real delivery destinations as far as the sending world is concerned. Test them as such.
STARTTLS is opportunistic, which is the catch
On port 25, STARTTLS is an offer rather than a requirement. A sending server asks whether encryption is available and proceeds either way. If your server does not advertise it, mail still arrives, just in plain text.
That is why “mail is working” and “mail is encrypted in transit” are separate questions, and why the fix for a missing STARTTLS is never visible to your users. Enforcing encryption for inbound mail is what MTA-STS and DANE are for. Both are covered in SPF, DMARC, MTA-STS, TLS-RPT, and DANE.
For the full set of mail transport observations and what each listener state means, see mail routing and TLS transport.