MTA-STS vs DANE: which transport security to use

30 March 2026 · 15 min read

If you are trying to make inbound mail to your domain arrive over verified, encrypted connections, you will quickly run into two standards that do the same job in completely different ways: MTA-STS (RFC 8461) and DANE for SMTP (RFC 7672). Both close the same hole, the fact that plain SMTP over STARTTLS can be silently downgraded to plaintext or intercepted by a man in the middle. But they anchor their trust in two different places, and that single difference drives almost every practical decision about which one to deploy, how risky it is to get wrong, and whether you can even use it at all on your DNS provider.

This article is not a generic "what is TLS" explainer. It is a direct comparison of the two transport-security mechanisms: their trust models, their failure behaviour, the operational burden of each, how they interact when a domain publishes both, and a concrete decision guide for picking one. If you want to inspect what a specific domain is publishing first, the MTA-STS checker and the DANE checker will show you both sides before you read another word.

The shared problem both standards solve

Server-to-server mail is delivered over SMTP. When your mail server has a message for someone@example.com, it looks up the MX records for example.com, connects to the named host on TCP port 25, and starts an SMTP conversation. Encryption on that connection is opportunistic, provided by the STARTTLS command, which the receiving server advertises to offer an upgrade from plaintext to TLS.

That default has two well-known weaknesses, and both MTA-STS and DANE exist to fix exactly these:

• STARTTLS is strippable. An active attacker on the path can delete the STARTTLS advertisement from the SMTP banner. The sending server, seeing no offer of encryption, carries on in plaintext. Nothing in plain SMTP says encryption was expected, so there is nothing to fall back from. This is a downgrade attack.
• MX discovery is unauthenticated. Without DNSSEC, the MX lookup itself can be tampered with, pointing your sending server at a host the attacker controls. And historically SMTP accepted any certificate, including expired, self-signed or name-mismatched ones, so even a negotiated TLS session could be terminated by an impostor.

Both standards answer the same question, "how does a sending server know it must encrypt, and to which legitimate host", but they answer it with different roots of trust. That is the whole story. See the STARTTLS glossary entry for the underlying mechanism both standards harden.

MTA-STS in one paragraph

MTA-STS works through a policy that is anchored in the web PKI, the same public certificate authorities that secure HTTPS. A domain publishes a small TXT record at _mta-sts.<domain> that says "a policy exists, version id is X". The actual policy lives in a file served over HTTPS from a fixed URL, https://mta-sts.<domain>/.well-known/mta-sts.txt. A sending server fetches that file over an authenticated HTTPS connection, reads which MX hostnames are legitimate and whether the policy is in enforce or testing mode, caches it for up to max_age seconds, and then refuses to deliver to any MX that does not match the policy and present a valid, CA-signed certificate.

_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20260601000000Z"

version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

The trust comes from two things working together: the policy file is fetched over HTTPS with a certificate that must validate for mta-sts.example.com, and the MX hosts must present certificates that validate against their published names. DNS is used only as an untrusted hint that tells the sender to go and fetch the real policy. For the standard in full, see RFC 8461 explained.

DANE in one paragraph

DANE works through fingerprints anchored in DNSSEC. Instead of trusting a public CA, the domain publishes a TLSA record in DNS that pins the exact certificate (or public key) the MX host will present. The sending server looks up the TLSA record, and because the DNS response is signed and validated through the DNSSEC chain of trust, it can trust that the fingerprint genuinely came from the domain owner. It then connects to the MX, demands STARTTLS, and checks that the server's certificate matches the pinned fingerprint. No public CA is involved at all; the certificate can be self-signed, because trust flows from DNSSEC, not from a CA.

A TLSA record for an MX host on port 25 looks like this:

_25._tcp.mx1.example.com.  IN  TLSA  3 1 1 (
    a1b2c3d4e5f6... )

The three numbers in front of the fingerprint are the heart of DANE and decide what is actually being pinned:

