dotvitals

Mail server's certificate does not cover its own hostname

MediumConfirmedemail.smtp-tls.certificate-name-mismatch

What this check looks for

The certificate your mail server presents is for a different name than the one your MX record points at. Senders that check the name — which is every sender following an MTA-STS policy — will refuse to deliver.

Why it matters

This is the single most common way a correct-looking MTA-STS setup silently loses mail: the policy tells senders to require a certificate for the MX name, and the server presents one for the web host or for the provider's shared name instead.

When the check passes, your report says: “The certificate covers the hostname the MX record points at”.

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

Issue a certificate that includes ‹mx host› as a subject alternative name, or point the MX at a name the certificate already covers.

An MTA-STS policy makes a name mismatch a delivery failure rather than a cosmetic one.

  1. Add ‹mx host› to the certificate's SAN list and reissue — with ACME, add it to the -d list and renew.

  2. Alternatively, change the MX record to point at a hostname the existing certificate already covers, then re-test.

  3. If your mail is hosted, this certificate belongs to the provider: check their documented MX hostnames and use those exactly, rather than a CNAME or a vanity name of your own.

How to confirm it worked

  • openssl s_client -starttls smtp -connect ‹mx host›:25 -servername ‹mx host› 2>/dev/null | openssl x509 -noout -text | grep -A1 'Subject Alternative Name' — expect ‹mx host› to appear.

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 certificate presented by ‹mx host› covers ‹certificate names›, which does not include ‹mx host› (‹verification error›). RFC 8461 §4.1 requires the certificate to be valid for the MX hostname as published in DNS — not for the domain, and not for the name the server announces in its SMTP greeting.

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