MTA-STS — SMTP MTA Strict Transport Security

The problem MTA-STS solves

SMTP was originally specified in 1982 with no encryption. TLS was added later via the STARTTLS extension (RFC 3207, 2002), but with a fundamental limitation: STARTTLS is opportunistic. The sending and receiving servers negotiate whether to use TLS during the SMTP handshake, and if either side claims TLS is unavailable, the message flows in plaintext. Two attack vectors exploit this:

• STARTTLS stripping (downgrade attack). An attacker positioned in the network path between sender and receiver intercepts the receiver's response to the sender's EHLO and removes the 250-STARTTLS line. The sender now believes the receiver doesn't support TLS and sends in plaintext. The attacker captures or modifies the message in transit. Both endpoints have no signal that TLS was even possible.
• MX redirection via DNS spoofing. An attacker manipulates the DNS response for the sender's MX lookup, replacing the legitimate MX target with an attacker-controlled mail server. The attacker presents a valid TLS certificate for their own domain, the sending server happily encrypts, the attacker copies/modifies the message, and forwards it to the real MX. STARTTLS doesn't catch this because the attacker's TLS connection is itself valid.

MTA-STS addresses both. By publishing an out-of-band policy fetched over HTTPS, the recipient domain tells the world: "Mail to me must use TLS, with a valid certificate matching one of these MX hostnames." A sending MTA that supports MTA-STS will refuse to deliver in plaintext when the policy mode is enforce — even if STARTTLS appears stripped, even if the MX response was spoofed, the cached policy provides the authoritative list of expected MX targets and the requirement to verify TLS certificates against them.

How MTA-STS works — the dual DNS+HTTPS architecture

MTA-STS is unusual among email authentication standards because it requires two coordinated components: a DNS TXT record signaling policy presence, and an HTTPS-served policy file that contains the actual rules. Both must be operational; either one missing or broken means the policy is effectively absent from the perspective of sending MTAs.

The two components serve different roles. The DNS TXT record is small, fast to fetch, and contains a version id that changes whenever the policy changes. The HTTPS policy file is the authoritative document containing the actual list of MX hosts, mode, and cache duration. Sending MTAs that have already fetched a policy don't re-fetch the HTTPS file on every message — they only re-fetch when the DNS TXT record's id value differs from what they last saw, or when their cache has expired (after max_age seconds).

The DNS TXT record

The HTTPS policy file

The three modes — none, testing, enforce

MTA-STS defines three policy modes, each with different operational semantics. The standard rollout sequence is testing → enforce, with none reserved as the explicit way to retire a previously-published policy. Skipping testing mode is the most common cause of post-deployment delivery loss.

Adoption in 2026 — the data

Despite being defined in 2018 and supported by Gmail, Microsoft, and Yahoo for outbound mail, MTA-STS adoption remains in single digits across the broader internet. The growth curve is upward but slow. Public-sector mandates (UK NCSC, US CISA) have pushed government domains well above the average, while regulated industries like banking lag despite the obvious need.

The interpretation: organizations that adopt MTA-STS mostly get it right (high deployment-correctness rate), but most organizations don't adopt it at all. The barrier isn't technical complexity — it's that the protection MTA-STS offers is invisible to most operators until they investigate transport-layer attacks specifically. SPF/DKIM/DMARC have visible payoff (DMARC reports, deliverability impact). MTA-STS protects against attacks most teams have never seen evidence of, even though those attacks are happening.

MTA-STS vs DANE — when to use which

DANE (DNS-based Authentication of Named Entities, RFC 7672) is the alternative transport-security mechanism, predating MTA-STS but adopted less widely because of its DNSSEC dependency. The two are not mutually exclusive — domains with DNSSEC can publish both. The choice is determined primarily by whether you have DNSSEC.

Safe deployment — the testing → enforce migration

The standard rollout sequence is non-negotiable: any domain that goes straight to enforce mode is risking delivery loss. The sequence below is the production-grade pattern based on RFC 8461 guidance and operational experience from large mail operators.

Hosted MTA-STS vs self-hosted policy

The HTTPS policy host is the operationally annoying piece of MTA-STS deployment. It needs a webserver, a TLS certificate, monitoring, and ongoing maintenance — all to serve a small static text file that rarely changes. Two deployment patterns exist:

Common deployment failures

The 2026 URIports survey of the Top 1M domains found that ~20% of published MTA-STS deployments have at least one operational issue. The seven most common failure modes, ordered by frequency in the survey:

