MTA-STS and TLS-RPT: Enforce Email Encryption in Transit

Why SPF, DKIM, and DMARC Do Not Protect the Transport Path

Email authentication and transport encryption solve two entirely different problems. SPF, DKIM, and DMARC are authentication methods: they prove that a message really comes from the domain in the sender address and thus protect against spoofing and phishing. What they do not do is secure the channel between the mail servers. A perfectly signed, DMARC-compliant email can still travel across the network in plaintext if the sending server does not enforce a TLS connection.

The distinction matters because both layers are attacked independently. Authentication fends off forged senders; transport encryption prevents eavesdropping and tampering along the way. Securing only one side leaves the other open. That is why MTA-STS is not a replacement for DMARC but its logical complement. For how to evaluate the authentication side, see analyzing DMARC reports and spotting spoofing; this article is about the transport path.

The last column makes the difference clear: only MTA-STS turns the opportunistic, always-optional TLS connection into a binding requirement. TLS-RPT, in turn, does not protect on its own but delivers the visibility without which enforcement would remain blind.

STARTTLS, Opportunistic Encryption, and the Downgrade Attack

SMTP was designed in the 1980s without any encryption. The STARTTLS extension, retrofitted later, lets two mail servers switch to TLS within the existing plaintext connection. The catch: STARTTLS is opportunistic. If the other side offers no TLS or the handshake fails, delivery quietly falls back to plaintext — the main thing being that the mail arrives. That permissiveness is precisely the weakness.

The attack is not theoretical: the MTA-STS specification names STARTTLS downgrade and man-in-the-middle explicitly as its motivation (RFC 8461). Transport security is also a moving target — alongside today's encryption, the migration to quantum-safe methods is on the horizon, which the post monitoring post-quantum TLS with ML-KEM addresses. MTA-STS forms the bracket that keeps an existing TLS capability from being bypassed in the first place.

How MTA-STS Works: DNS Record, Policy File, and Certificate

MTA-STS consists of three building blocks that must fit together. If one is missing or misconfigured, the sending server ignores the policy and falls back to opportunistic behavior. The three blocks are a DNS record as the signal, a policy file served over HTTPS, and a valid certificate on the MX host.

_mta-sts.your-domain.com.  IN TXT  "v=STSv1; id=2026070701"

# v   = version identifier, currently only STSv1 is valid
# id  = arbitrary alphanumeric identifier of the current policy;
#       must be updated whenever the policy file changes so that
#       sending servers reload the policy

version: STSv1
mode: enforce
mx: mail.your-domain.com
mx: *.your-domain.com
max_age: 604800

A sending server fetches the policy on first contact, checks the MX certificate against the mx: patterns, and caches the policy for the duration of max_age. This trust-on-first-use model (TOFU) means only the very first fetch is unprotected; after that the cached requirement applies. Per the specification, max_age may be up to 31,557,600 seconds — one year (RFC 8461); in practice you pick short values during the test phase and extend them when moving to enforce. Which certificate authorities may issue certificates for the domain at all can additionally be constrained via CAA records for DNS hardening.

The Three Policy Modes: none, testing, and enforce

The mode value in the policy file decides how a sending server reacts to a failed TLS check. This single parameter separates pure observation from real enforcement — and it is the lever for a low-risk rollout.

In testing mode the sending server behaves as if the policy did not yet exist — it delivers even on a failed TLS check but reports the failed attempt via TLS-RPT. Only enforce makes the TLS requirement binding: if the MX certificate does not match or no TLS is established, the message is not delivered but returned to the sender with an error (RFC 8461).

TLS-RPT: Making Failed Connections Visible

MTA-STS on its own works in the dark: without feedback you do not know whether sending servers apply your policy correctly at all, or at which MX hosts TLS fails. TLS-RPT (RFC 8460) closes that gap. An additional DNS record invites sending servers to send daily aggregated reports about the success and failure of TLS negotiation to an address you specify.

_smtp._tls.your-domain.com.  IN TXT  "v=TLSRPTv1; rua=mailto:tls-reports@your-domain.com"

# v    = version identifier (TLSRPTv1)
# rua  = destination for the aggregate reports; mailto: or https: allowed

The reports arrive as machine-readable JSON, usually once per day per reporting provider (RFC 8460). Each line names the policy type (sts, tlsa, or no-policy-found), the number of successful and failed connections, and the specific failure type. These failure types are the real diagnostic tool:

• starttls-not-supported — the MX host offers no STARTTLS at all, or the command was suppressed.
• certificate-expired — the MX host's certificate has expired.
• certificate-host-mismatch — the certificate name does not match the MX address.
• validation-failure — the certificate chain could not be verified up to a trusted root.
• sts-policy-fetch-error — the policy file was unreachable when fetched.

Especially during the test phase these messages are indispensable: they show which legitimate peers still have problems before enforce turns them into rejected mail. Anyone who also keeps an eye on certificates — for instance via Certificate Transparency log monitoring — spots expiring or mismatched certificates before they show up as errors in the TLS-RPT reports.

