The short answer
A mail server takes an ordinary publicly trusted TLS certificate, the same product that secures a website. What changes is the name inside it: the certificate has to match the hostname mail clients connect to and the hostname your MX record points at, not the domain after the @ in your address. An S/MIME certificate is a different product and cannot be installed on a server. As of March 15, 2026 these certificates expire after at most 200 days, so a mail host needs the same renewal automation a web server does.
If you already know which hostname you need to cover, the order itself is routine. DV and OV SSL certificates from My-SSL accept any fully qualified hostname you can validate, including mail hosts, and let you add the MX target as a second name on the same certificate.
Do mail servers need a special certificate?
No. A mail server uses a standard TLS server certificate, issued by a publicly trusted certificate authority, with the server authentication extended key usage that every website certificate already carries. There is no separate "mail server" product line at the CA level. Postfix, Dovecot, Exim, Exchange and every hosted mail platform read the same PEM or PFX file a web server reads. What differs between them is the installation, and on Exchange in particular the certificate has to be bound to services before anyone sees it — installing a certificate on Exchange Server walks through that step.
Where mail differs is in what checks the certificate on the other end. A browser checks one name against one address bar. A mail setup gets checked by three separate audiences: the mail client on a laptop, the sending servers of everyone who writes to you, and any policy layer those senders honor. Each looks at a hostname it obtained a different way, which is why a certificate that works perfectly for the website can still fail on the mail host.
Practical consequence: you can buy the cheapest DV certificate on the shelf and it will work, as long as the names are right. Getting the names wrong is what costs time, and no validation level fixes it.
Which hostname goes in the certificate?
Put in the hostname mail clients are configured with, and add the hostname your MX record resolves to if it is different. Those two names are the identities that anything on the far side of a TLS handshake will compare against. The domain in your email address plays no part in that comparison, even though it is the name most people reach for when they order.
Name matching follows the ordinary rules for service identity in RFC 6125: the client takes the name it used to reach the server and looks for it among the certificate's subject alternative names. It never derives a name from the recipient address, and it never falls back to the organization field. So you@example.com delivered to a host called mx1.example.com needs the certificate to say mx1.example.com.
How to find the right names in two minutes
Read them out of what is already running rather than from memory. Open the account settings of a mail client that connects successfully today and note the incoming and outgoing server fields. Then resolve your MX record. Between those two answers you have every name that belongs on the certificate.
| What you need | Where to read it | Typical value |
|---|---|---|
| Client hostname | Mail client account settings, incoming and outgoing server | mail.example.com |
| MX target | dig +short MX example.com | mx1.example.com |
| Webmail hostname | The address staff open in a browser | webmail.example.com |
| Autodiscover host | Only if Outlook autoconfiguration is in use | autodiscover.example.com |
All four can sit on one certificate as subject alternative names. Order them together and you avoid the situation where IMAP is clean and webmail throws a warning. If you have never generated a request with multiple names before, how a CSR carries those names is worth ten minutes before you order.
Why an S/MIME certificate will not work
An S/MIME certificate is issued to a mailbox or a person, carries an email address rather than a hostname, and holds the email protection key usage. A mail server certificate is issued to a DNS name and holds server authentication. Software enforces the difference: install an S/MIME certificate on a mail daemon and it either refuses to load the file or presents a certificate whose identity no client can match to a hostname.
The confusion is understandable, because both products get sold under the phrase "email certificate". Transport TLS stops someone on the network path from reading a message in flight, and it stops your users from typing a password into an impostor server. S/MIME keeps the message sealed even from the mail servers that carry it, and proves who wrote it. Plenty of organizations run both, because neither one does the other's job.
If message-level signing and encryption is what you were actually looking for, S/MIME certificates for individuals and businesses are the product for that job, and the practical guide to email certificates covers how they behave in a real mailbox.
Which ports and TLS modes does it cover?
One certificate covers every mail port on the host. A certificate binds a name to a key and says nothing about ports or protocols, so the same file serves submission on 465, IMAP on 993, POP3 on 995 and inbound SMTP on 25. What varies between those ports is when TLS starts, and that affects configuration rather than procurement.
Implicit TLS negotiates before any mail protocol traffic moves. STARTTLS opens in cleartext and upgrades on command, which leaves a window where an attacker in the path can strip the upgrade offer and watch the client fall back. RFC 8314 recommends implicit TLS for client connections for exactly that reason, and registers port 465 as the submissions service.
Server-to-server SMTP is the exception, and it has to be. A sending server cannot know in advance whether a stranger's mail host speaks TLS, so port 25 keeps STARTTLS and treats encryption as opportunistic. MTA-STS and DANE both exist to close that gap, which is where the certificate stops being cosmetic.
Wildcard, single name, or SAN?
A wildcard for *.example.com does cover mail.example.com and every other single label under the domain, so it works. A multi-name (SAN) certificate listing the mail hosts explicitly works too, and for most mail setups it is the better fit. The deciding factor is how many places that private key ends up.
The asterisk matches exactly one label. That catches people out on layered names: *.example.com covers mx1.example.com but not mx1.eu.example.com. Regional or per-datacenter mail hosts are usually where that bites.
The argument against reusing the web wildcard on mail
Sharing one wildcard across web and mail means the same private key sits on every one of those machines, so a compromise anywhere is a compromise everywhere, and a revocation forces a simultaneous replacement across services with different maintenance windows. There is also a protocol-level reason. The ALPACA research showed that when a certificate is valid for both an HTTPS endpoint and a mail service, an attacker can redirect a browser's TLS connection to the mail port and have it validate cleanly, because TLS authenticates the name and not the application answering behind it. The NSA published an advisory in 2021 recommending narrower certificate scope for that reason.
Reasonable default: a SAN certificate carrying your mail hostnames, kept separate from the certificate on the web servers. Reach for a wildcard when you are adding mail hosts often enough that reissuing becomes the bottleneck. Compare wildcard coverage and pricing if your naming is growing faster than your change windows, or read how wildcard and multi-domain certificates differ first.
What MTA-STS and DANE require from the certificate
MTA-STS demands a certificate that chains to a publicly trusted CA and matches the MX hostname; DANE does not require either. That difference decides how badly a name mismatch hurts. Under an enforced MTA-STS policy, a certificate that fails validation stops inbound mail from arriving. Under DANE, the TLSA record in DNS is the trust anchor, so the certificate is judged against that record rather than against a root store.
MTA-STS makes the certificate a delivery dependency
RFC 8461 specifies that a sending server honoring a policy must reach an MX host that offers STARTTLS and presents a non-expired, PKIX-valid certificate matching that host's DNS name. Miss any part of that and, in enforce mode, the sender refuses to deliver rather than falling back to cleartext. Ordinary opportunistic SMTP would have shrugged and delivered anyway, which is precisely what MTA-STS exists to prevent.
Two operational details follow from that. The MTA-STS policy is itself served over HTTPS from mta-sts.<your-domain>, so that host needs its own valid certificate before you publish anything. And multi-tenant mail platforms rely on SNI to pick the right certificate for the MX name being requested, so a host serving several domains needs each MX name covered.
DANE moves the trust decision into DNS
RFC 7672 lets you publish a TLSA record that pins the certificate or its public key. With DANE-EE usage, a sending server authenticates the host purely on that match, and the specification is explicit that the server is authenticated even when no name in the certificate matches. A self-signed certificate can satisfy DANE. The prerequisite is a DNSSEC-signed zone: without one, compliant senders ignore the TLSA record entirely.
If you run both: the stricter side sets the bar. Publishing DANE does not exempt the host from MTA-STS validation for senders who use the policy, so keep the publicly trusted certificate correct and let DANE add its own guarantee on top.
DV or OV for a mail host?
Either level works, and nothing in the mail path treats them differently. Mail clients and sending servers check the chain, the dates and the name; none of them read the organization field or change behaviour based on validation level. A DV certificate secures a mail server exactly as effectively as an OV one, which is why so much of the internet's mail runs on free automated certificates.
The case for OV is about people rather than protocol. A certificate that names your legal entity gives an auditor, a security questionnaire or a customer's IT department something to verify when they inspect the mail host, and DV gives them nothing beyond domain control. Regulated industries and B2B suppliers running vendor reviews tend to end up on OV for that paperwork reason.
| Situation | Reasonable choice |
|---|---|
| Small team, self-hosted mail, no compliance obligations | DV, automated renewal |
| Mail host inspected during vendor security reviews | OV, organization named |
| Mail platform serving several customer domains | OV multi-name, one certificate per MX identity set |
| Host that cannot answer HTTP for validation | Either level, validated by DNS record |
One validation note specific to mail hosts. Domain control checks often default to serving a file over HTTP, and a machine that only listens on mail ports cannot do that. Ask for DNS-based validation when you order, or open port 80 for the length of the check. The step-by-step certificate selection guide walks the same decision for the rest of your estate.
What the 200-day limit changes for mail
Since March 15, 2026, publicly trusted TLS certificates carry a maximum validity of 200 days under the CA/Browser Forum schedule introduced by ballot SC-081v3, with commercial CAs issuing at 199 days to stay inside the ceiling. The schedule continues: 100 days from March 15, 2027, and 47 days from March 15, 2029. Mail servers are covered by this like anything else, and they are the hosts most likely to be forgotten.
Mail expiry fails quietly in a way web expiry does not. Nobody browses to a mail server, so there is no wave of user reports on day one. Clients start refusing connections, senders honoring an MTA-STS policy stop delivering, and the first signal is often a customer asking why nobody replied. Renewal that runs twice a year rather than annually turns a task people remember into one that has to be automated.
The step teams miss: renewal scripts written for a web server reload nginx or Apache and stop there. Postfix and Dovecot hold the certificate in memory and will happily keep serving the expired one until they are reloaded too. Add the mail daemons to the deploy hook and verify with an actual connection to port 993, not by checking the file on disk. Our SSL checker reads what a host is really presenting, which is the only answer that counts here.
The mistakes that break mail
Four failure patterns account for most mail certificate tickets, and all four are visible before you order rather than after. Each one produces a distinctive symptom, which makes diagnosis quick once you know the shape.
| Mistake | What it looks like | Fix |
|---|---|---|
| Certificate names the domain, not the host | Client warns that the server name does not match | Reissue with the client hostname and MX target as SANs |
| Intermediate chain not served | Works in one client, fails in another; senders drop to unauthenticated TLS | Concatenate the intermediates into the file the daemon reads |
| Web server renewed, mail daemon not reloaded | HTTPS is current while port 993 still serves the expired certificate | Reload Postfix and Dovecot in the same deploy hook |
| Self-signed certificate left in place | Users trained to accept warnings; MTA-STS senders refuse delivery | Replace with a publicly trusted certificate before publishing any policy |
The chain problem deserves a word, because it hides better than the others. Some clients cache intermediates from previous connections and validate a host that is objectively serving an incomplete chain, so testing from one laptop proves nothing. Mail servers on the far side have no such cache. How an incomplete chain breaks validation covers the mechanism and the repair.
Frequently asked questions
Ordering the certificate
Once you have the hostname list, the rest is a normal certificate order. Browse DV and OV SSL certificates and add every mail name to the same request. My-SSL is a Certum partner, so the certificates chain to a root that has been in the public trust stores for years, which is the property MTA-STS validation actually depends on.
Related reading
- Which SSL certificate do I need? — the same decision applied across web, mail and everything else you run.
- Wildcard vs multi-domain certificates — how the two coverage models differ once you have more than one host to name.
- Installing the certificate on Postfix and Dovecot — the next step once you have the file, including the chain order each daemon expects.
- What an email certificate actually does — the S/MIME side, for when the message rather than the connection is the thing to protect.