• Usage (first field). 3 means "pin this exact end-entity certificate or key, and ignore CA validation entirely" (DANE-EE). 2 means "pin a trust anchor", a CA you nominate (DANE-TA). For SMTP, usage 3 is overwhelmingly the common and recommended choice.
• Selector (second field). 0 pins the full certificate; 1 pins just the SubjectPublicKeyInfo, the public key. 1 is preferred because you can renew a certificate without changing the record, as long as you keep the same key.
• Matching type (third field). 0 is the full value, 1 is a SHA-256 hash, 2 is a SHA-512 hash. 1 (SHA-256) is the norm.

So 3 1 1 means "pin the SHA-256 hash of the server's public key, and do not involve any CA". That combination is what most DANE-for-SMTP deployments use. See the TLSA glossary entry and the DANE glossary entry for more.

The fundamental difference: where trust is anchored

Everything else follows from this one fact.

• MTA-STS anchors trust in the web PKI and HTTPS. It needs no DNSSEC. It needs a public CA certificate for your policy host and your MX hosts, and a web server to serve a static file. Tampering with DNS cannot forge a policy, because the policy itself is fetched over authenticated HTTPS.
• DANE anchors trust in DNSSEC. It needs no public CA, your MX certificate can be self-signed, because the fingerprint that authorises it is delivered through a cryptographically signed DNS chain. But it is completely dependent on DNSSEC being correctly deployed and validated end to end. Without DNSSEC, a TLSA record is just an unsigned, forgeable string and provides no security at all.

This is the crux of the comparison. MTA-STS moves the security-critical material out of DNS and into HTTPS precisely because DNS, by default, is not trustworthy. DANE takes the opposite bet: make DNS itself trustworthy with DNSSEC, then you can put security-critical fingerprints directly in it. You can check whether a domain even has the prerequisite signed DNS with the DNSSEC checker; for DANE this is not optional, it is the entire foundation. See the DNSSEC glossary entry for what that chain of trust involves.

How they fail, and why that matters most

The trust model is interesting in theory, but the failure behaviour is what determines real-world risk. The two standards fail in genuinely different ways, and this is the single most important thing to understand before deploying either.

MTA-STS failure is cache-protected and soft at the edges

A sender that has cached your MTA-STS policy keeps enforcing it for the whole max_age, even if your DNS record or policy file later becomes unreachable. That caching is a feature: an attacker who suppresses your _mta-sts record cannot strip protection from a sender that already holds a valid cached enforce policy.

But MTA-STS also has a deliberately soft edge. If a sender has no cached policy and the policy fetch fails, for example the HTTPS host is down or the certificate is invalid, the sender falls back to ordinary opportunistic STARTTLS rather than blocking mail. A failed fetch on a first contact does not, by itself, queue your mail. This makes MTA-STS forgiving to deploy: the worst case for a transient policy-host outage on a cold cache is that you temporarily get the same security as a domain with no policy at all.

The testing mode reinforces this. MTA-STS has a testing mode where the policy is evaluated exactly as in enforce, but failures never block mail; instead they are reported via TLSRPT. You can run testing for weeks, watch the reports, and fix mismatches with zero delivery impact before flipping to enforce. The progression none to testing to enforce is the safe on-ramp the standard was designed around.

DANE failure is hard and unforgiving

DANE has no equivalent soft fallback. When a domain publishes a valid TLSA record, a DANE-aware sender must establish TLS to a host whose certificate matches the pinned fingerprint, or it must not deliver. There is no testing mode in the standard, and there is no "fetch failed, fall back to plaintext" path: if the TLSA record validates but the certificate does not match it, the connection is rejected and the mail queues.

This makes DANE genuinely stricter, which is the point, but it also means a mistake stops mail. The classic DANE outage is a key rotation that forgets the TLSA record. You renew your MX certificate, the public key changes (or you used selector 0 and the whole certificate changed), and now every DANE-validating sender on the internet pins a fingerprint that no longer matches what your server presents. Mail from those senders queues and eventually bounces until you republish a correct TLSA record and wait for DNS to propagate.

