Your mail is encrypted — until an attacker says otherwise.

/ TL;DR

/ 01

Why STARTTLS isn't enough

SMTP was designed in 1982 with no encryption at all. TLS came later, bolted on through a command called STARTTLS that upgrades a plaintext connection to an encrypted one when both mail servers support it. Most mail today does travel over STARTTLS — but the way it's designed leaves a gap that's easy to miss and easy to exploit.

The gap is that STARTTLS is opportunistic. If the encrypted connection can't be established, the sending server doesn't refuse to deliver — it falls back to sending in plaintext. That fallback is the vulnerability. In a downgrade attack, sometimes called STRIPTLS, an attacker positioned on the network path removes the STARTTLS offer from the SMTP handshake as it passes. Both servers, seeing no TLS on offer, deliver the message in cleartext — and neither one registers that anything went wrong. The message crosses the internet readable by anyone watching, exactly as if encryption had never existed.

There's a second weakness alongside the first. Plain STARTTLS doesn't require the other server's certificate to be valid — the specification sets no requirements, so a sending server will accept an expired certificate, a self-signed one, or one belonging to an impostor. That makes a man-in-the-middle attack straightforward: intercept the connection, present any certificate at all, and the sender proceeds. Opportunistic encryption protects you from passive eavesdropping on a well-behaved network, but not from an attacker who actively interferes. Closing both holes — the plaintext fallback and the unchecked certificate — is what the three technologies in this guide do.

/ 02

Identity vs transport

Before the mechanics, it's worth placing these protocols correctly, because they're often confused with email authentication and they solve a genuinely different problem. SPF, DKIM, and DMARC answer the question who sent this? — they let a receiver confirm a message really came from your domain and reject spoofed mail claiming to be you. They are about identity, and they say nothing about encryption.

MTA-STS, TLS-RPT, and DANE answer a different question: did this arrive securely? They make sure the message travels between servers inside an encrypted, certificate-verified connection that can't be silently downgraded. They are about transport, and they say nothing about who sent the mail. The two concerns are independent — a domain can have immaculate DMARC and still hand its message content to anyone on the wire, because DMARC has no bearing on whether the connection carrying it was encrypted.

So these aren't competing with your authentication setup or replacing any of it; they're the missing layer beneath it. A complete posture has both: authentication proving who sent the message, and transport security protecting what was sent while it moves. If you've already worked through SPF, DKIM, and DMARC — our authentication guide covers those — transport encryption is the natural next piece, and the one most senders haven't done.

/ 03

MTA-STS

MTA-STS — Mail Transfer Agent Strict Transport Security — lets your domain declare that senders must use TLS with a valid certificate to deliver to you, and must not fall back to plaintext. It's the SMTP counterpart to HSTS on the web. It rests on two published pieces working together:

The DNS record signals that a policy exists and carries an id that changes whenever you update the policy, so senders know to re-fetch it. The policy file, served over HTTPS from the mta-sts subdomain, lists the mode, the MX hostnames allowed to receive your mail, and a max_age caching duration. Its trust comes from the web PKI: because the file is fetched over HTTPS, the ordinary certificate on that subdomain authenticates the policy, which is why MTA-STS needs no DNSSEC and is simple to deploy.

The mode is the safety valve, with three settings. None means no active policy. Testing asks senders to attempt TLS and report any failure, but still deliver the message if TLS can't be established — so you gather data without risking mail. Enforce tells senders to refuse delivery if TLS fails, the certificate is untrusted, or the receiving host isn't in your MX list. One important limit: MTA-STS only affects senders that support it. A server that doesn't understand it ignores your policy and keeps using opportunistic STARTTLS — but the major providers, Gmail, Microsoft, and Yahoo, all support and check it, so it covers the bulk of your mail.

/ 04

TLS-RPT

MTA-STS on its own has a blind spot: it enforces TLS, but it doesn't tell you when a connection to your domain fails. A sender that can't establish TLS in enforce mode simply doesn't deliver, and without a feedback channel you'd never know a legitimate correspondent was being blocked by a misconfiguration on your side. TLS-RPT is that feedback channel, and it's why the two are always deployed together.

TLS Reporting is a single DNS record naming where reports should be sent:

