EnglishMTA-STS, DANE and TLS-RPT: What Twenty Domains Secure in Mail Transport
Management Summary
Email travels between several servers, and protecting those connections helps prevent interception during delivery. MTA-STS and DANE provide security rules that compatible sending servers can enforce; TLS-RPT supplies reports about transport protection. These tools strengthen server-to-server delivery rather than keeping a message confidential throughout its entire journey. A historical sample of twenty domains shows uneven adoption and illustrates why dependable protection needs to cover the actual receiving infrastructure.
Contents
SMTP transfers email between mail servers; STARTTLS adds encryption to that connection. Without an enforced security policy, the connection often remains opportunistic: if the EHLO response does not advertise STARTTLS, delivery may continue without encryption. An attacker on the network path could remove that advertisement. Whether plaintext is then permitted depends on the sending server’s configuration and other policies.
MX records name the servers that receive mail for a domain. MTA-STS and DANE provide binding checks for supporting senders. TLS-RPT supplies reports about successful and failed TLS sessions. None replaces end-to-end encryption: the protection covers transport between servers.
Three mechanisms with different jobs
MTA-STS: A TXT record at _mta-sts.example.com announces a policy. The file at https://mta-sts.example.com/.well-known/mta-sts.txt contains permitted MX names, a mode and a lifetime. In enforce mode, a supporting sender must not hand a message to an MX with missing TLS, a disallowed name or an unsuitable certificate. In testing, an MTA-STS failure alone does not block delivery; other security requirements still apply.
DANE: TLSA records under the mail server’s name bind the TLS endpoint to a certificate, key or trust anchor. SMTP DANE requires trustworthy MX and TLSA information through DNSSEC, including a valid trust chain and correct error handling. TLSA requires a separate DNS lookup; the TTL sets how long a cached DNS answer may be reused, and signature expiry adds another time limit.
TLS-RPT: A TXT record at _smtp._tls.example.com identifies report destinations. Supporting senders report aggregate successes and failures. Reports complement local logs and active checks. Missing reports establish neither trouble-free operation nor coverage of every sender.
A historical sample: 20 domains, 38 host checks
The saved raw data from 5 September 2026 cover 20 domains and 38 recorded host checks. During the 25 October revision, the totals were recalculated from that file. The providers were not measured again. Those 38 checks also do not demonstrate complete coverage of every published MX server and IP address.
| Observation on 5 September | Domains |
|---|---|
| MTA-STS TXT present | 11 |
| Readable policy | 9: 6 enforce, 3 testing |
| TLS-RPT published | 11 |
| TLSA at one or more checked MX hosts | 7 |
In this sample, the eleven domains publishing TLS-RPT were the same eleven publishing MTA-STS TXT. That is not a general rule. An AD flag in a TLSA response also does not establish a fully validated DNSSEC chain for the recipient domain. The historical measurements therefore cannot certify complete DANE protection.
What the results do not establish
An MTA-STS identifier containing 2018 does not prove eight years of testing. The id field is an arbitrary change identifier, not a required timestamp. The mode must be read from the retrieved policy.
Two domains had a TXT record but no readable policy. Without a previously cached, valid policy, that does not create an enforceable MTA-STS rule. An unexpired cached policy remains applicable. Calling the record “worse than no record” was therefore too broad. This small selection also cannot establish organisational reasons for choosing MTA-STS or DANE.
The historical data recorded an enforce policy for wp.pl covering *.wp.pl. At the checked host mx5.wp.pl, the tool reported failed certificate validation despite a matching hostname. The saved data lack the complete certificate chain; “self-signed” is therefore unproven. The result also says nothing about the current configuration. A supporting sender would have to skip an actually non-compliant MX and, where possible, try another MX or retry delivery later.
For gmx.net, web.de and t-online.de, an SMTP rejection ended the check before STARTTLS could be tested. Only the saved t-online.de response explicitly mentions reputation; a missing PTR record is not established for all three cases. “Connection rejected” and “STARTTLS unavailable” are different findings.
Separate checks for DNS, policy and certificate
The following Linux examples use placeholders. A real check requires the domain and MX hostname from the actual configuration. These commands send no message.
dig +short MX example.com
dig +short TXT _mta-sts.example.com
dig +short TXT _smtp._tls.example.com
dig +dnssec TLSA _25._tcp.mx.example.com
curl --fail --show-error --silent --max-time 15 --include \
https://mta-sts.example.com/.well-known/mta-sts.txt
timeout 20s openssl s_client -starttls smtp \
-connect mx.example.com:25 -servername mx.example.com \
-verify_hostname mx.example.com -verify_return_error </dev/nullcurl retrieves the body with GET; -I would request headers only. A usable policy also requires the correct HTTP status, content and HTTPS certificate. openssl explicitly checks the hostname and stops on certificate errors. -servername alone only sets SNI. This connection tests public certificate trust against the local trust store, not complete DANE validation.
dig +dnssec requests DNSSEC data but does not validate the entire chain itself. An AD flag is meaningful only with a trusted resolver and a protected path to that resolver. A TLSA hash comparison alone is also insufficient: certificate usage, selector, matching type and DNSSEC status belong in the assessment.
The Mail Transport Security Checker provides an initial inventory. The implementation inspected during this revision checks at most three MX hosts by default and only the first resolved IP address for each. Its TLSA comparison does not fully cover all supported record combinations, and the AD flag comes from an unprotected DNS query. The result therefore replaces neither complete DANE validation nor checks of every delivery path.
Questions and answers
Does MTA-STS protect the first contact?
Suppressing the TXT record can prevent initial discovery. A cached, unexpired enforce policy provides protection during later retrieval failures. The maximum max_age is 31,557,600 seconds. Longer cache lifetimes extend protection but also complicate rapid withdrawal of a faulty rule.
What belongs in a change from testing to enforce?
All MX names, reachable addresses, certificates and fallback paths need checking first. TLS-RPT complements these checks but does not guarantee complete visibility. The HTTPS policy is then changed and the TXT identifier updated. A new identifier helps discovery; senders should also refresh policies regularly before expiry. Withdrawal requires mode: none with a new identifier. The file and announcement remain available until older policies have expired.
How should a DANE key rollover work?
With DANE-EE 3 1 1, the SHA-256 digest covers the public key. Certificate renewal with the same key can therefore retain the TLSA record. For a new key with unchanged TLSA parameters, RFC 7671 section 8.1 describes publishing old and new bindings together, waiting at least two TTL periods, activating and checking the new key, then removing the old binding. Other models, including DANE-TA, need a corresponding rollover plan.
Is a signed recipient domain sufficient?
No. The MX provider’s TLSA data must also validate securely. DNSSEC distinguishes authenticated absence, insecure delegations, and invalid or indeterminate responses. A DNSSEC validation failure must not simply become permission to send plaintext. One signed zone fragment does not establish a working DANE delivery path.
Related articles