The correct DANE rotation is a careful dance: publish the new TLSA record alongside the old one, wait for the old record's TTL to expire everywhere, then deploy the new certificate, then remove the old record. Get the ordering wrong and you have an outage. MTA-STS has nothing this sharp, because its certificates are validated against public CAs, not against a fingerprint you have to keep in lockstep with DNS.

Deployment burden compared

The two standards demand different things from you, and the gap is large.

MTA-STS asks for:

• A web-facing host mta-sts.<domain> serving one static file over HTTPS with a valid public certificate.
• A _mta-sts TXT record carrying a version id.
• Discipline to bump that id every time you edit the policy file, or senders keep their stale cached copy.
• Optionally, a TLSRPT record so you receive failure reports during testing.

Crucially, MTA-STS needs no DNSSEC, which is why it was created in the first place: large mail operators wanted transport security they could deploy without the operational weight and provider support that DNSSEC requires. You can stand it all up on any DNS host plus any HTTPS host.

DANE asks for:

• DNSSEC fully and correctly deployed on your domain, signed and validated through the parent zone. This is the hard prerequisite and the main reason DANE adoption is concentrated among operators who already run DNSSEC.
• A TLSA record per MX host (and per relevant port), generated from your actual certificate or key.
• Tight coupling between certificate lifecycle and DNS: every certificate rotation requires a coordinated TLSA update, in the right order, respecting TTLs.

If your DNS provider does not support DNSSEC, or your registrar does not let you publish DS records to the parent zone, DANE is simply off the table until that changes. MTA-STS has no such gate. This is often the deciding factor before any of the trust-model philosophy even enters the conversation.

Reporting and visibility

Both standards pair with TLSRPT (RFC 8460), the TLS Reporting standard, which is independent of which mechanism you deploy. You publish a _smtp._tls.<domain> TXT record naming a destination, and supporting senders email you daily JSON summaries of how their TLS sessions to you went, including MTA-STS policy failures and DANE TLSA validation failures.

_smtp._tls.example.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

TLSRPT is the only systematic way to see DANE failures before they cause sustained loss, because DANE itself has no testing mode. For MTA-STS, TLSRPT is what makes testing mode useful. Either way, turning it on is non-negotiable for a serious deployment. Check a domain's reporting record with the TLS-RPT checker, and see the TLS-RPT glossary entry for the record format.

Running both at once

MTA-STS and DANE are not mutually exclusive, and large, security-conscious operators frequently publish both. When a domain offers both:

• A DANE-aware sender with DNSSEC validation will typically prefer DANE, because TLSA validation is cryptographically stronger and does not depend on the CA ecosystem. Postfix, for example, will use DANE when a validated TLSA record is present.
• A sender that does not do DNSSEC or DANE (which includes some very large providers historically) will honour MTA-STS instead.

Publishing both therefore widens coverage: DANE protects connections from DNSSEC-validating senders, MTA-STS protects connections from the large web-PKI-oriented providers that do not validate DNSSEC. The two audiences only partly overlap. The cost is doubled operational surface, both the policy host and id discipline of MTA-STS and the DNSSEC and TLSA-rotation discipline of DANE.

If you run both, your MX certificate and names have to satisfy both at once: a certificate that validates against a public CA (for MTA-STS) and whose key or certificate matches your TLSA fingerprint (for DANE). In practice a normal CA-issued certificate with a 3 1 1 TLSA record pinning its key satisfies both cleanly.

A decision guide

Strip away the theory and the choice usually resolves on a few concrete questions.

1. Do you already run DNSSEC, correctly, end to end?
2. - No, and you cannot easily add it. Deploy MTA-STS. DANE is not available to you, and there is no point agonising over its stronger trust model when you cannot meet its prerequisite. This is the most common situation.
3. - Yes. Both are open to you; continue down the list.

