MTA-STS and TLS-RPT: requiring TLS on inbound mail and knowing when it fails

SMTP encryption through STARTTLS is opportunistic: a sending server attempts TLS and, if negotiation fails or the other side does not offer it, sends in the clear. An attacker on the path can therefore strip the STARTTLS advertisement or redirect traffic to another server with forged MX answers. MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) lets the receiving domain declare that its MX hosts require TLS with a valid certificate; TLS-RPT (SMTP TLS Reporting, RFC 8460) lets it receive reports when senders fail to comply.

Both mechanisms concern the domain as a receiver: they protect mail addressed to you, not mail you send.

How MTA-STS works#

The mechanism rests on two pieces:

1. A TXT record under _mta-sts.<domain> signalling that a policy exists and carrying an id= identifier;
2. A policy file served over HTTPS at https://mta-sts.<domain>/.well-known/mta-sts.txt, with a certificate valid for the name mta-sts.<domain>.

A sending server supporting MTA-STS queries the TXT, downloads the policy, caches it for max_age, and then only delivers to MX hosts whose name matches the policy's mx: list and whose TLS certificate is valid for that name. On each later delivery it compares the id= in DNS with the cached one to decide whether to refetch the policy. Going through HTTPS makes the policy independent of DNS integrity, unlike DANE, which requires DNSSEC.

The records#

_mta-sts.example.com.   IN TXT  "v=STSv1; id=20261001T090000"
_smtp._tls.example.com. IN TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

And the policy file:

version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
mx: *.backup-mx.example.net
max_age: 604800

• mode: is testing (failures are only reported), enforce (failures block delivery, the message stays queued at the sender) or none (policy withdrawal);
• mx: lists the allowed host names, with a wildcard permitted only on the leftmost label;
• max_age: is the cache lifetime in seconds, typically between one and four weeks.

For TLS-RPT, the rua= tag accepts a mailto: address or an https: URL. Reports are JSON files sent once a day by supporting senders, listing successful sessions and failures by cause: invalid certificate, STARTTLS not offered, MX name not allowed, policy unreachable.

Deploying MTA-STS and TLS-RPT#

1. Start with TLS-RPT alone: publish _smtp._tls and watch for a few weeks which senders already fail to establish TLS to your MX hosts.
2. Check every MX: STARTTLS advertised, certificate issued by a recognised authority, covering exactly the MX host name (not just the domain), full chain, TLS 1.2 or 1.3.
3. Put the policy file online in mode: testing at mta-sts.<domain> with a valid HTTPS certificate, then publish the _mta-sts TXT.
4. Read the TLS-RPT reports: as long as they show failures caused by your own setup, stay in testing.
5. Switch to mode: enforce and raise max_age.
6. On every MX or certificate change, update the file then the id= in the TXT, in that order.

Common mistakes#

• MX certificate not matching the name: the MX is mx1.example.com but the certificate covers mail.example.com. In enforce, mail stays stuck at the sender.
• id= never updated after changing the policy: senders keep the old version cached until it expires.
• Incomplete mx: list: a forgotten backup MX becomes unusable for senders applying the policy.
• mta-sts.<domain> host unreachable or HTTP redirect to another name: the policy is not fetched and, if it was cached, it expires with no replacement.
• File served with the wrong MIME type: it must be text/plain.
• max_age too short in enforce: if the HTTPS site goes down, protection vanishes quickly; too long, and an MX change becomes awkward.
• Confusing MTA-STS with DANE: both can coexist; DANE (RFC 7672) relies on TLSA records signed with DNSSEC, MTA-STS on HTTPS.

What SenderRadar shows#

For each domain, SenderRadar indicates whether an MTA-STS record exists, the policy's mode and cache lifetime, consistency between the mx: list and the MX records actually published, the presence of a TLS-RPT record and its destination, and the state of the certificates presented by the MX hosts. SenderRadar relies on its own analysis base to flag inconsistencies between these elements.

References#

• RFC 8461 – SMTP MTA Strict Transport Security (MTA-STS)
• RFC 8460 – SMTP TLS Reporting
• RFC 7672 – SMTP Security via Opportunistic DANE TLS
• RFC 3207 – SMTP Service Extension for Secure SMTP over TLS