SMTP Test

What this actually does

It opens the same conversation any other mail server would open. Connect, read the greeting, say hello, look at what the server advertises, and — if it offers encryption — negotiate it and inspect the certificate.

No message is ever sent. The exchange stops before the command that would carry one, and when a relay probe is run it is followed by a reset rather than any content. What you see is what a receiving server sees in the first second of a delivery attempt.

The three names that have to agree

This is the finding that surprises people most, because it has nothing to do with the records they spent the afternoon configuring.

When a server connects, the receiver knows one thing for certain: the address it came from. It looks that address up in reverse DNS to get a name, then resolves that name forward to see whether it points back. It also compares both against the name the sender announced in HELO. Three values, and they are expected to describe one machine.

• No PTR at all — a large share of receivers reject the connection immediately, before any authentication is considered.
• A PTR that does not resolve back — anyone can point a name at an address; only the address owner can make the reverse record. When the forward lookup does not return the same address, the name proves nothing.
• HELO disagreeing with the PTR — the usual result of a default configuration announcing an internal hostname such as localhost.localdomain or a container ID.

Getting this right is not subtle work: one PTR record from whoever owns the address, one hostname in the mail server's configuration, and an A record that ties them together. It is simply invisible from the DNS side, which is why it survives so many otherwise careful setups.

Encryption, and what the certificate has to do

Mail between servers uses opportunistic TLS: the sender asks whether encryption is available and uses it if so. The certificate is usually not validated, which is why self-signed certificates carry mail every day without complaint.

Two things change that. Publishing an MTA-STS policy tells senders to require TLS with a valid, matching certificate and to refuse delivery rather than fall back to plaintext — so a certificate that was fine yesterday starts bouncing mail. And since 2024 Gmail and Yahoo require bulk senders to transmit over TLS at all.

The expiry date is worth a note in the calendar for the same reason. A certificate that lapses on an ordinary web server produces a warning someone can click through. On a mail server under MTA-STS it produces silence, and mail that stops arriving.

Open relay: rare, and catastrophic

A relay that carries mail for anyone will be found within days of appearing, and the address will be on every blocklist shortly after. It is rare in modern software because no current mail server ships that way — it turns up after a hand-edited configuration, or a permissive rule added to solve a delivery problem and never removed.

When you test a domain, we ask its mail server to accept a message from an address it has no relationship with, addressed to a domain it does not host, and stop before sending anything. A correct server refuses. A server that agrees is being abused already, whether or not anyone has noticed.

We do not run this probe against a specific host you type in. Asking an arbitrary machine whether it will carry someone else's mail is indistinguishable from scanning, and our own address would be the one paying for it.

Reading the capability list

The server lists what it supports in response to the greeting. A few of those lines are worth knowing.

• STARTTLS — encryption is available. Its absence on a public mail server is a real gap in 2026.
• SIZE — the largest message the server will accept. Worth checking before blaming a bounce on filtering.
• AUTH — authenticated submission is offered. Expected on port 587, and a little unusual on port 25.
• 8BITMIME and SMTPUTF8 — the server handles non-ASCII content and international addresses without re-encoding.

The list often changes after encryption is negotiated: many servers advertise authentication only once the channel is secure. We re-issue the greeting after the upgrade and show what the server says then, since that is what a real sender would act on.