TLS protects a message while it moves between cooperating mail servers. It does not replace SPF, DKIM or DMARC, and opportunistic delivery behaviour must be understood before requiring encryption on every destination.
1. Use a valid mail hostname
The SMTP hostname should resolve to the sending server and present a certificate whose name matches the service hostname. Keep certificate renewal automated and monitor expiry.
2. Enable modern STARTTLS
Offer STARTTLS on server-to-server SMTP and disable obsolete protocol versions and weak ciphers where the platform supports it. Test the actual public hostname from outside the server network.
3. Choose opportunistic or required TLS deliberately
Opportunistic TLS allows delivery when a recipient server cannot negotiate encryption. Required TLS improves transport assurance but can defer or fail mail to destinations with broken TLS. Use policy-based enforcement for destinations that require it.
4. Monitor transport results
Track certificate errors, handshake failures, downgrade behaviour and the encryption dashboard in Postmaster Tools. A high TLS rate confirms transport encryption, not recipient consent or inbox placement.
Implementation checklist
- Hostname resolves correctly
- Certificate name matches
- Certificate renewal monitored
- STARTTLS offered
- Legacy protocols disabled where possible
- TLS failures visible in logs
Primary references
Share the sending domain, route, message purpose, expected volume and a recent received-message header.
Request technical review