Most administrators assume that because their mail server 'supports TLS', their email is encrypted in transit. In reality, classic SMTP encryption is opportunistic: two servers try to upgrade the connection with STARTTLS, but if anything goes wrong—a certificate mismatch, a network error, or an attacker stripping the upgrade—the conversation silently falls back to plain text. Neither side logs an obvious failure, and the message still delivers.
This is the second article in the Solution Savy series on Microsoft 365 and Exchange architecture. It explains why opportunistic TLS is not enough, and how three standards—DNSSEC, DANE, and MTA-STS—turn optional encryption into enforced encryption for your Exchange and Microsoft 365 mail flow.
The problem: downgrade and interception attacks
Because STARTTLS negotiation happens in plain text, an attacker positioned between two mail servers can remove the STARTTLS capability or interfere with the handshake. The sending server, designed to deliver mail rather than fail, simply continues unencrypted. This is a downgrade attack, and it requires no malware, no credentials, and no access to either server—only a position on the network path.
A related risk is DNS spoofing: if an attacker can tamper with MX record lookups, they can redirect your inbound mail through a server they control, read or modify it, and forward it on. Senders would have no idea anything changed.
Layer one: DNSSEC signs your DNS answers
DNSSEC adds cryptographic signatures to DNS records so resolvers can prove an answer came from the authoritative zone and was not modified in transit. It does not encrypt DNS queries; it authenticates them. For mail security, DNSSEC is the foundation layer: both DANE and the trust in your MX records depend on DNS answers that cannot be forged.
Enabling DNSSEC is done at your DNS provider and domain registrar: the provider signs the zone, and you publish a DS record at the registrar to complete the chain of trust. Most major DNS hosts support this with a toggle, but verify that your registrar supports DS records for your top-level domain before you start.
Layer two: DANE binds TLS to DNS
DANE (DNS-based Authentication of Named Entities) lets you publish a TLSA record in DNS that states which certificate your mail server must present. A sending server that supports DANE checks the TLSA record, verifies it with DNSSEC, and refuses to deliver if the certificate does not match or encryption cannot be established. The silent fallback to plain text is gone.
Microsoft has rolled out inbound DANE support for Exchange Online, and outbound DANE for Exchange Online has been a major roadmap investment—check the current Microsoft 365 roadmap and Message Center for the status in your tenant. For on-premises Exchange, your sending partners' servers do the DANE validation, so publishing correct TLSA records for your MX hosts still protects your inbound stream.
DANE requires DNSSEC. A TLSA record without DNSSEC is untrusted and ignored.
Certificate renewals must be coordinated with TLSA record updates, or remote servers will reject your mail. Automation is essential.
Use TLSA usage type 3 1 1 (domain-issued certificate, public key match) where possible—it survives certificate re-issuance better than matching the full certificate.
Layer three: MTA-STS enforces TLS without DNSSEC
MTA-STS takes a different approach: you publish a policy over HTTPS at a well-known address that tells sending servers your domain requires TLS, which MX hosts are valid, and what to do when negotiation fails. A companion DNS TXT record (_mta-sts) signals that a policy exists, and an optional TLS-RPT record tells senders where to email aggregate reports about negotiation failures.
MTA-STS does not require DNSSEC, which makes it practical for domains whose DNS providers cannot sign zones. Its weakness is the trust-on-first-use model: a sender must have seen your policy before. DANE and MTA-STS are complementary, not competitors—Microsoft's own guidance for Exchange Online is to deploy both, since different sending ecosystems support different standards.
What this means for Exchange and Microsoft 365
Exchange Online tenants: confirm your accepted domains' MX records point to Microsoft, enable DNSSEC at your DNS provider where supported, and follow Microsoft's documentation for enabling inbound DANE on your domains.
On-premises Exchange: publish TLSA records for your MX hostnames, keep certificates from a public CA, and automate TLSA updates alongside certificate renewal.
Hybrid environments: secure both legs. Mail between your on-premises servers and Exchange Online uses connectors with TLS enforcement, but mail to and from the rest of the internet still depends on the standards above.
Add a TLS-RPT reporting address from day one. The reports show you which sending servers fail negotiation before you switch any policy from testing to enforce mode.
A safe rollout order
Deploy in stages so you never reject legitimate mail. First, enable DNSSEC and confirm validation with a resolver such as dnsviz.net. Second, publish your MTA-STS policy in testing mode and collect TLS-RPT reports for at least two weeks. Third, publish DANE TLSA records and monitor. Finally, move MTA-STS to enforce mode once reports are clean. Each stage is reversible; the final one is not something to rush.
The bottom line
Opportunistic TLS protects against passive listeners but not against an active attacker who can interfere with the handshake. DANE and MTA-STS convert encryption from a best effort into a requirement, and DNSSEC makes the whole chain trustworthy. For organizations in regulated industries—or anyone who has ever had a payment diverted through intercepted email—this is one of the highest-value, lowest-cost hardening projects in the Exchange portfolio.
Planning mail flow hardening or a Microsoft 365 migration? Solution Savy can assess your current DNS and TLS posture and build a rollout plan that never puts delivery at risk.