MTA-STS in Cloud Server for Email's managed infrastructure

For clients on managed PowerMTA + MailWizz infrastructure, MTA-STS is configured during the day 1-3 onboarding sequence as part of the broader transport-security setup (alongside TLS-RPT and DANE for DNSSEC-enabled clients). The patterns we use across most accounts:

• Hosted policy via the dedicated subdomain pattern. Each client sending domain gets mta-sts.<client-subdomain> served from our managed HTTPS infrastructure. This avoids requiring the client to set up their own webserver for what is essentially a static file. The client publishes a CNAME at mta-sts.example.com pointing to our endpoint, and we handle TLS, uptime, and policy updates.
• Default rollout: testing → enforce in 30 days. All new client domains start in testing mode at day 14 (after the rest of the authentication stack is verified working), with TLS-RPT collection going to our reporting endpoint. We aggregate failures, identify any MX hosts with cert issues, fix them coordinated with the client, and advance to enforce at day 30-45.
• max_age: 604800 (7 days) as the default, balancing cache effectiveness against rapid policy update propagation. Some compliance-sensitive clients prefer 86400 (1 day) for faster policy changes; we configure per-client based on requirements.
• Microsoft CNAME-on-MX awareness. Our managed infrastructure uses direct A/AAAA records on MX hostnames (no CNAMEs), so Microsoft Exchange Online's stricter interpretation isn't an issue for our outbound delivery. For clients running mixed inbound infrastructure (e.g., corporate mail at Microsoft 365, marketing at our infrastructure), we coordinate the policy mx: lines to cover both reachability paths.
• Coordinated DANE deployment for DNSSEC clients. Clients with DNSSEC-signed zones get DANE TLSA records published alongside MTA-STS, providing the strongest possible transport-security posture. Both protocols coexist correctly when configured by the same team.
• TLS-RPT monitoring with weekly review. Failures aggregated across all client domains are reviewed weekly. Most reports show zero or single-digit failures per domain per week. Any sustained failure pattern triggers investigation — usually traces to a specific receiver's intermediate gateway with deprecated TLS configuration.

Auditing your MTA-STS — practical workflow

Related concepts

• TLS-RPT — SMTP TLS Reporting (RFC 8460); the companion reporting protocol that tells you which sending MTAs successfully or unsuccessfully delivered under your MTA-STS policy. Mandatory for safe MTA-STS rollout.
• DANE/TLSA — DNS-based Authentication of Named Entities (RFC 7672); the alternative transport-security mechanism using DNSSEC. Stronger guarantees, higher deployment barrier. (Coming soon)
• STARTTLS — the SMTP TLS upgrade extension (RFC 3207); the opportunistic encryption layer MTA-STS hardens. (Coming soon)
• DNSSEC — DNS Security Extensions; required for DANE, optional but beneficial alongside MTA-STS. (Coming soon)
• SPF, DKIM, DMARC — the message-authentication layer; complementary to MTA-STS's transport-authentication layer. Both are needed for full email security posture.

Frequently asked questions

What does MTA-STS solve that STARTTLS doesn't?

STARTTLS is opportunistic encryption — sending and receiving servers negotiate TLS during the SMTP handshake, but if the negotiation fails or is stripped by an attacker, mail still flows in plaintext. An attacker positioned in the network path can delete the "250 STARTTLS" response from the receiver's EHLO answer; the sender then assumes TLS isn't supported and sends in cleartext. This downgrade attack is invisible to both endpoints. MTA-STS publishes an out-of-band policy fetched over HTTPS that says "TLS is required to deliver to my domain" — a sending MTA that complies will refuse to deliver in plaintext when the policy mode is enforce, even if STARTTLS is stripped. The policy is cached based on max_age, so the attack window is bounded only by DNS-spoofing the very first fetch.

What are the three MTA-STS modes?

none — the domain explicitly disclaims any MTA-STS policy, used to remove a previously-published policy. testing — sending MTAs attempt TLS verification but deliver the message regardless of result; failures are reported via TLS-RPT. enforce — sending MTAs reject delivery if the receiver fails TLS verification (no valid certificate, hostname mismatch, MX not in policy, or TLS not offered). The standard rollout is to publish in testing mode for 2-4 weeks while monitoring TLS-RPT for unexpected failures, then switch to enforce only when the failure rate is near zero. Skipping the testing phase is the most common cause of email delivery loss after MTA-STS deployment.

How does MTA-STS deployment actually work?

