MTA-STS and TLS-RPT — the downgrade attack most senders never patch.

The problem MTA-STS solves

SMTP between mail servers is encrypted via STARTTLS — an opportunistic upgrade negotiated inside an otherwise cleartext session. A sending MTA opens a TCP connection to the receiver, issues EHLO, the receiver advertises 250-STARTTLS in its capability list, the sender issues STARTTLS, and the session transitions to TLS. The opportunistic part is load-bearing: if the receiver does not advertise STARTTLS, or if the TLS handshake fails for any reason, the sending MTA's default behavior is to deliver the message in cleartext rather than fail the delivery.

A network-positioned attacker exploits this by stripping the STARTTLS capability from the server's EHLO response. The sender, observing no TLS offer, proceeds in cleartext — and the attacker reads or modifies the full message body in transit. Mail-server-to-mail-server transport is, in the default configuration, meaningfully weaker than the HTTPS guarantees the same operator's web stack delivers, and operators tend to discover this only when a regulator asks them to prove otherwise.

MTA-STS is the out-of-band signal. A receiving domain publishes a policy declaring that senders must use TLS to a specific set of MX hosts with valid certificates, and sending MTAs that honor the protocol refuse to deliver mail if the policy cannot be satisfied. The protocol does not encrypt anything itself — TLS already does that. It removes the cleartext fallback.

The DNS-published policy record

MTA-STS is published in two pieces. The first is a TXT record at _mta-sts announcing that a policy exists and assigning it a version identifier:

_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20260601T120000;"

The id is an opaque string assigned by the operator. Its only semantic requirement is that it changes whenever the policy itself changes. Sending MTAs cache the policy file (see below) for the duration specified by max_age, and re-fetch the policy only when the cached id differs from the current DNS value. This indirection is the reason the protocol can publish a policy file once and have receivers learn about updates without polling the HTTPS endpoint on every delivery.

The second piece is the policy file itself, hosted at a fixed URL at the mta-sts subdomain over HTTPS with a valid certificate. The URL is non-negotiable: https://mta-sts.example.com/.well-known/mta-sts.txt. Operators who attempt to host the file at any other path, on any other subdomain, or over plain HTTP have, technically, not deployed MTA-STS.

The HTTPS-hosted policy file

The policy file is plaintext, served with Content-Type: text/plain, and contains a small number of required fields:

version: STSv1
mode: enforce
mx: mail.example.com
mx: *.mail.example.com
max_age: 604800

The mx: entries enumerate the hostnames that are permitted to receive mail for the domain. Wildcards match one DNS label. The max_age is the cache lifetime in seconds, with an upper bound of 31,557,600 (one year) and a sensible operational floor of 86,400 (one day). The shorter the max_age, the faster a sender re-fetches after a policy change; the longer the max_age, the smaller the failure window if the HTTPS endpoint becomes unreachable.

The operational reality of MTA-STS is that the operator now has to host an HTTPS file in addition to a DNS record. This sounds trivial and is, in practice, the single most common reason deployments break — the certificate on mta-sts.example.com expires, the static-site host changes its routing, the file is served with the wrong content type. Any of these causes the fetch to fail, at which point a sender falls back to the cached policy if one exists or to opportunistic STARTTLS otherwise — which is to say, no enforcement at all.

The three policy modes

The mode: field accepts three values, paralleling the DMARC escalation pattern.

none — withdrawal

mode: none declares that no MTA-STS policy is in effect. It exists as the mechanism by which an operator withdraws a previously published policy without an instantaneous DNS removal — sending MTAs honoring a cached enforcing policy will, on their next refresh, observe the new id, fetch the policy file, and learn that enforcement no longer applies. This is the safe rollback target for any operator who deployed enforcement prematurely.

testing — monitoring posture

mode: testing declares that the policy is published for diagnostic purposes only. Sending MTAs evaluate the policy and, on failure, deliver anyway — but if TLS-RPT is also configured (see below), they emit a report describing the failure. This is the correct initial deployment. It produces the diagnostic stream required to validate that real-world senders observe a satisfiable policy before the operator escalates to enforcement.

enforce — hard enforcement

mode: enforce instructs sending MTAs to refuse delivery when the policy cannot be satisfied — the MX hostname does not match the policy's mx: list, the certificate is invalid, the certificate's name does not match the policy MX, or TLS negotiation fails. A sender encountering any of these conditions does not deliver the message. The message either bounces with a transient SMTP error, retries to a different MX if the receiver advertises one, or eventually returns a permanent failure.