With it published, participating senders deliver you daily aggregate reports summarizing their TLS connections to your domain — how many succeeded, how many failed, and why. Those reports are what make a safe rollout possible: during testing mode you read them to find and fix problems, such as a misconfigured MX or an expired certificate, before any of those problems can block mail. Then, once the reports show clean connections, you can move to enforce with confidence rather than hope. Deploying MTA-STS without TLS-RPT is deploying it with your eyes closed.

/ 05

DANE

DANE — DNS-based Authentication of Named Entities — reaches the same goal as MTA-STS, mandatory verified TLS, but anchors its trust somewhere else entirely: in DNSSEC. Instead of an HTTPS-hosted policy, you publish a TLSA record in DNS that pins the expected certificate for your mail server, and DNSSEC's cryptographic signatures guarantee that record hasn't been tampered with.

That different foundation gives DANE two advantages. Because the TLSA record binds the certificate directly, DANE has no trust-on-first-use gap — there's no initial unprotected fetch the way there is with an MTA-STS policy a sender hasn't seen before. And because trust comes from your own DNSSEC signatures rather than a public authority, you can pin any certificate you like, including a self-signed one. For a sender that supports DANE, a downgrade or a swapped certificate fails immediately.

The cost of that strength is the prerequisite: DANE requires DNSSEC across your entire DNS chain, and DNSSEC adoption remains limited, which raises the operational bar. It's most common in environments where DNSSEC is already the norm — notably European government and academic networks, where standards frameworks in countries like the Netherlands and Germany actively require it. If you already run DNSSEC, DANE is exceptionally strong; if you don't, standing it up solely for email is a larger project than MTA-STS.

/ 06

MTA-STS vs DANE

The two are easy to frame as rivals, but that's the wrong lens — they're complementary tools with different prerequisites, and the right choice depends on your DNS setup. The core difference is the root of trust. MTA-STS trusts the web PKI: public certificate authorities and HTTPS, no DNSSEC required, easy to deploy, with the tradeoff of a small trust-on-first-use window. DANE trusts DNSSEC: stronger, no trust-on-first-use, able to pin any certificate, at the cost of requiring DNSSEC everywhere.

For reach, MTA-STS wins today, because it works without the whole DNS chain supporting DNSSEC and because the largest mailbox providers check it. DANE has deeper security guarantees but a narrower deployed base, concentrated where DNSSEC is already established. Neither is universally supported by every sender, which is an argument for coverage rather than for picking one.

The key point is that they aren't mutually exclusive — you can publish both on the same domain, and they coexist cleanly. A sender that supports DANE will use your TLSA records; a sender that only supports MTA-STS will use your HTTPS policy; a sender that supports neither falls back to opportunistic STARTTLS. Running both is defense in depth. The pragmatic 2026 sequence most organizations follow is to deploy MTA-STS with TLS-RPT first for broad compatibility and quick protection, then layer DANE on top wherever DNSSEC is already in place.

/ 07

Deploying it safely

The appeal of MTA-STS is that the whole deployment is DNS records and a static file — there's no software to install on your mail servers and nothing changes about how your users send mail. That makes it one of the highest-value, lowest-effort controls in email security, provided you roll it out in the right order.

The sequence is deliberate. First, publish the policy file over HTTPS on your mta-sts subdomain with mode: testing, listing your real MX hosts. Second, publish the _mta-sts DNS record. Third, publish the _smtp._tls TLS-RPT record so reports start flowing. Then wait, and read those reports — testing mode is deliberately harmless, so let it run until the reports consistently show clean TLS connections and you've resolved anything they surface. Only then change the policy to mode: enforce, at which point downgrade attacks against your inbound mail stop working.

Two things to watch afterward. The policy depends on a valid certificate on the mta-sts subdomain, so its expiry is now part of your mail's reliability — monitor it, or use a managed setup that renews it. And keep the id in your DNS record in sync whenever you edit the policy, so senders re-fetch it. Before and after you switch to enforce, validate the whole setup from the outside with our MTA-STS validator, which checks the DNS record, fetches the policy, and confirms the pieces agree; the domain health scanner shows it beside your authentication records. Getting to enforce and keeping it there — certificate, policy, and reports all healthy as your infrastructure changes — is the standing operation we run.

/ 08 — FAQ