{"id":15599,"date":"2026-10-29T08:05:00","date_gmt":"2026-10-29T07:05:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=15599"},"modified":"2026-10-26T13:13:14","modified_gmt":"2026-10-26T12:13:14","slug":"mta-sts-dane-and-tls-rpt-what-twenty-domains-secure-in-mail-transport","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/it-networks\/tutorials-en-it-networks\/mta-sts-dane-and-tls-rpt-what-twenty-domains-secure-in-mail-transport\/","title":{"rendered":"MTA-STS, DANE and TLS-RPT: What Twenty Domains Secure in Mail Transport"},"content":{"rendered":"

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.<\/p>\n

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.<\/p>\n

\"Mail
20 domains \u00b7 38 recorded host checks \u00b7 5 September 2026. No new provider measurement \u00b7 no complete MX\/IP or DNSSEC validation.<\/figcaption><\/figure>\n

Three mechanisms with different jobs<\/h2>\n

MTA-STS:<\/strong> A TXT record at _mta-sts.example.com<\/code> announces a policy. The file at https:\/\/mta-sts.example.com\/.well-known\/mta-sts.txt<\/code> contains permitted MX names, a mode and a lifetime. In enforce<\/code> mode, a supporting sender must not hand a message to an MX with missing TLS, a disallowed name or an unsuitable certificate. In testing<\/code>, an MTA-STS failure alone does not block delivery; other security requirements still apply.<\/p>\n

DANE:<\/strong> 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.<\/p>\n

TLS-RPT:<\/strong> A TXT record at _smtp._tls.example.com<\/code> 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.<\/p>\n

A historical sample: 20 domains, 38 host checks<\/h2>\n

The saved raw data from 5 September 2026<\/strong> 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.<\/p>\n
Observation on 5 September<\/th>Domains<\/th><\/tr><\/thead>
MTA-STS TXT present<\/td>11<\/td><\/tr>
Readable policy<\/td>9: 6 enforce, 3 testing<\/td><\/tr>
TLS-RPT published<\/td>11<\/td><\/tr>
TLSA at one or more checked MX hosts<\/td>7<\/td><\/tr><\/tbody><\/table>\n

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.<\/p>\n

What the results do not establish<\/h2>\n

An MTA-STS identifier containing 2018<\/code> does not prove eight years of testing. The id<\/code> field is an arbitrary change identifier, not a required timestamp. The mode must be read from the retrieved policy.<\/p>\n

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 \u201cworse than no record\u201d was therefore too broad. This small selection also cannot establish organisational reasons for choosing MTA-STS or DANE.<\/p>\n

The historical data recorded an enforce policy for wp.pl<\/code> covering *.wp.pl<\/code>. At the checked host mx5.wp.pl<\/code>, the tool reported failed certificate validation despite a matching hostname. The saved data lack the complete certificate chain; \u201cself-signed\u201d 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.<\/p>\n

For gmx.net<\/code>, web.de<\/code> and t-online.de<\/code>, 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. \u201cConnection rejected\u201d and \u201cSTARTTLS unavailable\u201d are different findings.<\/p>\n

Separate checks for DNS, policy and certificate<\/h2>\n

The following Linux examples use placeholders. A real check requires the domain and MX hostname from the actual configuration. These commands send no message.<\/p>\n

Shell<\/span>