How it works
When a mail server delivers a message to your domain, it looks up the MX records, connects to the MX host on port 25 and upgrades to TLS via STARTTLS. From then on, sender, recipients and content are encrypted on that hop. This is server-to-server encryption, not end-to-end: on the servers themselves the message sits in plain text.
How much the encryption is worth comes down to two things. The mail server's certificate should come from a public CA, be valid and include the MX host name, such as mail.example.com, not just the website's name. The negotiated TLS version should be 1.2 or higher; TLS 1.0 and 1.1 were formally deprecated by RFC 8996.
Without MTA-STS or DANE, sending servers are lenient about the certificate and will happily encrypt with an expired or self-signed one. With those policies in place, the certificate is validated strictly, and if it fails, the message is not delivered.
Why it matters
An expired or misnamed certificate on the mail server can go unnoticed for a long time, because most senders deliver anyway. As soon as the domain uses MTA-STS in enforce mode or DANE, though, messages get stuck and bounce back days later.
Many senders now reject outdated protocols like TLS 1.0 and 1.1; depending on their settings, your mail then arrives in plain text or not at all. And relying on opportunistic TLS alone leaves you exposed to attackers on the network path.
How to prevent it
- Install a certificate from a public CA on every MX host, with names that include the MX host name, and have it renew automatically.
- After every renewal, make sure the mail service actually loads the new certificate, for example by reloading Postfix or Exim.
- Allow TLS 1.2 at minimum, disable TLS 1.0 and 1.1, and turn on TLS 1.3 wherever the software supports it.
- Use MTA-STS or DANE to require encrypted delivery with a valid certificate, and TLS-RPT to receive failure reports.
- Monitor the certificate and TLS version of your mail servers continuously, not just at setup.
How DomainWarn detects it
The SMTP check connects to up to five MX hosts on port 25, negotiates TLS via STARTTLS and evaluates the certificate presented. An expired certificate, an invalid chain, a self-signed certificate or one that doesn't match the MX host name opens a “Mail server certificate invalid” incident; less than 14 days remaining is a warning. A server that only negotiates TLS 1.0, 1.1 or SSLv3 triggers “Mail server with weak TLS”. A certificate change on the mail server shows up as a change event.
DomainWarn does not enumerate the cipher suites a server offers; it rates the negotiated version and the certificate. The SMTP check only runs if port 25 is enabled for the probe servers. Separately, you can point the Certificate check at a mail server's host name, using STARTTLS on port 25, 587 or 143, or implicit TLS on 465 or 993.
DomainWarn checks this for all your domains on a schedule and alerts you when something is missing or changes.