The Safe Path from testing to enforce

The biggest concern during rollout: will legitimate mail suddenly be rejected? A fair one — jumping to enforce too early can block delivery to peers with outdated TLS. That is why the transition happens in controlled stages, backed by the TLS-RPT data. The UK NCSC recommends observing in testing mode for at least a month before switching to enforce (UK NCSC).

1. Prepare the records: create the _mta-sts and _smtp._tls DNS TXT records and serve the policy file with mode: testing under the mta-sts. subdomain over HTTPS. For the test phase the NCSC suggests a max_age of 86,400 seconds — that is 24 hours (UK NCSC).
2. Observe: evaluate the TLS-RPT reports for at least a month and check whether and where TLS connections fail (UK NCSC).
3. Fix the sources of error: renew expired certificates, align the policy's MX patterns with the actual MX records, and add missing STARTTLS on your own hosts.
4. Switch to enforce: once no unexpected errors have appeared for several weeks, set mode: enforce and raise max_age — the NCSC names at least 1,209,600 seconds, i.e. two weeks, for production (UK NCSC).
5. Monitor continuously: new MX hosts, a provider change, or an expired certificate can alter the picture at any time. Observation does not end with the switch.

Adoption and Reality: Below One Percent — and Often Broken

Despite clear benefits, adoption remains low. The ACM IMC 2025 study measured over 87 million domains across four TLDs over 31 months. As of September 2024, only 0.07% of .com domains with an MX record, 0.09% of .net, and 0.13% of .org domains published an MTA-STS policy (ACM IMC 2025). Even among the most popular domains the picture is thin: for the top 10,000 domains the rate is 1.2%, and for the lower ranks only 0.4% (ACM IMC 2025).

Even more telling than sheer adoption is the quality of implementation. Of the broken setups, the study found 3.2% cause actual delivery failures toward MTA-STS-compliant senders (ACM IMC 2025). A large share of individual errors originates at the policy host: 35% of self-managed and 3.9% of third-party policy servers already fail the TLS handshake (ACM IMC 2025). And on the sending side, only 19.6% of domains check MTA-STS at all when delivering to an MTA-STS-capable domain (ACM IMC 2025) — so enforcement depends on both ends.

Common Pitfalls with MTA-STS and TLS-RPT

The research shows that most problems stem not from the concept but from operational practice. Four failure patterns appear especially often — and all of them can be caught early through continuous monitoring.

MTA-STS, DANE, and BSI TR-03108: Classification and Compliance

MTA-STS is not the only route to enforced transport encryption. The alternative is DANE (DNS-based Authentication of Named Entities), which binds the certificate key to the MX host via DNSSEC-signed TLSA records. Both methods pursue the same goal but anchor trust differently — DANE in DNSSEC, MTA-STS in publicly trusted certificates plus HTTPS.

The difference also has a compliance dimension. The technical guideline BSI TR-03108 makes DANE mandatory for secure email transport and, since version 2.0, supports MTA-STS only optionally as an alternative (BSI TR-03108). The reason: DANE identifies the peer more robustly because it does not rely on trust-on-first-use. In practice, however, DANE is tied to DNSSEC and implemented globally by only about 4% of domains (ACM IMC 2025) — MTA-STS is easier to introduce without DNSSEC. The two methods are not mutually exclusive; many operators publish both in parallel.

Continuously Monitoring the MTA-STS Policy and Certificates

MTA-STS is not a one-off project. The very elements that carry it can drift unnoticed: the DNS record can disappear, the policy file can return a 404 after a server move, the HTTPS certificate of the mta-sts. subdomain can expire, or a new MX host can fall out of the mx: patterns. Each of these deviations makes enforcement either ineffective or — under enforce — a delivery block. The high error rate of 29.6% (ACM IMC 2025) is ultimately an operational problem, not a conceptual flaw.

• DNS records: check _mta-sts and _smtp._tls for existence and correct content — if the record disappears, the policy is dead.
• Policy reachability: the file at https://mta-sts.your-domain.com/.well-known/mta-sts.txt must stay retrievable and contain valid version/mode/mx/max_age.
• Certificates: both the policy host and the MX hosts need valid certificates with sufficient remaining lifetime and matching names.
• MX consistency: the policy's mx: patterns must match the actual MX records.
• TLS-RPT evaluation: review the daily reports for new failure types and rising error rates.

This is exactly where XICTRAQ's DNS and domain monitoring comes in: it watches MTA-STS policy reachability, the relevant DNS records, and the associated certificates, and reports deviations as soon as they occur. Combined with alerting across all relevant channels, you learn about a vanished record or an expiring certificate before mail bounces. In addition, blacklist monitoring of the mail server IPs covers the deliverability side, while the security scan and the detection of defacement attacks round out the picture of the domain's overall security. That way the hard-won enforce stage stays effective, instead of quietly breaking after the next server move.

Frequently Asked Questions about MTA-STS and TLS-RPT