Disabling TLS 1.0 and TLS 1.1 for outgoing email is usually the right security move, but it does not automatically mean more bounces. The result depends on whether your mail server uses opportunistic STARTTLS or mandatory TLS. With opportunistic STARTTLS, mail to a receiver that only supports TLS 1.0 or TLS 1.1 will often fall back to clear text. With mandatory TLS 1.2 or newer, that same message will fail delivery.
The practical answer is this: turn off TLS 1.0 and TLS 1.1, keep opportunistic STARTTLS for general internet mail, and require TLS 1.2 or newer only where the recipient domain or business relationship justifies it. For stricter transit security, honor recipient MTA-STS and DANE where available, collect TLS-RPT reports, and build a separate exception process for legacy destinations.
- Main implication: weak protocol negotiation goes away, but legacy receivers either get clear text fallback or a bounce depending on your policy.
- Best default: opportunistic STARTTLS with TLS 1.2 or TLS 1.3 enabled and TLS 1.0 and TLS 1.1 disabled.
- Best strict option: mandatory TLS for selected partner routes, plus MTA-STS or DANE enforcement when receiver policy supports it.
- Biggest trap: treating old TLS fallback and no encryption as the same risk. They have different audit, privacy, and delivery consequences.
What actually changes when TLS 1.0 and 1.1 are disabled
SMTP delivery uses STARTTLS as an upgrade mechanism. Your sending MTA connects to the recipient MX over port 25, reads the EHLO capabilities, and upgrades to TLS when the receiver advertises STARTTLS. After that, both sides negotiate a protocol version and cipher. If you disable TLS 1.0 and TLS 1.1, your sender refuses those old protocol versions during that negotiation.
That setting improves your security posture because TLS 1.0 and TLS 1.1 are obsolete. Microsoft's TLS note reflects the same direction in operating systems, and the Qualys grade change made old TLS support a visible security weakness for public services.
Do not confuse protocol removal with mandatory encryption
Disabling old TLS versions means your sender refuses weak encrypted sessions. It does not mean every outbound message is encrypted. Opportunistic STARTTLS still allows clear-text delivery when the recipient does not offer a usable encrypted path.
|
|
|
|
|---|---|---|---|
Opportunistic | No STARTTLS | Sent clear | No transit TLS |
TLS 1.2+ only | Old TLS only | Sent clear | Avoids weak TLS |
Required TLS | TLS fails | Bounced | No clear fallback |
MTA-STS | Policy fails | Deferred or bounced | Policy enforced |
DANE | TLSA fails | Deferred or bounced | DNSSEC-backed |
Outbound TLS modes and delivery behavior
The delivery risk
The direct bounce risk from turning off TLS 1.0 and TLS 1.1 is usually low if the sender remains opportunistic. The bigger change is reporting and visibility: some mail that used to travel over weak TLS now travels in clear text because the receiver has no modern encrypted option. If your compliance position treats weak TLS as worse than no encryption, that is acceptable. If your policy requires encryption for certain data, clear-text fallback is not acceptable.
In high-volume outbound programs, I expect TLS 1.2 and TLS 1.3 to cover the overwhelming majority of encrypted sessions. I have seen daily outbound mixes where more than 97% of delivered mail used TLS 1.2, and other sender fleets where TLS 1.2 or TLS 1.3 covered about 99.3% of traffic. The remaining traffic is usually a mix of clear-text destinations, misconfigured MX hosts, and legacy systems.
Example outbound mix after removing old TLS
Use your own MTA logs for final numbers. This shows the shape I usually expect before a strict rollout.
TLS 1.2+
Clear text
Legacy TLS
Requiring TLS 1.2 or newer for every outbound destination has a much larger impact than honoring recipient MTA-STS. MTA-STS only applies when the recipient publishes a policy, and failure tends to concentrate around a small set of domains with bad policy files, stale MX names, or certificate problems. A blanket mandatory TLS rule applies to every destination, including small receivers and older private systems.
The bounce cases to expect
- Protocol mismatch: the receiver only supports TLS 1.0 or TLS 1.1 and your policy requires TLS 1.2 or newer.
- Certificate failure: the MX certificate is expired, self-signed, incomplete, or issued for the wrong hostname.
- Policy mismatch: the recipient publishes MTA-STS or DANE data that does not match its real mail hosts.
- Operational gap: support teams see bounces but lack a clear route for customer, partner, or receiver remediation.
Alternatives available
There are several better alternatives than leaving TLS 1.0 and TLS 1.1 enabled forever. The right choice depends on the mail type, recipient risk, and your appetite for delivery failures. I separate normal marketing or transactional mail from mail that carries regulated data, invoices, credentials, legal notices, or contract material.
Permissive path
Use this for broad internet delivery where reach matters and message content is not sensitive.
- Old TLS off: remove TLS 1.0 and TLS 1.1 from outbound negotiation.
- Fallback allowed: allow clear-text delivery when no modern TLS path exists.
- Logging required: capture protocol, cipher, MX, destination, and failure reason.
- Customer notice: explain that weak TLS is gone and some receivers still lack encryption.
Stricter path
Use this for partners, regulated workflows, and destinations that publish enforceable policy.
- Route policy: require TLS 1.2 or newer for named domains or transport maps.
- Policy checks: honor recipient MTA-STS and DANE where the receiver publishes them.
- Report loop: review TLS-RPT data and map recurring failures to owners.
- Exception path: document who can approve fallback for a legacy receiver.
The exact settings vary by MTA, but the policy model stays consistent: remove obsolete protocols first, then decide where delivery must fail instead of falling back. I like to keep that decision out of ad hoc tickets by classifying destinations into default, monitored, required TLS, and blocked.
TLS-RPT DNS record exampledns
_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"
MTA-STS policy file exampletext
version: STSv1 mode: enforce mx: mail.example.com max_age: 86400
How I would roll this out
Flowchart showing a staged rollout for outbound TLS changes.
Start by measuring current delivery before changing policy. Pull logs for the last 30 days and group by destination domain, MX hostname, negotiated TLS version, cipher, certificate result, STARTTLS support, and final SMTP status. If you already monitor authentication and domain health in Suped, pair that with the domain health checker so DNS, DMARC, SPF, DKIM, and transport-adjacent checks sit in one workflow.
Then make the protocol change in a staged way. Do not start by forcing every destination to use TLS. That creates avoidable noise and hides the useful question: which destinations still depend on old TLS, and which of those destinations matter enough to contact or isolate?
- Baseline first: measure TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3, and clear-text delivery by domain.
- Disable old TLS: remove TLS 1.0 and TLS 1.1 from outbound encrypted negotiation.
- Keep default fallback: continue opportunistic STARTTLS for general mail while you collect impact data.
- Add strict routes: require TLS 1.2 or newer for specific partners, regulated streams, and receiver policies.
- Publish outcomes: report bounces, clear-text fallbacks, and recurring receiver failures to account owners.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
If this is an ESP or multi-tenant sending platform, treat the rollout as a customer-facing behavior change. A sender can be comfortable bouncing mail to a broken receiver, but a customer with time-sensitive notices sees that as a delivery failure. That is why I prefer route-level policy and clear reporting over one global switch.
Where MTA-STS, DANE, and TLS-RPT fit
MTA-STS and DANE are not simple substitutes for disabling TLS 1.0 and TLS 1.1. They answer a different question: when a receiver declares that TLS is required, should your sender deliver only after validating that encrypted path? For outgoing mail, your MTA honors the recipient's MTA-STS policy or DANE TLSA records. For inbound mail to your own domain, you publish the policy that other senders enforce. If that distinction is still fuzzy, this inbound versus outbound explainer helps: inbound or outbound.
DANE has strong cryptographic properties because it depends on DNSSEC and TLSA records. That strength also creates an operational dependency: DNSSEC must be correct, the receiving domain must publish usable TLSA records, and the sending MTA must validate them. MTA-STS is easier for many domains because it uses DNS plus a policy file over HTTPS, but it also depends on correct MX names and certificates.
Hosted MTA-STS configuration dialog showing policy mode, MX hosts, CNAME records, and verification
This is where Suped's product fits in a practical way. Suped brings DMARC, SPF, DKIM monitoring, hosted MTA-STS, hosted SPF, hosted DMARC, TLS reporting workflows, blocklist (blacklist) monitoring, and issue detection into one place. For teams that already use Suped for authentication monitoring, Hosted MTA-STS reduces the web-hosting and policy-file work that usually slows down adoption.
TLS-RPT closes the feedback loop. It tells you which sending sources failed to deliver to domains with MTA-STS or DANE policy and why. If you start receiving reports and need help interpreting them, the practical starting point is understanding MTA-STS reports before you adjust enforcement.
Best practical pattern
- Default mail: use opportunistic STARTTLS with TLS 1.0 and TLS 1.1 disabled.
- Sensitive routes: require TLS 1.2 or newer and accept bounces when validation fails.
- Receiver policy: honor MTA-STS and DANE when the destination domain publishes them.
- Monitoring loop: review TLS-RPT, MTA logs, DMARC failures, and domain health in the same queue.
Decision table for common policies
I would not make this a binary choice between old TLS and total bounce risk. Most teams need a layered policy that separates normal internet delivery from mail that has a firm encryption requirement. The table below is the model I use when deciding what to enforce.
|
|
|
|
|---|---|---|---|
Keep old TLS | Legacy reach | Weak encryption | Avoid |
Old TLS off | General mail | Clear fallback | Default |
Require TLS | Partners | More bounces | Selective |
Honor MTA-STS | Policy domains | Bad policies | Enable |
Honor DANE | DNSSEC domains | DNSSEC dependency | Enable |
Policy choices for outbound email TLS
For most senders, the strongest practical choice is not a single switch. It is observability plus staged enforcement. Suped is a good fit for that pattern because the same product can show authentication problems, surface DMARC issues, monitor blocklist and blacklist exposure, manage hosted policies, and send real-time alerts when something changes.
Views from the trenches
Best practices
Measure TLS versions by destination before changing the sender's default behavior.
Keep opportunistic STARTTLS for broad mail while strict routes are tested first.
Separate legacy receiver exceptions from normal routing and customer reporting paths.
Review TLS-RPT and MTA logs together so policy failures have clear named owners.
Common pitfalls
Assuming old TLS removal creates bounces when fallback still remains enabled for mail.
Forcing mandatory TLS globally before support teams can explain each failure case.
Treating broken receiver certificates as sender defects without routing evidence.
Publishing MTA-STS without checking every MX name and certificate before launch.
Expert tips
Use route-level required TLS for sensitive streams before expanding enforcement.
Track clear-text fallback as a risk metric, not only as a deliverability metric.
Classify receivers by business value before deciding who gets exception handling.
Pair hosted policy management with alerts so stale MX changes are caught quickly.
Marketer from Email Geeks says disabling TLS 1.0 and TLS 1.1 usually leads to clear-text fallback under opportunistic delivery, not immediate bounces.
2022-08-16 - Email Geeks
Marketer from Email Geeks says weak encryption can give teams a false sense of protection, so clear reporting matters when fallback is allowed.
2022-08-16 - Email Geeks
The practical answer
I would disable TLS 1.0 and TLS 1.1 for outgoing encrypted email. I would also keep opportunistic STARTTLS for normal internet delivery unless the organization has a hard rule that some messages must never travel without encryption. That combination removes obsolete encrypted sessions without creating an unnecessary bounce spike.
For higher-risk mail, use required TLS by route, honor recipient MTA-STS and DANE, collect TLS-RPT, and report failures in a way customers or account teams can act on. The best operational setup is one where the sender can answer three questions quickly: which destinations lost modern TLS, which messages fell back to clear text, and which failures deserve receiver outreach.
Suped's product is useful here because TLS policy work rarely sits alone. It sits beside DMARC enforcement, SPF lookup limits, DKIM domain matching, hosted policy records, real-time alerts, and reputation monitoring. Keeping those signals in one place makes the change easier to operate after the first rollout.
