SMTP Test

Mail servers talk to each other over SMTP. When another server delivers mail to your domain, it connects to your MX server on port 25, waits for a greeting, introduces itself with EHLO, switches to an encrypted connection with STARTTLS and only then sends the message. This SMTP test tool repeats those steps up to the point where a message would be sent, and stops there:

1. connects to the server and measures how long the connection and the greeting take;
2. reads the greeting (the banner) and checks that it is a valid SMTP reply;
3. sends EHLO and lists the features the server announces;
4. switches to TLS with STARTTLS (on port 465: TLS from the first byte) and records the TLS version and cipher;
5. checks the certificate: a trusted issuer, the server's name, the expiry date;
6. notes whether the server offers a password login before encryption;
7. says goodbye with QUIT.

No email is sent. The only commands we send are EHLO, HELO, STARTTLS and QUIT. We never send MAIL FROM, RCPT TO or DATA, never log in, never test whether the server relays mail and never ask whether a mailbox exists. The whole conversation is shown in the result.

The port changes how strict the verdict is. On port 25 senders accept any certificate unless your domain asks for more (MTA-STS or DANE), so certificate problems there are warnings. On 587 and 465 mail apps must check the certificate and servers must offer TLS 1.2 or later (RFC 8314), so the same problems are failures.

The verdict is Pass, Warning, Fail or Could not check. Anything that may be about our network rather than your server, such as a connection that times out, is “could not check”, never a failure.

Pass: the server answers and encrypts

The server greeted us, accepted EHLO, switched to TLS 1.2 or 1.3 and presented a trusted certificate for its name. Under the verdict you see the greeting, the features it announced, the certificate and the whole conversation.

Which server we tested

• A domain (example.com): we look up its MX records and test the most preferred MX server on port 25, the one a sending server tries first. The result lists all MX servers with a link to test each one.
• A name without MX records (mail.example.com): we test that name itself on port 25. This is also what sending servers do when a domain has no MX record.
• A name with a port (smtp.example.com:587): that server on that port, no MX lookup.
• An IP address: that address on port 25. We only test public internet addresses.

If the MX lookup fails, the result is “could not check”: we do not know which server to test, so we test none.

Fail: an MX record holds an IP address instead of a host name

An MX record must name a mail server by its host name, such as mail.example.com, and that name needs an A or AAAA record (RFC 5321 §5.1). A value like 10 203.0.113.25 looks right but is not a host name: sending servers look it up as a name, find nothing, and cannot use it. We do not test such a record. If another MX record names a real host, we test that one instead and say so; if none does, there is no server to test.

To fix it, give the server a name: add an A record, for example mail.example.com pointing to 203.0.113.25, then change the MX record to 10 mail.example.com. The same applies to a value that is not a valid name at all, such as one with an empty part between two dots.

Nothing to check: the domain accepts no mail (null MX)

The domain publishes a null MX: a single MX record with the host ., which says that it accepts no email (RFC 7505). There is no mail server to test, so the result shows a notice instead of a verdict. That is correct for a domain that never receives mail. If yours should, replace the null MX with the MX records your email provider gives you.

Connecting to the server

• Connected (Pass): the TCP connection opened; the time it took is shown.
• No address, or only private addresses (Fail): the name has no A or AAAA record, or points only to addresses that cannot be reached from the internet, such as 10.0.0.5.
• Connection refused (Could not check): either nothing listens on the port, or a firewall on the way refused the connection. We report it as a failure only on ports where we have confirmed that our own outgoing connections work; otherwise it could be our side.
• Timed out or unreachable (Could not check): no answer within our time limit (10 seconds to connect, 15 seconds for the greeting). This is also what a firewall that silently drops packets looks like.
• Closed early (Warning): the server hung up before the conversation finished. Some servers do that to addresses they do not trust, so it may be aimed at our test.
• Not an SMTP server (Fail): something answers on the port, but not with SMTP, for example a web server.
• Our limits (Could not check): the probe is switched off, or a reply was larger than our safety limit. The result lists the limit that stopped it.

The greeting (banner)

A server starts with a line that begins with 220 and usually names itself, for example 220 mx.example.com ESMTP. A reply starting with 4 is temporary (Could not check: try again later). A reply starting with 5 is a refusal (Warning): it may be meant for our address only, not for everyone.

EHLO and the features the server announces

After EHLO, the server lists what it supports: STARTTLS, SIZE (the largest message it accepts), PIPELINING, AUTH and others. After TLS the list is read again, because only the list sent over the encrypted connection counts. If the server refuses EHLO and only accepts the old HELO (Warning), it cannot announce any feature, including STARTTLS.

STARTTLS

• Works (Pass): the server offered STARTTLS and the switch to encryption succeeded.
• Not offered: a warning on port 25, where mail still arrives unencrypted, except from senders that enforce your MTA-STS or DANE policy: they will not deliver at all. A failure on port 587.
• Offered but failed (Warning on 25, Fail on 587): the server refused the command or the TLS handshake broke, for example because the server cannot load its certificate or key.
• Not announced, but works (Warning): TLS started although the feature list did not contain STARTTLS. Clients that go by the list will not use encryption.
• Data sent before encryption (Warning): the server sent more text right after agreeing to start TLS. Clients must ignore it; it is a sign of a broken setup or of interference on the way.

