Why won't my email send? A fast SMTP diagnostic guide

"My email won't send" is not one problem, it is at least three, and each one has a completely

different cause. Before touching any settings, work out which of these three you actually have -

it takes under five minutes and prevents hours of fixing the wrong thing.

Problem 1: the connection never happens

If your mail client or script reports a timeout, "could not connect", or "connection refused"

*before* any SMTP reply text appears, you have a network problem, not an email problem. Common

causes: your ISP or hosting provider blocks outbound port 25 (extremely common on residential

connections and many cloud platforms by default), a local firewall or antivirus is intercepting

the connection, or you have the wrong port for the intended encryption mode (25, 465, and 587 all

behave differently).

$ nc -zv smtp.example.net 587
nc: connect to smtp.example.net port 587 (tcp) failed: Connection timed out
$ nc -zv smtp.example.net 465
Connection to smtp.example.net 465 port [tcp/*] succeeded!

That pairing tells you 587 is blocked somewhere on the path and 465 is open - switch your client

to port 465 with implicit TLS, or get the block on 587 lifted with your network provider.

Problem 2: the server replies, but with an error code

If you *do* see a three-digit reply (535, 550, 421, and so on), you are past the network

layer entirely. The server received your command and gave you a specific, documented answer. This

is the single most useful split in all of SMTP troubleshooting:

• `4xx` = temporary. The server is asking you to try again later. Nothing is permanently

wrong. Do not change configuration in response to a single 4xx.

• `5xx` = permanent. This exact attempt will never succeed. Something needs to change -

content, credentials, the recipient address, or your configuration - before retrying helps.

$ swaks --to test@mailpilots.in --server smtp.example.net:587 --auth LOGIN \
        --auth-user sender@yourdomain.com -tls
-> AUTH LOGIN
<- 535 5.7.8 Username and Password not accepted

A 535 is permanent and about your credential. No amount of retrying changes the outcome; the

fix is to check the credential type (see the dedicated pieces on 535 5.7.8, 535 5.7.3, and

534 for exactly which variant you have).

Problem 3: sending "succeeds" but mail never arrives

This is the hardest of the three because your own tooling reports success - the server returned

250 2.0.0 OK, the message left your queue, and nothing in your logs looks wrong. The mail is not

undelivered in the SMTP sense; it was accepted and then filtered, delayed, or placed somewhere

other than the inbox after acceptance. This is a deliverability problem, not a sending problem,

and no SMTP error code will ever describe it, because none was returned.

$ swaks --to test@mailpilots.in --server smtp.example.net:587 ...
<- 250 2.0.0 OK 1cYz9k-003x2L-1A

A clean 250 with silence afterwards means: check SPF, DKIM, and DMARC alignment; check whether

the receiving provider silently placed the message in spam; and check your own sending domain and

IP reputation. None of these show up as an SMTP error, which is exactly why they get missed.

A decision table

The ordered fix

1. Test the raw connection first with nc -zv host port before touching any client settings.
2. Capture the full SMTP transcript with swaks --server host:port ... rather than relying

on your mail client's summarised error message.

1. Read the leading digit of any reply you get. 4 means wait, 5 means something must

change.

1. Match the full code (base + enhanced) to its specific, documented meaning rather than

guessing from the base code alone - 550 alone covers dozens of unrelated conditions.

1. If the SMTP transaction completes cleanly and mail still does not arrive, stop looking at

SMTP entirely and check authentication records and placement instead.

What not to do

• Do not change SPF/DKIM records in response to a connection timeout. Those two problems are

unrelated; a timeout never reaches far enough to check authentication.

• **Do not paste a summarised client error message into a search engine without finding the raw

server reply first.** Wrapper libraries frequently flatten several distinct server replies into

one generic sentence.

• Do not assume "it worked yesterday" rules anything out. Ports get blocked, credentials

expire, and provider policies change without any action on your part.

• Do not treat a `250 OK` as proof of inbox delivery. Acceptance and placement are two

different events, often separated by seconds, sometimes by provider-side filtering you cannot

see from your own logs.

MailPilot separates exactly these three layers for every monitored mailbox: connection health,

the literal SMTP reply for every send attempt, and real inbox placement measured through a

seed-inbox network - so a problem that is actually a filtering issue never gets mistaken for a

broken SMTP connection, and vice versa.