SMTP test online

When an SMTP server stops answering, the shop no longer sends its order confirmations. The copier down the corridor refuses to send scans. And the billing software quietly sits on its invoices without telling anyone. Before you take your configuration apart, run an SMTP test on the server itself and find out which side the fault is on.

The tool below runs that test for real. It dials the server you name, walks through the same conversation your mail client would, and hands back the whole transcript. Ten seconds or so, usually.

What we store: nothing. No tested server, no username, no password, no result is kept. No database, no log file, no email. Anonymous counters limit how many tests can be run, per visitor and above all per tested server, so the tool cannot be turned against someone else's machine. Private addresses and non-SMTP ports are refused, for the same reason.

What the SMTP test checks, step by step

Email delivery rarely breaks for a single reason. The test therefore walks the sequence and stops at the first step that fails.

The TCP connection opens the door. Fail here and your credentials are irrelevant, because nobody has picked up yet. Either nothing listens on that port, or a firewall sits in between. Providers that close outbound port 25 produce this result all day long.

The banner is the server’s opening line. It starts with 220 and gives its real name. Compare it with the name you typed. A mismatch often means a DNS record pointing somewhere other than where you assumed.

The EHLO handshake asks the server what it can do. Its answer lists the available extensions, STARTTLS and the authentication methods among them. A server refusing EHLO at this stage is most likely filtering your IP address.

Encryption comes next. STARTTLS begins in clear text and switches over mid-conversation, while direct SSL is encrypted from the very first byte. Either way we check the certificate. Expired, self-signed, issued for some other name, and the handshake collapses. Your own software won’t be any more forgiving.

Authentication only runs if you fill in the credentials, and only after the channel is encrypted. Pushing a password across an unencrypted port proves nothing, so we don’t do it, test or no test.

Reading the result

Each step comes back with a status, and the difference between the three matters.

Status	What it means	What to do
Passed	The step went through normally	Nothing, move to the next one
Warning	It works, but under questionable conditions	Fix it when you can, it is not blocking
Failed	The sequence stops here	Deal with this step before looking at the others

Underneath sits the full transcript. Lines beginning with > are ours, everything else comes back from the server. Same content telnet would give you, minus the squinting. Paste it straight into a support ticket and you’ll skip two rounds of questions.

Which SMTP port to try, and in what order

Start with port 587 over STARTTLS. It is the submission port for authenticated mail, and it works in the large majority of cases. A great deal of folklore surrounds SMTP ports, but four cases cover almost everything.

Port	Mode	When to use it
587	STARTTLS	The default choice, the one to try first. Dedicated to authenticated message submission
465	Direct SSL	When the software or the device cannot do STARTTLS. Plenty of copiers fall into this category
25	STARTTLS or clear	The historic server-to-server port. Blocked outbound by most access providers and hosts
2525 and above	STARTTLS	Fallback ports, for when a corporate firewall closes the others

If 587 fails and 465 goes through, look no further: that is network filtering, not a broken server. The alternatives we offer are listed on the flexibility page.

The SMTP errors you will meet, and what they tell you

SMTP error codes are standardised, and the first digit is enough to decide. A 4xx code is temporary, the server is asking you to come back later. A 5xx code is final, and insisting will get you nowhere.

What you see	Real cause	Where to look
Connection refused	Nothing is listening on this port	Check the port, then the server name
Timed out	A firewall swallows the packets without answering	Try another port, test from another network
421	Server saturated, or sending deliberately throttled	Slow your sending rate down
535	Username or password rejected	Check that the username is the full address
550	The recipient refuses the message	Address does not exist, or poor sending IP reputation
554 5.7.1	Relay denied, or message treated as spam	Missing authentication, missing SPF or DKIM
Certificate rejected	Certificate expired, self-signed, or wrong name	Fix the certificate, never disable verification

Rejection codes and delivery reports are covered in detail in our guide on error codes for undelivered messages.

A green test does not mean your email arrives

This one costs people days, and it comes up constantly.

All a successful SMTP test proves is that the server took your connection. What happens afterwards, once the message leaves and shows up at Gmail, Outlook or some corporate filter, is a separate story. Different criteria, none of them related to the handshake you just watched.

Domain authentication is one of them. Without a published SPF record and a DKIM signature, a perfectly transmitted message still lands in the junk folder for a fair share of recipients. The reputation of the IP address carrying your mail counts just as much, and that is long-term work rather than a setting. Both sides are covered on our safety page.

Put differently: a successful test rules out half the possible causes. That is a lot when you are hunting a fault, but it is not a certificate of good deliverability.

Why your host’s SMTP eventually gives up

There is one family of results that comes back regularly, and it is not really a fault.

The server answers, the connection is fine, authentication passes, and the mail still goes badly. Those are quotas. Shared hosting imposes a sending limit per hour and per day, shared between every account on the server. As long as your site sends three emails a week, nobody notices. The day the shop takes twenty orders, or the day the property management software fires off its rent notices all at once, the ceiling arrives and messages are queued, or lost.

The same mechanism hit multifunction copiers when Microsoft turned off basic SMTP authentication on Microsoft 365. Those devices cannot handle modern authentication protocols. They need a relay that accepts a username and a password, plainly.

In both cases the tester shows green and the problem stays, because the problem is not technical. It is contractual. An independent SMTP relay exists for exactly that situation. Your own account, a quota you choose, French IP addresses whose reputation somebody actually watches, and no dependency on your host. Pricing starts at 29 euros a year.

Frequently asked questions

Do you store the server or the password I type? No, none of it. The password lives in memory for as long as the connection lasts, then it’s gone. The transcript shows asterisks in its place. Nothing you type reaches a database or a log file.

Is this the same thing as an SMTP checker? Yes, that is the other common name for this kind of tool. Most SMTP checkers stop at telling you a port is open. This one runs the conversation to the end, validates the certificate and tests authentication if you ask it to.

The test fails but my software sends fine. How? It happens, and it tells you something. Our tester calls from our servers, not from your desk. So if your software sends happily and we get refused, the far end is probably filtering by IP address, or it simply isn’t reachable from outside your network.

Can I test a server on my local network? No. The tool deliberately refuses private addresses, the 192.168 and 10.x ranges and their equivalents, along with every port that is not an SMTP port. A public tester without that restriction becomes a reconnaissance tool for anyone who wants one.

The authentication test says it is unavailable for this server. Why? Any given server can only receive a small number of credential attempts per hour, counted across all visitors. Without that limit, our tool would turn into a machine for trying stolen passwords against somebody else’s server. Wait a while, or test the connection on its own first.

Why is the authentication test skipped on an unencrypted port? Because your password would travel the wire in the clear. We won’t do that, not even to satisfy a test. Switch to STARTTLS or direct SSL and try again.

What should I do with the transcript? Paste it as it stands into your support request, ours or somebody else’s. It carries the exact sequence of answers, which usually saves a couple of rounds of back and forth.