MTA-STS, TLS-RPT, and DANE: Layering Mail Transport Security

One problem, two trust roots

The problem both mechanisms address is the same downgrade scenario: SMTP TLS between servers is opportunistic, so an attacker in the path can strip STARTTLS and force plaintext, or present a fraudulent certificate that an opportunistic sender never verifies. The question is where a sender gets a trustworthy statement that your domain expects verified TLS.

DANE anchors that statement in DNSSEC: a TLSA record under the MX hostname, valid only when the DNSSEC chain validates. MTA-STS anchors it in the web PKI: a policy file fetched over HTTPS from mta-sts.your-domain, protected by a normal browser-grade certificate. Same promise, different roots of trust — and different sender populations. Some large senders validate DANE, others fetch MTA-STS policies, and the overlap is imperfect enough that publishing only one leaves real senders unprotected on the path to you.

The mechanisms also fail differently, which is the strongest argument for layering. DANE inherits every DNSSEC failure mode; a bogus zone silences it entirely. MTA-STS inherits web infrastructure failure modes: an expired certificate on the policy host or a broken redirect quietly disables enforcement for policy-fetching senders. It is entirely possible to break one while the other keeps protecting — if both exist.

Getting the details right

MTA-STS has two coupled parts: the DNS TXT record _mta-sts.your-domain announcing the policy version, and the policy file at https://mta-sts.your-domain/.well-known/mta-sts.txt listing your MX hosts and the mode. The subtle contract sits in the id field of the TXT record: senders cache policies aggressively and refetch only when the id changes, so every policy edit must change the id, or the world keeps enforcing your old policy for as long as max_age allows. The MX list in the policy must cover every host in your MX set — a forgotten backup MX in mode: enforce means failover mail gets refused by policy-honoring senders precisely when your primary is down.

Validate the whole arrangement — TXT record, policy reachability, MX coverage, mode — with the MTA-STS Checker/Generator, and cross-check the live transport picture with the SMTP TLS Handshake / Mail Domain Delivery Readiness. If you also run DANE, the DANE Validator covers that half. The mechanisms coexist, but a DANE validation failure is not overridden by a successful MTA-STS check; a sender applies the supported trust rules without using one green layer to erase another layer’s failure.

TLS-RPT: the feedback channel everyone forgets

Enforcement without visibility is a trap: transport-security failures happen on other people's infrastructure, in sending queues you cannot see, and the default symptom is mail that quietly does not arrive. TLS-RPT fixes the visibility half. A single TXT record — _smtp._tls.your-domain with a rua address — asks senders to mail you daily JSON summaries of their TLS outcomes toward your domain: how many sessions succeeded, and what failed for which reason, from certificate mismatches to policy fetch errors to STARTTLS being unavailable.

The reports are modest in volume and enormously useful in an incident: they distinguish a misconfigured sender from a broken policy on your side from an active downgrade in some network path — distinctions that are nearly impossible to make from your own logs, because the failures happen before the connection reaches you. Validate the single record and its rua URI syntax with the TLS-RPT Checker/Generator, then separately verify that the destination accepts and processes reports; a valid URI alone proves neither acceptance nor delivery. Treat a sudden spike in failure reports as the early-warning signal it is. The combination — DANE and MTA-STS for enforcement, TLS-RPT for eyes — is the current best practice for any domain whose mail matters.