exim.ro

Testing an SMTP server: banner, STARTTLS, certificate

What an SMTP server check looks at: the greeting, EHLO capabilities, STARTTLS, TLS version, the certificate and reverse DNS, and why each one matters.

Updated 3 min read5 sections

Run the SMTP server check

When another server delivers mail to your domain, it looks up your MX records, connects to port 25 and holds a short conversation before sending anything. The SMTP server check replays the first part of that conversation, stops before any message is sent, and reports what it saw.

The conversation

S: 220 mx.example.com ESMTP ready
C: EHLO probe.exim.ro
S: 250-mx.example.com Hello probe.exim.ro [91.239.230.137]
S: 250-SIZE 52428800
S: 250-STARTTLS
S: 250 8BITMIME
C: STARTTLS
S: 220 Ready to start TLS
   (TLS handshake)
C: EHLO probe.exim.ro
S: 250-mx.example.com ...
C: QUIT
  • Banner (220). The server's greeting. A 554 here means it refuses the connection outright. Some servers wait several seconds before greeting, on purpose, because badly written spam software gives up or talks too early; the checker allows 5 seconds per step and reports a slow greeting as unavailable, not as a fault.
  • EHLO. The client names itself; the server answers with its capabilities, one per line: the maximum message size, STARTTLS, 8BITMIME, SMTPUTF8 and so on.
  • STARTTLS. Upgrades the same connection to TLS (RFC 3207). After the handshake the client must forget what it learned before and send EHLO again (RFC 3207, section 4.2), because anything said in clear text could have been altered.
  • QUIT. The checker never sends MAIL FROM, RCPT TO or DATA: it does not deliver anything and does not test whether the server relays mail for others.

TLS and the certificate

Between mail servers, TLS is usually opportunistic: a sender uses it when offered and does not insist on a valid certificate. So an expired or wrongly named certificate often goes unnoticed, until the recipient domain publishes an MTA-STS policy (RFC 8461) or DANE records (RFC 7672). Senders that honour those then check the certificate properly and refuse to deliver when it is wrong.

That is why the checker completes the handshake even when the certificate is bad, and verifies it separately:

  • Trusted chain. Does the certificate lead to a public root authority?
  • Name matches. Is it valid for the name in the MX record? A certificate issued for the hosting company's server name, but reached through mail.yourdomain, fails here.
  • Validity. The dates, and a warning two weeks before expiry.
  • TLS version. TLS 1.2 and 1.3 are current; 1.0 and 1.1 are obsolete.

Reverse DNS and FCrDNS

The checker looks up the PTR record of the server's IP address and resolves the name found back to an address. When that gives the same address, the reverse DNS is forward-confirmed (FCrDNS). For receiving alone this matters little, but most mail servers also send, and many receivers penalise or reject mail from addresses without a PTR record or whose PTR does not resolve back. A PTR name that differs from the name in the banner is common (large providers use generic names) and is only noted.

Where the test comes from

The checker connects from a dedicated address, 91.239.230.137, whose reverse DNS is probe.exim.ro, and introduces itself with that name. You can see both in the server's EHLO answer. Each network may run 6 checks a minute, at most 5 mail servers are contacted per check, and private, loopback and reserved addresses are never contacted.

Sources