dotvitals

Mail server's TLS certificate does not verify

MediumConfirmedemail.smtp-tls.certificate-untrusted

What this check looks for

Your mail server encrypts, but its certificate is self-signed or issued by an authority senders do not trust, so senders cannot tell they are talking to you rather than to someone intercepting the connection.

Why it matters

Most senders still deliver — opportunistic TLS accepts any certificate — so this is not immediately breaking your mail. It stops mattering only until you publish MTA-STS or DANE, at which point the same certificate causes every enforcing sender to refuse delivery.

When the check passes, your report says: “The mail server's certificate verifies against a trusted root”.

What it costs your score

When this check fails it removes 15 points from your Email transport score, before the status, confidence and repeat multipliers are applied. Email transport carries a weight of 8 in the overall score.

It shares the email-transport.smtp-tls family ceiling of 40 points: however many findings that family produces, together they cannot remove more than that from Email transport. One underlying problem showing up in several places is still one problem.

Severity
medium
Default confidence
confirmed
Status when triggered
fail
Deduction
15 points
Family cap
email-transport.smtp-tls · 40
Category
Email transport
Module
Email smtp tls
Fix owned by
mail provider
In the ruleset since
2026.09

How the whole score is calculated

How to fix it

Install a publicly trusted certificate for ‹mx host› and serve the full chain.

A certificate that does not verify gives senders no protection against interception, and blocks MTA-STS and DANE.

  1. Issue a certificate for ‹mx host› from a public CA — an ACME client such as certbot does this free and renews automatically.

  2. Configure the mail server to present the full chain file, not the leaf certificate alone; a missing intermediate is the commonest cause of this failure.

  3. Reload the mail server and re-test.

How to confirm it worked

  • openssl s_client -starttls smtp -connect ‹mx host›:25 -servername ‹mx host› -verify_return_error — expect 'Verify return code: 0 (ok)'.

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Technical detail

The chain presented by ‹mx host› did not verify against a public root store: ‹verification error›. Opportunistic TLS under RFC 3207 does not require a verifiable certificate, which is why this is a failure of assurance rather than of delivery today. RFC 8461 §4.1 requires a valid, publicly trusted certificate for the MX hostname whenever an MTA-STS policy is in effect.

Standards and references

Test this on your domain

Run the check that produces this finding, on its own, against any domain.

Open the email smtp tls checker

Other email smtp tls checks