1. What is your appetite for hard-fail risk?
2. - If a TLSA rotation mistake taking out mail from DNSSEC-validating senders is unacceptable and you lack tooling to automate certificate-and-TLSA coordination, lean towards MTA-STS first, which has a non-blocking testing mode and a soft fetch fallback. You can add DANE later once your rotation process is automated and proven.
3. - If you have mature DNSSEC operations and automated certificate handling, DANE gives you the strongest available transport guarantee, with no dependence on the CA ecosystem.

1. Who are you exchanging mail with?
2. - Microsoft 365, Google Workspace and similar large providers publish and honour MTA-STS. If most of your mail flows to and from those, MTA-STS gives you the broadest practical coverage today.
3. - If you exchange a lot of mail with DNSSEC-heavy, DANE-supporting operators (common in some European and government sectors), DANE meaningfully protects those flows.

1. Do you want maximum protection and can absorb both?
2. - Deploy both, in this order: MTA-STS first (lower risk, testing mode lets you validate safely), then DANE once DNSSEC and TLSA rotation are solid. Turn on TLSRPT from day one so you can see failures from either.

For most domains that are not already running DNSSEC, the honest answer is: start with MTA-STS, because it is deployable, forgiving, and covers the providers you most exchange mail with. Treat DANE as the upgrade you add once DNSSEC is in place and your certificate lifecycle is automated.

Where this sits in the wider authentication stack

It is worth being precise about the boundary, because MTA-STS and DANE are often lumped in with SPF, DKIM and DMARC and they solve a different problem entirely.

• SPF, DKIM and DMARC are about authenticity. They let a receiver decide whether a message genuinely came from your domain and what to do if it did not. They are your defence against spoofing and phishing.
• MTA-STS and DANE are about transport security. They protect the connection over which inbound mail reaches you, against passive snooping and active downgrade or interception. They say nothing about whether a message is authentic.

A domain at DMARC p=reject with neither MTA-STS nor DANE still accepts inbound mail over strippable plaintext. A domain with enforce MTA-STS but no DMARC is still trivially spoofable. A complete posture wants both halves. The full set of expected records, authentication and transport, is laid out on the requirements page.

One more boundary: both MTA-STS and DANE protect inbound mail to your domain (you publish; other people's servers honour it when sending to you). They do nothing for your outbound mail unless the recipient domains publish their own policies or TLSA records and your sending MTA honours them.

The practical takeaway

The comparison comes down to one design decision and its consequences. MTA-STS trusts the web PKI and uses DNS only as an untrusted pointer to an HTTPS-hosted policy; it needs no DNSSEC, has a safe non-blocking testing mode, fails softly on a cold cache, and is honoured by the largest mail providers, which makes it the pragmatic default for most domains. DANE trusts DNSSEC and pins certificate fingerprints directly in signed DNS; it is cryptographically stronger and CA-independent, but it is hard-fail, has no testing mode, demands DNSSEC as a prerequisite, and turns every certificate rotation into a coordinated DNS operation that can cause an outage if mishandled.

If you run DNSSEC and have automated certificate operations, both together give the widest and strongest protection: deploy MTA-STS first for safety and coverage, then add DANE. If you do not run DNSSEC, deploy MTA-STS and move on; it gives you real, low-risk transport security today.

When you are ready, inspect any domain's published policies with the MTA-STS checker and the DANE checker, confirm the DNSSEC foundation with the DNSSEC checker, and turn on reporting via the TLS-RPT checker. If you would rather not run the policy host, the certificate-and-id discipline, or the DNSSEC-and-TLSA coordination yourself, hosted MTA-STS sets it up and takes the domain from testing to enforce without an outage, alongside hosted DMARC, SPF, DKIM and BIMI, with emailed monitoring and change alerts watching the records over time. For the deeper dives, see RFC 8461 explained and the step-by-step MTA-STS setup guide.