Two coordinated components must exist before sending MTAs will respect the policy. (1) A DNS TXT record at _mta-sts.example.com containing v=STSv1; id=<changing-string> — the id changes whenever the policy changes, signaling MTAs to re-fetch. (2) An HTTPS-served policy file at mta-sts.example.com/.well-known/mta-sts.txt — must respond with HTTP 200 OK (no redirects), valid TLS certificate matching the mta-sts subdomain, declaring version: STSv1, mode: testing|enforce|none, mx: lines listing authorized MX hosts (wildcards allowed for left-most label only), and max_age: seconds (recommended ≥86400). The DNS record needs an A or AAAA record at mta-sts.example.com pointing to the HTTPS server.

Should I use MTA-STS or DANE?

MTA-STS if you don't have DNSSEC; both if you do. DANE (RFC 7672) provides stronger cryptographic guarantees by binding TLS certificates directly to DNS records signed with DNSSEC, eliminating the trust-on-first-use weakness of MTA-STS. But DNSSEC adoption sits below 30% of domains because of operational complexity, key management, and registrar support gaps. MTA-STS works without DNSSEC, has wider adoption among consumer providers (Gmail, Microsoft, Yahoo all support it), and includes a built-in testing mode that DANE lacks. The two are not mutually exclusive — domains with DNSSEC can publish both DANE TLSA records and MTA-STS policy. For most production deployments without DNSSEC, MTA-STS is the practical choice.

What is the trust-on-first-use weakness in MTA-STS?

The first time a sending MTA fetches your MTA-STS policy, it has no prior cache to compare against — if an attacker has DNS-spoofed the response and serves a fake policy with mode: none or no policy at all, the sending MTA accepts that as authoritative. The TOFU window is bounded by max_age (recommended ≥86400 seconds = 1 day). After the first successful fetch, the cached policy protects against DNS-spoofing for max_age seconds. DANE doesn't have this weakness because it relies on DNSSEC for authenticated DNS responses from the start. The practical impact: MTA-STS protects against ongoing downgrade attacks but not against an adversary who controls the network at the exact moment of first policy fetch. For most threat models, the TOFU window is acceptable.

What is TLS-RPT and why is it required for MTA-STS?

TLS-RPT (RFC 8460) is the reporting mechanism that tells you which sending MTAs successfully or unsuccessfully delivered to your domain under MTA-STS or DANE policies. Daily JSON reports list policy types, MX hosts contacted, total session counts, total failure counts, and per-failure-type breakdowns (TLS negotiation failure, certificate validation failure, policy mismatch, etc.). Without TLS-RPT, you have zero visibility into whether legitimate sending MTAs are failing your policy. The standard pattern: deploy MTA-STS in testing mode + TLS-RPT on day 1, monitor reports for 2-4 weeks, fix any unexpected failures, then advance to enforce mode. Publish a TXT record at _smtp._tls.example.com with v=TLSRPTv1; rua=mailto:tls-reports@example.com to receive reports.

Why does my Microsoft 365 MTA-STS deployment fail when receivers use CNAME on MX?

Microsoft Exchange Online enforces a stricter interpretation of RFC 8461 than most MTAs: when MTA-STS is active, Microsoft does NOT resolve CNAMEs on MX records. If your receiving domain uses a CNAME to alias its MX to another hostname (common pattern for hosted mail providers and email gateways), Microsoft's outbound delivery to your domain will fail MTA-STS checks and the email won't be sent. The workaround is to list the final target hostname in your MTA-STS policy mx: lines (the resolved A/AAAA destination), even though that doesn't strictly follow the RFC. Most other senders (Gmail, Yahoo) follow CNAMEs, so the issue is Microsoft-specific. Audit your MX records and policy mx: lines together to confirm the targets are reachable when CNAMEs are not resolved.

What are the most common MTA-STS deployment failures?

Based on URIports' 2026 survey of the Top 1M domains: missing A/AAAA records at mta-sts.example.com (34% of broken deployments) — the policy host hostname must resolve over HTTPS; missing or expired TLS certificate at mta-sts.example.com (high single-digit %); HTTP 3xx redirects from the policy URL (RFC 8461 forbids); policy file served with wrong Content-Type or MIME headers; mismatched version: directive (must be STSv1); MX patterns in policy that don't match actual MX records; max_age outside recommended range. About 1 in 5 published MTA-STS deployments has at least one of these issues. Validation tools (URIports, MxToolbox, CaptainDNS) check all components in a single test.