A mail client reports that it cannot connect, and the message covers four different problems: wrong settings, a blocked port, a certificate it will not accept, or a server that is genuinely down.
One command tells you which half you are in.
Test the server directly
openssl s_client -connect mail.example.com:993 -servername mail.example.com
If the server answers: you see a certificate and an IMAP greeting: the server, the network path and the certificate are all fine. The problem is in the client's settings.
If nothing happens, the port is blocked or the server is unreachable, and no amount of adjusting the client will help.
Run it from the same network as the person reporting the problem where possible. A block on their office network is invisible from anywhere else.
The ports
993 for IMAP over TLS. 995 for POP3 over TLS. 465 for sending over TLS. 587 for sending with STARTTLS.
Port 587 begins unencrypted and upgrades, so the test command needs to know:
openssl s_client -connect mail.example.com:587 -starttls smtp
The plain ports (143, 110, 25) should not be used and are frequently blocked outright by networks and providers.
Port and encryption must match
This is the commonest settings error. Choosing port 993 with STARTTLS, or 587 with implicit TLS, fails, and the client reports it the same way it reports everything else.
993 and 465 expect encryption from the first byte. 587 expects a plain connection that upgrades. Pair them correctly and most of these reports resolve.
The hostname
Customers naturally enter mail.theirdomain.com. That works only if the certificate covers it, and frequently the server presents its own hostname certificate instead, producing a warning about the server's identity that many people click through.
Giving customers the server's hostname avoids it entirely, because that is the name on the certificate being presented, service certificates and the server hostname walks through why, and SSL for subdomains and mail explains the alternative of covering their name properly.
The username
Nearly always the full email address, not the part before the at sign.
A client set up with just the prefix fails authentication, and the error says the password is wrong, which sends everyone to reset a password that was correct.
When authentication really is failing
If the connection succeeds and the login does not, and the address is entered in full, check whether the account is blocked.
Repeated failed attempts trigger automatic blocking, and a mail client retrying every few minutes with an old password reaches that threshold quickly, and re-blocks itself immediately after each release. cPHulk brute force protection goes into finding and releasing it, and the underlying cause is usually a second device nobody mentioned.
When one device works and another does not
That is conclusive: the server is fine.
Compare the two configurations field by field. The difference is almost always a port, an encryption setting or the username form.
A phone that works on mobile data and fails on office wireless is a network block on that office, not a mail problem, port 587 outbound is blocked on a surprising number of corporate and hotel networks.
When it worked yesterday
Four candidates, in order of likelihood.
A password changed somewhere and not on every device. A certificate renewed and the client is refusing the new chain. The account is over quota, which some clients report as a connection failure. Or the server's clock drifted enough to make the certificate appear invalid. Why a server clock matters goes into that one.
The email troubleshooting guide deals with the case where connection succeeds and messages still do not arrive, which is an entirely different investigation.
Read what the server says during the handshake
The connection test does more than confirm the port is open. The server announces what it supports, and that answers several questions at once.
openssl s_client -connect mail.example.com:993 -servername mail.example.com </dev/null 2>/dev/null | tail -20
Look for the certificate's subject, which tells you which name the client must be configured with, and the verification result, which tells you whether the client will accept it.
On the submission port, the server lists its supported authentication methods after STARTTLS:
openssl s_client -connect mail.example.com:587 -starttls smtp </dev/null 2>/dev/null | grep -i 'auth'
A client configured for a method the server does not offer fails with a password error, which sends everyone to reset a password that was correct.
Send a message by hand
When authentication is the question, testing it directly removes the client from the equation entirely.
printf '%s' '[email protected]' | openssl base64 printf '%s' 'thepassword' | openssl base64
Then, in an interactive session on port 587 with -starttls smtp, issue AUTH LOGIN and supply those two encoded values when prompted. A 235 response means the credentials are correct and the problem is the client's configuration.
Do this on an account you control instead of a customer's, and note that the encoding is not encryption. It is a transport format, and the connection's own encryption is what protects it.
Autodiscovery is frequently the culprit
Modern clients try to configure themselves from DNS before asking the user anything, and a stale record sends them somewhere wrong, while the settings the user was given are perfectly correct.
dig autodiscover.example.com CNAME +short dig _autodiscover._tcp.example.com SRV +short dig autoconfig.example.com A +short
A record left over from a previous mail provider produces the specific symptom where manually entered settings work and automatic setup does not, and new staff, who use automatic setup, are the ones affected.
Remove records belonging to providers no longer in use. Splitting DNS between website and email providers goes into which records the current provider needs.
Check the mailbox is not simply full
An over-quota mailbox produces connection and authentication errors on some clients in place of a clear message.
quota -s 2>/dev/null du -sh ~/mail/example.com/user 2>/dev/null
It is a thirty-second check that explains a surprising share of "it suddenly stopped working" reports, and no amount of settings adjustment resolves it.
The same applies at the account level in place of the mailbox: a full hosting account refuses incoming mail entirely. Managing mailbox quotas deals with finding what filled it.