Skipping directly from none to enforce without observing a clean testing run is the same category of operator error as skipping straight to p=reject on DMARC: the deployment works correctly the moment everything is correctly configured, and produces silent mail loss in every other case. A staged progression of testing for two to four weeks, monitored against TLS-RPT, is the conservative path.

Policy ID and version semantics

The id in the TXT record and the policy file's contents are the two halves of an update protocol with no explicit push channel. A sender's caching logic is approximately: on delivery, query _mta-sts.example.com; if the returned id matches the cached policy, use the cached policy; if it does not, fetch the policy file from the HTTPS endpoint and update the cache with the new policy and the new id.

The implication: the id must change every time the policy file changes. Operators occasionally edit the policy file in place — adding a new MX, extending max_age — without updating the TXT record's id. Senders continue to use the stale cached policy until the cache expires on max_age, which can be a week. The new MX is unreachable from MTA-STS-honoring senders for that entire window.

A common convention is a timestamp string — 20260601T120000 — which is human-debuggable and self-incrementing on each deploy. The protocol places no requirements on the format; only that it changes when the policy changes.

TLS-RPT — the reporting stream

RFC 8460 defines the reporting protocol that surfaces failed TLS connections back to the receiving domain. It is published as a TXT record at _smtp._tls on the domain:

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

Sending MTAs that honor TLS-RPT aggregate their TLS-related delivery outcomes — successful sessions, STARTTLS-not-offered events, certificate validation failures, MTA-STS policy mismatches, DANE TLSA mismatches — and emit a daily JSON report to the address specified by rua. The reports are structured per RFC 8460 and contain, per (sending-side, policy-source) tuple: total session count, successful-session count, failure-session count, and a breakdown of failure types with hostname-level granularity.

The signal a receiving operator extracts from these reports:

• Successful TLS-RPT report inflow at all. The presence of any report indicates that at least one sender on the internet has observed and honored the published policy. Absence of reports for a week after publication usually means the TXT record is wrong.
• Sustained failure rate at a meaningful fraction of volume. A small number of policy failures from senders running their own MTAs with outdated TLS stacks is expected. Failure rates above one or two percent of inbound volume indicate the published policy is misconfigured — most often the policy file lists an MX hostname that does not match the certificate on that MX.
• Specific failure types. certificate-expired and certificate-host-mismatch are operational issues. starttls-not-supported from a high-volume sender means a peer MTA does not advertise STARTTLS at all and is the strongest argument for a phone call to that peer's operations team.

DANE — the DNSSEC-anchored alternative

RFC 7672 defines DANE for SMTP — DNS-based Authentication of Named Entities — which publishes TLS certificate fingerprints as TLSA records in DNS, anchored cryptographically by DNSSEC. A sending MTA that honors DANE queries the TLSA record for the MX, verifies that the certificate served during STARTTLS matches the published fingerprint, and refuses delivery on mismatch.

DANE and MTA-STS solve overlapping problems differently. DANE is conceptually cleaner — the policy lives at the DNS layer, no HTTPS file is required, the chain runs through DNSSEC instead of the web PKI — but it requires the receiving domain and its TLD to support DNSSEC end-to-end, which a meaningful fraction of commercial US infrastructure does not. MTA-STS is the protocol that emerged for operators whose registrars or TLDs do not deliver usable DNSSEC.

Adoption tracks accordingly. DANE is heavy in European government infrastructure, in .gov.uk, in jurisdictions with national-CA mandates, and in operator-run mail infrastructure with strong DNSSEC discipline. It is sparse in commercial US mail flow, especially among the SaaS-hosted mail platforms most B2B operators actually use. MTA-STS is the more broadly deployed protocol in practice, mostly because the prerequisites are softer.

The two protocols compose. A receiving domain may publish both, in which case senders prefer DANE when the DNSSEC chain validates and fall back to MTA-STS otherwise. TLS-RPT covers failures against either policy source, which is how an operator detects DANE failing for senders with broken validators while MTA-STS succeeds for everyone else.

The Microsoft 365 inbound connector bypass

Enterprise tenants on the dominant hosted-Exchange platform routinely configure inbound connectors — administrative routing rules that override default mail-flow policy for specific sender domains, partner organizations, or third-party security gateways. A permissive inbound connector accepting mail from an arbitrary IP range, configured with TLS marked as preferred rather than required, accepts cleartext delivery from the configured source regardless of any MTA-STS policy the receiving domain has published.

