Email protocols series. This is the tactical TLS/SSL setup guide. For the conceptual overview of how SMTP, IMAP and POP3 fit together, read the email protocols hub →
Quick TLS/SSL reference
TLS protects email in two very different places: the client-to-server submission link (where your desktop, phone, or app connects to your provider) and the MTA-to-MTA transport link (where mail servers exchange messages with each other). Both need TLS. The enforcement mechanism is different for each.
| Modern default | TLS 1.3 preferred, TLS 1.2 minimum accepted |
| Submission ports | 587 with STARTTLS or 465 with Implicit TLS (RFC 8314) |
| Retrieval ports | 993 IMAP + 995 POP3 (Implicit TLS) |
| MTA-to-MTA | Port 25 STARTTLS, enforced by MTA-STS and/or DANE |
| Enforcement | MTA-STS (RFC 8461), DANE (RFC 7672), TLS-RPT (RFC 8460) |
This guide covers the actual configuration and DNS setup for both submission and transport, the certificate requirements that mail servers care about, and the policy mechanisms (MTA-STS, DANE, TLS-RPT) that stop opportunistic TLS from being silently stripped by a man-in-the-middle. For context on how TLS fits with the broader email protocol stack, see our email protocols overview; this page picks up where that one ends.
Two TLS models: Implicit vs STARTTLS
Every TLS-enabled email connection uses one of two negotiation models. The difference matters because the wrong pairing (port with mode) breaks the connection outright.
Implicit TLS (SSL)
TLS from the first byte. The connection is encrypted before any SMTP, IMAP, or POP3 command is exchanged. Uses dedicated ports: 465 for SMTP submission, 993 for IMAP, 995 for POP3. If the TLS handshake fails, the connection never opens; no plaintext fallback is possible.
STARTTLS (opportunistic upgrade)
Connection starts in plaintext. The server advertises STARTTLS capability in its greeting; the client issues a STARTTLS command; both parties upgrade to TLS. Same port as unencrypted (587 for SMTP submission, 143 for IMAP, 110 for POP3, and 25 for MTA-to-MTA relay).
Which is better?
For client submission, both are equivalent per RFC 8314 (2018). Implicit TLS has a small edge because there is no plaintext phase where a MitM could strip the STARTTLS advertisement; the client either gets TLS or gets nothing. STARTTLS on 587 is more widely deployed, though, and works cleanly when the port is otherwise reserved. For MTA-to-MTA relay, STARTTLS on port 25 is the only option, which is exactly why MTA-STS and DANE exist.
Port to TLS mode reference
| Port | Protocol | TLS mode | Notes |
|---|---|---|---|
| 25 | SMTP relay (MTA-to-MTA) | STARTTLS opportunistic | Never for clients; enforce with MTA-STS or DANE |
| 587 | SMTP submission | STARTTLS mandatory (RFC 8314) | Modern default for client sending |
| 465 | SMTP submission | Implicit TLS | Legacy but still valid per RFC 8314 |
| 143 | IMAP | STARTTLS | Legacy; prefer 993 |
| 993 | IMAP | Implicit TLS | Modern default for mail retrieval |
| 110 | POP3 | STARTTLS | Legacy; prefer 995 |
| 995 | POP3 | Implicit TLS | Modern default |
Match the port to the mode. A client configured for STARTTLS on 465 fails because the server expects TLS immediately. A client configured for Implicit TLS on 587 fails because the server expects plaintext SMTP first. If your client separates the two settings, verify both align before troubleshooting anything else.
TLS versions in email, 2026
The negotiation of TLS version is separate from the negotiation of the encryption mode. In 2026, the situation is:
- TLS 1.3: preferred. Faster handshake (fewer round trips), mandatory forward secrecy, cleaner cipher suite list. Gmail, Microsoft 365, Yahoo, iCloud, and every major ESP all negotiate 1.3 by default.
- TLS 1.2: still accepted, still widely used. Required for compatibility with slightly older clients and self-hosted servers. All major providers accept 1.2.
- TLS 1.1 and 1.0: dead. Every major provider deprecated them by 2023. Configuring a client for TLS 1.0/1.1 causes silent connection failures.
- SSLv3, SSLv2: dead for over a decade. Any code path that still touches them is a security incident.
To check what version your client negotiates:
openssl s_client -connect imap.gmail.com:993 -tls1_3
openssl s_client -connect smtp.gmail.com:587 -starttls smtp -tls1_2If the connection succeeds, that version is supported. If it fails with a protocol error, the server refuses that version. Combine with -cipher to test specific cipher suites.
Certificate requirements
Mail servers demand the same certificate hygiene as HTTPS servers, plus a few email-specific quirks:
- Publicly trusted CA. The cert must be signed by a CA in the public trust store. Let’s Encrypt is free and works fine. Self-signed certs cause fatal errors at any major receiver.
- Hostname match. The certificate’s Subject or Subject Alternative Names (SAN) must include the hostname the client connects to. For example, if a client connects to
mail.example.com, the cert must include that exact hostname in SAN. Wildcard certs (*.example.com) work but do not cover the bare apex. - Full chain served. The server must send the leaf cert plus all intermediate CAs. A missing intermediate causes “unable to verify” errors on some clients (especially older ones that do not fetch intermediates automatically).
- Not expired. Renewal automation (certbot, acme.sh) is non-negotiable for production mail servers. A cert that expires on a Sunday afternoon means Monday’s mail bounces.
- Matches MX records. For MTA-to-MTA, the cert on the receiving MX host must include the MX hostname. This trips people up when they have
example.comas the mail domain but the MX points tomx.example.net; the cert must include the MX name.
The MTA-to-MTA problem: opportunistic TLS
Client submission (port 587 or 465) is simple: TLS is mandatory, no fallback. MTA-to-MTA relay on port 25 is different, and this difference is where most email TLS problems originate.
Port 25 STARTTLS is opportunistic. If the sending MTA sees STARTTLS advertised in the receiving MTA’s EHLO response, it upgrades. If not, or if the STARTTLS command fails, it falls back to plaintext. This fallback exists because refusing to relay mail would break every legacy email server. But the fallback also means: a man-in-the-middle can strip the STARTTLS advertisement, force plaintext, and read the messages. Both parties think they tried TLS. Neither notices the downgrade.
Three mechanisms fix this:
- MTA-STS: your domain publishes a policy saying “MTAs sending to my domain MUST use TLS with a valid cert”. Compliant senders enforce.
- DANE: DNSSEC-backed cert pinning. Your DNS declares the exact cert (or CA) your MTA presents, and senders verify.
- TLS-RPT: a reporting channel so you find out when senders fail to reach you over TLS.
MTA-STS is the pragmatic default for most domains. DANE adds an extra layer for those with DNSSEC deployed. TLS-RPT complements both by giving you visibility into failures.
MTA-STS (RFC 8461)
Three pieces:
- DNS TXT record at
_mta-sts.example.com: signals the policy exists and includes a version identifier. Example:
The_mta-sts.example.com. IN TXT "v=STSv1; id=20260701T120000;"idfield changes when the policy updates; senders cache by id. - Policy file served over HTTPS at
https://mta-sts.example.com/.well-known/mta-sts.txt. Example content:version: STSv1 mode: enforce mx: mail.example.com mx: *.mailhost.example.net max_age: 604800 - MX records in DNS: unchanged, but the MX hostnames must match the policy’s
mx:lines, and those hostnames must present valid certs.
The mode field takes one of three values:
- none: policy is being retired; ignore.
- testing: senders check but do not enforce. Failures generate TLS-RPT reports.
- enforce: senders refuse to deliver if TLS or cert validation fails.
Rollout best practice: publish in testing mode for two to four weeks, watch TLS-RPT reports, fix any cert issues, then flip to enforce. Skipping the testing phase invites mail loss.
DANE / TLSA records (RFC 7672)
DANE binds the certificate to the DNS record. A TLSA record in DNS says “this specific cert (or CA) is the one my MTA presents; if you see something else, reject”. DANE requires DNSSEC on the domain, otherwise the TLSA lookup can be forged.
Example TLSA record for the MX host:
_25._tcp.mail.example.com. IN TLSA 3 1 1 <sha256-of-cert-public-key>The three fields before the hash: usage (3 = domain-issued certificate), selector (1 = subject public key), matching type (1 = SHA-256). Different combinations trade off flexibility for security.
DANE and MTA-STS are complementary. MTA-STS is easier to deploy (no DNSSEC required). DANE is stricter (cryptographic proof via DNS). Large providers like Google, Microsoft, and Comcast increasingly check both. If you have DNSSEC, deploy both; if not, MTA-STS alone still covers the majority of the risk.
TLS-RPT (RFC 8460)
The reporting channel. A domain publishes a TXT record at _smtp._tls.example.com with a rua= address for aggregate TLS failure reports:
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"Compliant senders (Google, Microsoft, Yahoo, and others) send daily JSON reports listing successful and failed TLS connections to your MTA. Failures include the reason (cert expired, hostname mismatch, no STARTTLS, downgrade suspected). Without TLS-RPT, you find out about TLS issues only when someone complains that mail is disappearing.
Set up TLS-RPT alongside MTA-STS. Even in testing mode, the reports tell you what’s actually happening on the wire.
Setup walkthrough by role
Client submitting mail (SMTP)
Set the SMTP server hostname, port 587 with STARTTLS or 465 with Implicit TLS, TLS 1.2+ enabled, authentication with app password or OAuth2. The cert on the server is the provider’s problem; your job is to trust the CA (default on any modern OS). See our SMTP setup guide for the client-side detail.
Client receiving mail (IMAP)
Set the IMAP hostname, port 993 with Implicit TLS, TLS 1.2+ enabled, authentication with app password or OAuth2. Same principle as SMTP: verify the port and TLS mode align. See our IMAP configuration guide.
Client receiving mail (POP3)
Port 995 with Implicit TLS. See our POP3 configuration guide.
Outbound MTA (server-to-server)
Enable STARTTLS on outbound, honor destination MTA-STS and DANE policies. For Postfix:
smtp_tls_security_level = dane
smtp_tls_note_starttls_offer = yes
smtp_tls_loglevel = 1
smtp_dns_support_level = dnssecFor Exim, set tls_advertise_hosts, hosts_require_tls per destination, and enable DANE via the router configuration. For sendmail, migrate to Postfix or Exim; sendmail’s STARTTLS support is dated.
Inbound MTA (receiving mail from the internet)
Publish MTA-STS policy in testing, verify reports for two to four weeks, then flip to enforce. Publish TLSA records if DNSSEC is deployed. Publish TLS-RPT for visibility. Serve a valid cert covering the MX hostname on port 25, ensure the full chain is served, automate renewal.
Testing TLS
OpenSSL for hands-on testing
openssl s_client -starttls smtp -connect smtp.example.com:587
openssl s_client -connect imap.example.com:993
openssl s_client -connect pop.example.com:995Shows the TLS handshake, negotiated version and cipher, certificate chain, and lets you issue protocol commands manually.
testssl.sh for comprehensive audit
./testssl.sh --starttls smtp smtp.example.com:587
./testssl.sh imap.example.com:993Audits protocol versions, cipher suites, cert validity, known vulnerabilities. The most complete TLS testing tool for the command line.
Hardenize for domain-wide policy audit
The Hardenize web tool checks MTA-STS, DANE, TLS-RPT, cert validity, and TLS version support for an entire domain. Best single-shot view of your email TLS posture.
CheckTLS.com for MTA-to-MTA delivery test
Sends a probe to your MX and shows whether TLS was negotiated end to end. Useful for verifying that a specific test message actually travels encrypted.
Google Postmaster Tools TLS metric
Shows the share of your outbound mail to Gmail that was delivered over TLS. Any percentage below 100 percent indicates a subset of connections dropping to plaintext; investigate via TLS-RPT reports. See our Google Postmaster Tools guide.
Diagnosing common TLS errors
| Error | Likely cause | Fix |
|---|---|---|
certificate verify failed | Missing intermediate, expired cert, or hostname mismatch | Verify chain with openssl s_client; renew if expired; add missing SAN |
no shared cipher | Client and server cannot agree on a cipher | Check TLS version; enable TLS 1.2/1.3 on client; update server cipher list |
protocol version | Client only supports TLS 1.0/1.1; server refuses | Upgrade client to TLS 1.2+; update OS |
STARTTLS not supported | Server does not advertise it (or MitM stripping) | Verify with openssl; deploy MTA-STS to detect stripping |
hostname does not match | Cert SAN does not include the connected hostname | Reissue cert with correct SAN; check MX hostname alignment |
| Connection succeeds but mail bounces at destination | Destination MTA-STS in enforce mode; your cert is invalid | Fix your cert; check TLS-RPT reports from destination |
| Intermittent TLS failures | Multiple MX hosts, one with cert issue | Check every MX cert individually with openssl |
| MTA-STS not detected by receivers | DNS TXT record missing, HTTPS policy file 404, or id mismatch | Verify via Hardenize; ensure both TXT and HTTPS resource exist |
10 common TLS setup mistakes
- Mismatched port and TLS mode. Port 465 with STARTTLS or 587 with Implicit TLS both fail. Match them.
- Deploying MTA-STS directly to enforce mode. A cert issue causes silent mail loss. Always start in testing mode with TLS-RPT enabled.
- Cert covers
example.combut MX points tomx.example.com. The cert must cover the MX hostname the sender actually connects to. - Missing intermediate CA in chain. Older clients (and some MTAs) do not fetch intermediates automatically. Serve the full chain.
- Relying on TLS 1.0/1.1. Deprecated everywhere. Upgrade or replace the client.
- Publishing MTA-STS without HTTPS policy file. The TXT record advertises the policy, but the actual policy file must be reachable over HTTPS at the well-known URL. Both must exist.
- Forgetting to rotate the MTA-STS
id. Senders cache by id; if you update the policy but keep the same id, cached senders never see the update. - DANE without DNSSEC. DANE requires DNSSEC to be meaningful. TLSA records without DNSSEC can be spoofed.
- No TLS-RPT. You have no visibility into TLS failures. Set up TLS-RPT even without MTA-STS.
- No cert renewal automation. A cert expiring at 3am is a queue full of bounced mail by 9am. Use certbot or acme.sh with automated reload.
TLS setup FAQ
Should I use STARTTLS or Implicit TLS for client submission?
Either works. RFC 8314 (2018) validates both. Match the port: 587 uses STARTTLS, 465 uses Implicit TLS. Implicit TLS is slightly safer because there is no plaintext phase where a man-in-the-middle could strip the STARTTLS advertisement, but this attack is largely mitigated on submission by the mandatory-TLS requirement. Use whichever the client supports cleanly; both are correct.
Is TLS 1.2 enough, or should I require 1.3?
TLS 1.2 is sufficient. All major providers accept both 1.2 and 1.3, and negotiate the highest supported by both sides. Refusing 1.2 outright blocks a non-trivial share of client software that has not yet moved to 1.3 (older desktop clients, embedded devices, legacy scripts). Accept 1.2 and 1.3, refuse 1.0 and 1.1.
Do I really need MTA-STS?
For any domain sending or receiving business email, yes. Without MTA-STS, opportunistic TLS on port 25 can be silently stripped by a man-in-the-middle, and neither party knows. Gmail, Microsoft 365, and Yahoo all check MTA-STS policies. Deployment is a DNS TXT record plus a static HTTPS file, roughly an hour of work. The alternative is invisible TLS downgrades.
How do I know if my outbound mail actually travels over TLS?
Publish TLS-RPT and read the daily aggregate reports from Google, Microsoft, Yahoo and others. The reports break down every session by TLS status: negotiated, failed to STARTTLS, failed to validate cert. For a per-connection view, enable STARTTLS logging on your outbound MTA (in Postfix, smtp_tls_loglevel = 1). Google Postmaster Tools also shows the TLS delivery percentage for your outbound to Gmail.
Can I use a self-signed certificate on my mail server?
Not for public-facing servers. Every major receiver rejects self-signed certs when policy enforcement is active (MTA-STS, DANE, and most modern clients). For internal or lab setups where you control both endpoints, self-signed works as long as the client explicitly trusts your CA. For production, use Let’s Encrypt (free, automated) or a paid public CA. There is no legitimate case for self-signed on a public MTA in 2026.
What is the difference between MTA-STS and DANE?
MTA-STS is HTTPS-based: the receiving domain hosts a policy file over HTTPS, and the DNS TXT record signals its existence. It requires no DNSSEC. DANE is DNS-based: the domain publishes a TLSA record with a hash of the cert or CA, and DNSSEC signs the record so it cannot be spoofed. MTA-STS is easier to deploy (no DNSSEC required, works with any DNS provider), DANE is cryptographically stricter. The two are complementary; large receivers increasingly check both. Deploy MTA-STS first as the baseline; add DANE if you have DNSSEC.
Final words
Client-side TLS setup is memorization: match the port, match the mode, use TLS 1.2 or 1.3, use a valid cert. Where the real work happens is server-to-server: MTA-STS to enforce TLS on the receiving side, DANE if you have DNSSEC, TLS-RPT to see what’s actually happening on the wire. Domains that skip these mechanisms have TLS in name only; a MitM can strip STARTTLS on any hop and neither sender nor receiver notices.
The good news is that deployment is not hard. MTA-STS is a DNS record plus a static file. TLS-RPT is one more DNS record. Cert automation with Let’s Encrypt is a cron job. Together, these three primitives cover most of the real-world risk.
For broader context, see the email protocols overview, the SMTP setup guide, the IMAP configuration guide, the POP3 configuration guide, and the email forwarding guide for the DMARC-adjacent problems TLS does not solve.
Clean your list before TLS protects a single message.
SMTPing catches what regex misses: disposable addresses, role-based emails, catch-all domains, syntax errors, dead mailboxes and known traps. 13 validation types, 25 free checks daily, no card required.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
