tls.cert.hostname_mismatch

Certificate Hostname Mismatch

What we check

We connect to each MX IP address over STARTTLS and verify that the certificate's Subject Alternative Names (SANs) include the MX hostname. Wildcard matching follows RFC 6125 rules. The deprecated Common Name (CN) field is ignored — no modern validator uses it.

Each resolved IP is checked independently. Different IPs behind the same MX hostname can present different certificates, so one IP may pass while another fails.

What this finding means

The certificate presented by this IP is not valid for the MX hostname. The certificate may be perfectly valid for a different hostname — but it does not prove that this server is the one the MX record points to.

Why it matters

Identity failure. The certificate cannot authenticate the server as the expected mail destination. An attacker intercepting the connection could present an equally unrelated certificate.
Strict policy failures. Senders enforcing MTA-STS or DANE will refuse delivery when the certificate does not match the expected hostname.
Common misconfiguration. This often happens when a server hosts multiple domains but presents a default certificate that only covers some of them, or when the MX record points to a hostname not included in the certificate's SANs.

How to fix

Check which names the current certificate covers:

openssl s_client -starttls smtp -connect mail.example.com:25 \
    -servername mail.example.com 2>/dev/null | \
    openssl x509 -noout -ext subjectAltName

Add the MX hostname to the certificate. If using Let's Encrypt:

certbot certonly --standalone \
    -d mail.example.com \
    -d mx1.example.com \
    -d mx2.example.com

Alternatively, use a wildcard certificate if you have many MX hostnames under one domain:

certbot certonly --manual --preferred-challenges dns \
    -d "*.example.com" -d example.com

Reload and verify:

systemctl reload postfix
openssl s_client -starttls smtp -connect mail.example.com:25 \
    -servername mail.example.com 2>/dev/null | \
    openssl x509 -noout -ext subjectAltName

Confirm that the MX hostname appears in the SAN list.

How it's graded

A hostname mismatch carries a –20 penalty in the TLS category. When the certificate covers the IP's forward-confirmed PTR hostname instead (a shared mail front-end), the finding is softened to tls.cert.hostname_shared_frontend with a –5 penalty. See Grading Methodology for the full scoring model.

Evidence example

$ openssl s_client -starttls smtp -connect mail.example.com:25 \
    -servername mail.example.com 2>/dev/null | \
    openssl x509 -noout -subject -ext subjectAltName
subject=CN = other.example.net
X509v3 Subject Alternative Name:
    DNS:other.example.net, DNS:*.other.example.net

The MX hostname mail.example.com does not appear in the SAN list.