SSL/TLS Certificates for Mail Servers (SMTP, IMAP, POP3)

An SSL certificate for mail server software is a standard TLS server certificate installed on your SMTP, IMAP and POP3 services. It encrypts the connection between mail clients and your server, and between your server and other mail servers, and it proves your server’s hostname to whoever connects.

It must cover every hostname that clients and servers actually use, such as mail.example.com or smtp.example.com. When those are several names, a multi-domain certificate is the usual choice.

Service	Port	How TLS starts
SMTP server-to-server relay	25	STARTTLS (upgrade after connecting)
SMTP submission from mail clients	587	STARTTLS
SMTP submission from mail clients	465	Implicit TLS (encrypted from the first byte)
IMAP	143 / 993	STARTTLS / implicit TLS
POP3	110 / 995	STARTTLS / implicit TLS

Does your mail server need an SSL certificate?

Yes. Any mail server that accepts logins or exchanges mail over the internet needs a TLS certificate, whether it uses STARTTLS or implicit TLS. Without one, passwords and messages travel in plain text, and many mail clients warn users about the connection.

STARTTLS (a command that upgrades a plain connection to an encrypted one) and implicit TLS (a connection that is encrypted from the start, on its own port) use the same certificate. You install it once and every service that offers TLS presents it.

The certificate must be publicly trusted. A self-signed certificate triggers warnings in Outlook, Apple Mail and phone mail apps, and users learn to click through them. Our page on self-signed vs CA-signed SSL explains why that is risky.

Which names does an SSL certificate for a mail server need?

It needs every hostname that clients and servers connect to, listed as Subject Alternative Names (SANs, the field that holds all names a certificate covers). For most domains that means the mail host, any separate SMTP or IMAP names and the autodiscover name used by Outlook.

Hostname	Why it needs to be on the certificate
mail.example.com	The usual name for IMAP, POP3 and webmail
smtp.example.com	Outgoing mail configured in clients
imap.example.com	Only if clients use this name instead of mail.
autodiscover.example.com	Outlook’s automatic account setup
Your MX hostname	The name other mail servers connect to on port 25

A multi-domain (SAN) SSL certificate lists these names in one certificate. A wildcard for *.example.com also covers them, because each is one level below your domain, but it covers no deeper names. Internal-only names such as mail.local cannot go on any public certificate, because public CAs have not issued for internal names since 2015.

Tip: Check your MX record before you order. If your MX points to mx1.example.com, that name belongs on the certificate too, or senders that enforce TLS policies will reject the connection.

MX hosts, MTA-STS and certificate checks

Many sending servers use opportunistic STARTTLS on port 25 and accept almost any certificate. Domains that publish an MTA-STS policy (SMTP MTA Strict Transport Security, RFC 8461) change that. Senders that honor the policy require a certificate that is unexpired, chains to a trusted root and matches the MX hostname.

Under RFC 8461 a wildcard matches only the left-most label, so *.example.com matches mail.example.com but not example.com or mx.eu.example.com. A missing intermediate certificate also fails these checks; see our guide to the SSL certificate chain.

Is a mail server certificate the same as S/MIME?

No. A mail server certificate encrypts the connection between machines. An S/MIME certificate belongs to a person or mailbox and signs or encrypts the message itself, so it stays protected after delivery.

Point	Mail server TLS certificate	S/MIME certificate
Issued to	A hostname, such as mail.example.com	An email address or person
Protects	The connection in transit	The message content end to end
Installed on	SMTP, IMAP and POP3 services	The user’s mail client
Visible to recipients	No	Yes, as a signature

If you need signed or encrypted messages, read our guide to S/MIME email signing. Many organizations use both.

Can you use your website certificate for email?

Yes, if the certificate covers the mail hostnames. A certificate for example.com and www.example.com does not cover mail.example.com, so clients connecting to that name see an error. A wildcard or a multi-domain certificate that includes the mail names works on both servers.

Sharing one certificate means sharing its private key between your web and mail servers. If those run at different providers, consider separate certificates, so a compromise or a reissue on one side doesn’t force changes on the other.

Where the SSL certificate for mail server software goes

Each mail server reads the certificate and private key from its own settings. Include the intermediate certificates after your server certificate, or some clients and servers will fail to validate it.

Server	Setting	Notes
Postfix 3.4 and later	smtpd_tls_chain_files	One file: private key, then certificate, then intermediates
Postfix before 3.4	smtpd_tls_cert_file, smtpd_tls_key_file	Certificate file holds server certificate, then intermediates
Dovecot 2.3	ssl_cert, ssl_key	Point to the full-chain file and key
Dovecot 2.4	ssl_server_cert_file, ssl_server_key_file	Renamed settings; same full-chain file
Microsoft Exchange	Exchange admin tools	Assign the certificate to SMTP and IMAP/POP services

Exchange has its own naming and service-assignment rules; our page on SSL for Microsoft Exchange covers them. For CSR creation, file formats and web-server installs, see how to install an SSL certificate.

After installing, test each port from outside your network. For example, openssl s_client -connect mail.example.com:993 checks IMAPS, and openssl s_client -starttls smtp -connect mail.example.com:587 checks submission. Confirm the names, the expiry date and that the chain is complete.

Renewing mail server certificates

As of October 2026, publicly trusted TLS certificates last at most 200 days. The maximum drops to 100 days on 15 Mar 2027 and to 47 days on 15 Mar 2029, so mail servers need the same automated renewal as websites.

Remember that mail daemons usually read certificates at start-up. Your renewal process must reload Postfix, Dovecot or Exchange services after a new certificate is in place, or the old one keeps being served until it expires.