A certificate expires on a mail server nobody watches
The certificate on your website has a calendar entry. The one on your MX usually does not, and when it lapses mail stops being encrypted or stops arriving. Every host in your MX is connected to and its certificate read, so the number of days left is a figure you can see rather than one you have to remember
The certificate itself
Read from a real connection to each mail host, not from a database of what was true last month
- Expiry date and days remaining
- Chain validated to a trusted root
- Names on the certificate checked
- Reminders for the web certificate at 7, 3 and 1 days
What the server negotiates
STARTTLS is attempted on each host and the protocol versions and cipher suites it accepts are recorded
- STARTTLS on ports 25 and 587
- Protocol versions offered
- Cipher suites listed
- A deeper scan on request
DANE, where DNS and TLS meet
A TLSA record pins your certificate in DNS, and it is only useful while it matches what the server actually presents
- TLSA records read and matched
- Checked against the live certificate
- Both the domain and each MX host
- Failure named, not just flagged
What the TLS checks do
Everything here comes from an actual connection to your mail hosts, repeated on the same schedule as the rest
Days remaining, on every host
Read from the connection, not a note
The certificate on each mail host is read on every run and its remaining days shown. Email reminders at seven, three and one days are sent for the HTTPS certificate on the domain and for the domain registration itself; a reminder for MX certificates is not sent yet, so watch that number on the page
Every host, not just the first
The whole MX, one at a time
Mail is delivered to whichever host answers, so a certificate problem on the third of four is a problem for a quarter of your mail. Each host in the MX is connected to separately and reported separately
STARTTLS that is actually offered
Negotiated, not assumed
A connection is opened and STARTTLS attempted on ports 25 and 587. A host that advertises it and then fails the handshake is a different problem from one that never offers it, and the two are reported differently
The cipher suites on offer
What you would actually negotiate
Protocol versions and cipher suites accepted by each host are recorded, so you can see an old TLS version still enabled on a server everyone forgot about. A deeper scan is available on request when you want the full matrix
DANE that still matches
A TLSA record ages badly
A TLSA record pins a certificate in DNS. Renew the certificate without updating the record and every DANE-validating receiver refuses your mail, which is a self-inflicted outage that looks like somebody else fault. The record is matched against the live certificate on every run
The web certificate too
Same domain, same check
The HTTPS certificate on the same domain is read on the same schedule, along with whether plain HTTP reaches the encrypted site. A domain is judged as one thing by the people using it, so it is checked as one thing
Which ports are tried, and which decide the verdict
Two of them carry mail that has to arrive, and two are conveniences. A failure on the second pair is worth knowing about and is not worth an alarm
| Port | What it carries | Effect on the verdict |
|---|---|---|
| 25 | Delivery between servers, RFC 5321 | Required. A host that cannot start TLS here fails the check |
| 587 | Submission from clients, RFC 6409 | Required. Mail your own users send leaves through this one |
| 465 | Implicit TLS, RFC 8314 | Reported only. Its absence is normal on plenty of working servers |
| 2525 | Alternative submission where port 25 is blocked | Reported only. Common on cloud hosts, absent almost everywhere else |
| 443 | The web certificate on the same domain | Checked alongside, because a certificate that expires there usually expires on the mail hosts too |
Every MX host is tried on every port, so a certificate that expired on the third host is not hidden by the first two
Three steps, about ten minutes
No agent and no access to your servers. Everything is read from an ordinary connection
Enter the domain
Each host in the MX is connected to, STARTTLS attempted, and the certificate read with its expiry, chain and names
Look at the host you forgot about
Problems here are rarely on the primary. They are on the backup MX that was set up once and has not been touched since
Leave the reminders on
On an account the check repeats every ten minutes, and the web certificate and the domain registration send reminders at seven, three and one days
Questions about certificates and TLS
What is checked on which port, why a DANE record breaks on renewal, and what happens when STARTTLS fails
STARTTLS on ports 25 and 587 upgrades an unencrypted connection to a secure one, while Implicit TLS on port 465 is encrypted from the start. We monitor both to ensure your servers follow modern encryption standards.
Not on that host. The MTA-STS check fetches the policy file over HTTPS and validates its contents, the version, the mode, the max age and the MX names it lists. HSTS is checked separately, on your website, as part of the security headers check.
SSL/TLS encrypts the connection between mail servers, ensuring that your emails cannot be intercepted or read by unauthorized parties during transit.
If a certificate expires, other mail servers may refuse to send you email or mark it as insecure. This can lead to delivery failures and broken MTA-STS policies.
Every ten minutes, on every plan. Ports 25 and 587 are always tried, with 465 and 2525 where they answer, and the HTTPS certificate on the same domain is read on the same cycle. There is no per-plan frequency setting, because there is no plan that gets a slower one.
Check the certificate on your backup MX
Every host in your MX is connected to, not just the one with the lowest priority number. One domain is free, and no card is needed