Port 465: TLS from the first byte

On port 465 the connection is encrypted before any SMTP is spoken (RFC 8314). If the server answers in plain text there or the handshake fails, mail apps cannot connect (Fail).

TLS version

TLS 1.2 and 1.3 are fine. TLS 1.0 and 1.1 must no longer be used (RFC 8996): a warning on port 25, a failure on 587 and 465. We offer the old versions ourselves only to be able to report them; the connection carries no password and no mail.

The certificate

We check three things, separately:

• Trusted issuer: the chain leads to a root certificate authority in Mozilla's root store, the list of trusted authorities our test uses. A self-signed certificate, an unknown issuer or missing intermediate certificates fail this check.
• The name: the certificate lists the server's host name in its subject alternative names. A certificate for another name, or with the name only in the old Common Name field, does not match.
• Dates: the certificate and its intermediates have not expired. We warn 14 days before expiry (our own threshold).

On port 25 these are warnings: most senders encrypt with any certificate. They become failures for senders that enforce your MTA-STS policy (and DANE senders check the certificate against your TLSA records instead). On 587 and 465 they are failures, because mail apps refuse such certificates. When you test an IP address, we cannot check the name the clients use; that part is “could not check”.

Password login offered before encryption

The server announced AUTH PLAIN or AUTH LOGIN before TLS (Warning). A mail app that logs in at that point sends the password readable to anyone on the path, even if the server later refuses the login. Offer password logins only after STARTTLS.

Response times

How long the connection, the greeting and the whole test took, from our server. A slow greeting is not an error: some servers delay it on purpose to catch spam software that talks before its turn (Postfix's postscreen, for example, waits up to 6 seconds by default). We wait up to 15 seconds.

Could not check

The connection timed out, was refused on a port we cannot confirm from our side, a DNS lookup failed, or our safety limits stopped the test. This is not a failure of your server, and not a pass. Try again in a few minutes. If it stays like this, test from another network with the commands below.

Could not check: a fault on our side

Rarely, the result says the check could not be completed because of an internal error. That is a fault in our software, not a finding about your domain and not a network problem, so trying again will most likely give the same result. Please write to [email protected] with the address of the result page, and we will fix it.

Google Workspace, Microsoft 365, Zoho and other hosted mail

You do not run these servers, so you cannot change their TLS settings. What you control is where your MX records point. Google Workspace's MX is smtp.google.com (older setups use names starting with aspmx); for Microsoft 365, copy the MX value from the admin center. If the test of your domain shows a server you do not recognize, your MX records may still point to an earlier provider.

SendGrid, Mailgun, Amazon SES

These services send mail for you; your mail apps or applications log in to their SMTP servers on port 587 or 465. To check that such a server answers and encrypts, enter the SMTP host name from the provider's dashboard with the port, for example smtp.example-provider.com:587. We do not log in, so we cannot test your credentials.

Your own server: Postfix

Settings in main.cf for a server that receives mail on port 25:

# offer STARTTLS, never require it on a public MX
smtpd_tls_security_level = may
# private key first, then the certificate and its intermediates (Postfix 3.4+)
smtpd_tls_chain_files = /etc/postfix/mail-key.pem, /etc/postfix/mail-fullchain.pem
# no TLS 1.0 or 1.1 (this syntax needs Postfix 3.6+)
smtpd_tls_protocols = >=TLSv1.2
# password logins only after STARTTLS
smtpd_tls_auth_only = yes

In master.cf, require TLS on the submission port 587 with -o smtpd_tls_security_level=encrypt, and run port 465 with -o smtpd_tls_wrappermode=yes. Do not use encrypt on port 25: Postfix warns it must not be used on a publicly referenced server, because senders without TLS could no longer deliver. Reload Postfix and test again.

For Exim, Microsoft Exchange Server and others, the ideas are the same (a certificate with the full chain, TLS 1.2 or later, login only after STARTTLS), but we have not verified their exact settings here; follow their documentation.

DNS: MX records at Cloudflare, GoDaddy, Namecheap

• An MX record must name a host name that has an A or AAAA record: not an IP address (RFC 1035 §3.3.9) and not a CNAME (RFC 2181 §10.3).
• At Cloudflare, the A and AAAA records of your mail server must be DNS only (gray cloud). Cloudflare's proxy is for web traffic, and Cloudflare lists email records among the records that should stay DNS only.
• At GoDaddy, Namecheap and other panels, check that there are no leftover MX records from an earlier provider: senders try them too.

The classic SMTP tester on the command line is openssl: it can do the same STARTTLS handshake and print the certificate. Type QUIT to end the session:

# port 25 or 587, with STARTTLS
openssl s_client -starttls smtp -connect mail.example.com:25 -crlf -brief
# port 465, TLS from the first byte
openssl s_client -connect mail.example.com:465 -crlf -brief

-crlf makes the commands you type end the way SMTP expects, and -brief prints a short summary of the TLS connection. To see only the greeting, nc mail.example.com 25 is enough; type QUIT to leave.

If these commands hang on port 25, your own network may block outgoing connections to port 25. Google Cloud, for example, blocks them for its virtual machines. That is why a test from a web service like this one can reach servers that your computer cannot.