tls.cert.hostname_shared_frontend

Certificate for Shared Mail Front-End

What we check

When the certificate does not match the MX hostname, we perform a secondary check: does it match this IP's forward-confirmed PTR hostname? If the PTR hostname verifies against the certificate (full x509 SAN matching, not just domain relatedness) and no strict validation policy is published (MTA-STS enforce or checkable DANE TLSA records), the finding is softened from a hard hostname mismatch to this warning.

What this finding means

The certificate is not valid for your MX hostname, but it does cover the machine's own PTR-confirmed hostname. This is consistent with a shared mail front-end — a spam filter, relay cluster, or hosting provider's mail gateway where your MX name is an alias for their infrastructure.

Senders using opportunistic TLS will accept this certificate because the encryption channel is established, even though the name does not match the MX. But senders enforcing strict policies (MTA-STS, DANE) would reject it.

Why it matters

Reduced assurance. The certificate proves the machine's identity under its own name, but not under yours. This is weaker than a certificate that covers the MX hostname directly.
Strict-policy incompatible. If you later publish an MTA-STS policy in enforce mode or add DANE TLSA records, this configuration will cause delivery failures from senders that enforce those policies.
Accepted trade-off. Many hosted mail setups work this way by design — the provider manages certificates for their infrastructure hostnames, not every customer's MX alias.

How to fix

Ask your mail hosting provider to add your MX hostname to the certificate's Subject Alternative Names. Some providers support this via their admin panel.

Or use your own certificate. If you control the server, add the MX hostname to the certificate:

certbot certonly --standalone \
    -d mail.example.com \
    -d mx-gateway.provider.example.net

Consider the trade-off. If you are not planning to publish MTA-STS or DANE, this finding is informational — the shared front-end setup works for opportunistic TLS.

How it's graded

A shared front-end certificate carries a –5 penalty (warning), compared to –20 for a full hostname mismatch. This softening is revoked if a strict policy is published — MTA-STS enforce or checkable DANE TLSA records cause the full tls.cert.hostname_mismatch penalty instead. See Grading Methodology for the full scoring model.

Evidence example

MX hostname: mail.example.com
IP: 203.0.113.42
PTR: gateway7.provider.example.net (forward-confirmed)

Certificate SANs: *.provider.example.net, provider.example.net
  → does not cover mail.example.com (MX hostname)
  → covers gateway7.provider.example.net (PTR hostname) ✓
  → no MTA-STS enforce / no DANE TLSA → softened to shared front-end warning