SMTP Send Tests: Ports, TLS Modes and Reading Server Reply Codes

“Mail is not going out” is one of the vaguest trouble tickets in existence. Nine times out of ten the answer is visible in the raw SMTP conversation — the client connects, the server says something specific, and the session either proceeds or stops. A controlled send test reproduces that conversation deliberately, with your chosen port, encryption mode and credentials, and shows you every reply the server gave.

Ports and encryption modes

The three mail submission ports are not interchangeable:

• Port 25: server-to-server relay. Many residential and cloud providers block it outright to fight spam. Never use it for application mail.
• Port 587: submission with STARTTLS — the connection starts in plain text and upgrades to TLS after the client issues STARTTLS. The standard choice for application mail.
• Port 465: implicit TLS — encryption starts before any SMTP traffic. Some servers support only this; some clients mislabel it “SMTPS”.

If port 587 times out but 465 works (or vice versa), the problem is a firewall or a provider that runs only one mode, not your credentials. A send test lets you try both against the same host in seconds.

Reading the replies

SMTP replies are three-digit codes with the first digit carrying the meaning. The ones worth memorising:

• 220 — greeting, service ready. If you never see it, TCP failed: wrong port, blocked, or the server is down.
• 250 — success for the command that preceded it. 250 2.0.0 Ok: queued as ABC123 is your proof of acceptance; the queue ID is what you quote to the remote postmaster.
• 235 — authentication succeeded; 535 — authentication failed (bad password, or the server requires an app password because basic auth is disabled).
• 530 — usually “must issue a STARTTLS command first”: you picked plain text where TLS is mandatory.
• 550 — permanent rejection. Relay access denied means you did not authenticate before sending; sender rejected points at SPF or a blocklist.
• 4xx codes such as 450 greylisting are temporary — the mail is not lost, the server wants a retry later.

Common AUTH LOGIN failures

1. Correct password, wrong mechanism — some servers dropped AUTH LOGIN in favour of PLAIN, or require CRAM-MD5.
2. “Username” is the full address on most providers, not the local part.
3. Google and Microsoft accounts now refuse basic password auth entirely; you must generate an app-specific password or use OAuth.
4. TLS not negotiated before AUTH — several servers return 538 or a policy error if you try to authenticate in the clear.

When you can see the actual transcript instead of a client library’s “SMTP Error”, the failing command is obvious, and you stop guessing between DNS, firewall and credential causes. The mail send test on WhoDNS performs a full submission — host, port, TLS mode, authentication, from, to, subject, body — and shows each reply line it receives, so a 535 from the server is printed as a 535 rather than swallowed into a generic failure message.