Set Up the MX Certificate — Issued for the Right Name

Which name the certificate has to carry

Not the domain but the MX hostname — that is, whatever the MX record names:

The website's certificate is the most common wrong turn: it carries yourdomain.com and www.yourdomain.com, but a validating sender connects to mail.yourdomain.com and does not find that name. Either the certificate gains the MX name as an additional SAN entry, or the mail server gets its own.

With several MX hosts each needs its name in a certificate — one certificate per host, or a single certificate carrying all names in the SAN.

Four names that should agree

In a clean setup they all point at the same thing:

• The MX record names mail.yourdomain.com.
• The IP's PTR record resolves to mail.yourdomain.com, and that name resolves back to the same IP.
• The HELO name the server announces itself with is the same.
• The certificate carries that name.

These four agreements are the single strongest factor in a self-hosted mail server's reputation — more so than any filter tuning. How the PTR part is set up is covered in Set up reverse DNS.

The chain has to be complete

A frequent case: the certificate looks fine in a browser and verification fails over SMTP. The cause is a missing intermediate. Browsers often fetch missing links themselves; SMTP clients do not. So the full chain has to be served:

The output must list more than one certificate under Certificate chain, and end in Verify return code: 0 (ok).

The hook almost everyone forgets

Automatic renewal writes new files — but the running mail server works with what it read at start-up. Without a reload after renewal it keeps serving the old certificate until it expires. The result is 454 4.7.0 TLS not available, or a failed verification at the far end.

The reload therefore belongs inside the renewal process itself, not in a separate schedule. Worth checking too: whether the unprivileged process may even read the new files — after a renewal they often belong to root alone again.

Self-issued or from a CA?

• Opportunistic encryption: equivalent either way. The sender does not verify, it only encrypts.
• MTA-STS: it must be a public CA certificate carrying the MX name. A self-issued one causes delivery refusal in enforce mode.
• DANE: with usage 3 a self-issued certificate works, because the TLSA record is itself the trust anchor.

If you run both, take a CA certificate on the MX name — that covers each mechanism.

Checking

The MX check opens a real STARTTLS connection to every MX host and shows issuer, SAN names, remaining validity, key strength and whether the chain could be verified.