This is the failure mode that turns an apparently enforcing MTA-STS deployment into a deployment that protects nothing. The receiving domain publishes mode: enforce, the policy file is valid, the certificates check out, and a network-positioned attacker who can route mail through the configured inbound connector — by spoofing the partner sender, by compromising the security gateway, by the connector's source range overlapping cloud egress IPs — delivers cleartext mail that bypasses the policy entirely.

The remediation is to audit every inbound connector for permissive source ranges, require rather than prefer TLS, and remove connectors whose purpose no longer applies. The observation pattern is depressingly common: a tenant has accreted six to ten connectors over a five-year period, the rationale for half is no longer documented, and removing them requires signoff from teams that no longer remember what they configured.

Common deployment failures observed in production

• Hosting the policy file on the wrong subdomain. The operator publishes the file at the apex instead of mta-sts.example.com. The TXT record exists; the file does not exist at the URL senders query. The deployment is a no-op.
• Serving the policy file with the wrong content type. Static-site hosts default to serving .txt files as text/plain, but operators who route the file through a single-page-application server, a Markdown renderer, or a generic edge function often serve it as text/html or application/octet-stream. Strict senders reject the policy; lenient senders accept it; behavior diverges per sending MTA and is hard to reproduce without TLS-RPT.
• Certificate expiry on the mta-sts subdomain. Auto-renewal covers the apex and www but not mta-sts. The cert expires, the policy fetch fails, the cached policy expires, mail bounces. The operator notices when a high-volume peer reports inbound delivery failures.
• Updating the policy file without updating the id. A new MX is added; the TXT id is left stale. Senders enforce the old policy from cache until max_age elapses, and the new MX is unreachable from honoring senders for up to a week.
• Publishing mode: enforce without observing a testing run. Enforcement deploys on first publication, a subset of senders cannot validate the chain, mail bounces silently, the bounce stream goes uninvestigated until affected counterparties escalate by other means.
• TLS-RPT pointed at an unmonitored inbox. Policy enforced, reports flow, no one parses them. Misconfiguration affecting a fraction of inbound volume goes undetected until a security review asks for evidence of the enforcement.
• Leaving permissive inbound connectors in place on Microsoft 365 tenants. The MTA-STS deployment looks correct from the outside. The actual mail-flow path bypasses it. The downgrade exposure is unchanged from the pre-deployment state.

Pre-deployment checklist

• The mta-sts subdomain resolves and serves HTTPS with a valid, non-expiring certificate covered by the same auto-renewal as the apex
• The policy file is reachable at https://mta-sts.example.com/.well-known/mta-sts.txt and served with Content-Type: text/plain
• Every MX hostname listed in the policy resolves and serves a certificate whose name matches the listed hostname
• The TXT record at _mta-sts contains a current id that changes whenever the policy file changes
• A TLS-RPT TXT record is published at _smtp._tls with an rua destination routed to an automated parser, not a human inbox
• Initial deployment is mode: testing for a minimum of two weeks of observed report flow before escalation
• On Microsoft 365 tenants — every inbound connector audited for source range and TLS requirement, with permissive connectors removed or hardened
• A documented rollback path to mode: none, with the operator aware that rollback takes effect only on cache expiry at honoring senders, not immediately

Where MTA-STS fits in the broader infrastructure

MTA-STS protects inbound mail — it prevents an attacker from intercepting messages destined for the publishing domain. It does nothing for outbound mail. A sending operator who publishes MTA-STS on the corporate domain has not, by that act, improved the security posture of any outbound campaign; the protocol is the receiving counterparty's published policy, and a sender's role is to honor the policies of the domains it sends to, not the policy of its own domain.

For a cold-sending estate specifically, this is the protocol that most operators skip — and the skip is, on the merits, defensible. A pure-cold-sending domain has no meaningful inbound. The MX records exist primarily to receive bounce notifications and the occasional reply that a sequencing platform's reply detector routes through DNS. There is no transactional flow to protect, no employee-targeted phishing surface to harden, no regulator asking the operator to prove transport encryption. Provisioning MTA-STS on a sending-only domain produces operational burden without meaningfully reducing risk.

The picture inverts on the corporate domain. A B2B company's primary domain receives password resets, executive correspondence, vendor invoices, legal notices, and the long tail of transactional flow that is the actual target of a network-positioned attacker. MTA-STS at mode: enforce on the corporate domain — composed with TLS-RPT for diagnostic visibility, optionally with DANE for the receivers running DNSSEC, and with every inbound connector on the hosted-Exchange tenant audited for the bypass — is the configuration that closes the STARTTLS downgrade gap. The cold-sending domain inherits none of this and needs none of it.