What is the current adoption of TLS reporting with MTA-STS for domains?
Updated on 17 Oct 2026: We added separate TLS-RPT adoption data and corrected the guidance for measuring coverage and enforcing MTA-STS.
MTA-STS adoption is low by domain count, while support among large mailbox providers gives it value on busy mail routes. A comparable scan captured during the first week of January 2026 found that about 0.7% of the Top 1 million domains published an MTA-STS policy. That was 7,377 domains, up from 5,155 in 2025 and 2,975 in 2024. This is an MTA-STS publication figure, not a combined MTA-STS and TLS-RPT adoption rate.
That 0.7% number does not mean only 0.7% of email is affected. Domain-count adoption treats a parked domain and gmail.com as equal. Real mail traffic is not distributed that way. When an outbound provider honors MTA-STS and sends heavily to large policy-publishing destinations, MTA-STS can cover a much larger share of those delivery paths.
That dataset does not provide a global traffic-weighted measurement, so it does not establish that MTA-STS protects more than half of global email. Treat 0.7% as domain-count adoption, not a measured traffic-coverage percentage.
- Domain count: Still below 1% across the Top 1 million domains in the comparable early 2026 scan.
- Traffic impact: Often higher than the raw domain count on routes to large destinations, but no public global figure follows from this dataset.
- Main value: TLS-RPT detects reported TLS failures; an enforce-mode MTA-STS policy requires authenticated TLS from supporting senders.
- Main caveat: MTA-STS and TLS-RPT are related protocols, but they measure different things and can be deployed separately.
MTA-STS adoption in the January 2026 scan
MTA-STS policy publication more than doubled between the January 2024 and January 2026 snapshots, but it started from a small base. Comparable first-week January snapshots show 0.3% in 2024, 0.5% in 2025, and 0.7% in 2026. Adoption was below 1% in each sample; these snapshots do not measure the October 2026 deployment rate.
|
|
|
|---|---|---|
2024 | 2,975 | 0.3% |
2025 | 5,155 | 0.5% |
2026 | 7,377 | 0.7% |
Top 1 million MTA-STS policy publication trend
MTA-STS adoption by domain count
Top 1 million domains publishing an MTA-STS policy in comparable first-week January snapshots, not continuous measurements.
Adoption share
The number needs context. MTA-STS is a receiving-domain policy. In enforce mode, it tells supporting senders that mail for the domain must use authenticated TLS to the listed MX hosts. TLS-RPT is the reporting protocol for aggregate TLS success and failure statistics, including certificate validation and policy-fetch problems.
Provider support affects how much mail benefits. Google's setup guidance covers MTA-STS and TLS reporting records for Workspace administrators. Microsoft's current MTA-STS guidance confirms that Exchange Online applies outbound MTA-STS validation automatically. Receiving domains still need their own policy and DNS setup, so hosted mail does not automatically make every custom domain an MTA-STS publisher.
How many published policies work
Publication does not guarantee protection. In the same January 2026 Top 1 million scan, 80.8% of domains that published MTA-STS had a valid policy. Among policy-publishing domains, about 54% used enforce mode and about 45% used testing mode. A valid policy in testing mode does not enforce TLS, so policy validity and enforcement must be counted separately.
|
|
|
|---|---|---|
Valid policy | 80.8% | Publishing domains |
Enforce mode | About 54% | Publishing domains |
Testing mode | About 45% | Publishing domains |
Policy quality and mode among MTA-STS publishers
- Missing policy-host address records: 34% of invalid configurations had no working A or AAAA resolution for the policy host, directly or through a CNAME.
- HTTPS certificate problems: 25% of invalid configurations failed at the policy host certificate.
- TLS or certificate validation: 6% of invalid configurations failed validation checks.
- Expired certificates: 6% of invalid configurations used an expired certificate.
These figures measure MTA-STS policy quality, not combined MTA-STS and TLS-RPT adoption. A domain can publish either record without the other, and report delivery also depends on sender support. The January scan does not provide a separate TLS-RPT publication count, the overlap between the protocols, or global traffic-weighted coverage.
What separate TLS-RPT adoption data shows
A 2025 academic study measured TLS-RPT separately across .com, .net, .org and .se domains. Its September 2024 snapshot provides a historical baseline for reporting-record publication, using domains with MX records in each TLD as the denominator.
|
|
|
|---|---|---|
.com | 52,641 | 0.07% |
.org | 7,192 | 0.12% |
TLS-RPT publication among domains with MX records, September 2024
These are historical measurements, not October 2026 estimates. They cannot be compared directly with the January 2026 Top 1 million figures because both the sample and scan date differ. A combined adoption rate needs domains with both a valid MTA-STS policy and a TLS-RPT record in the same dated sample, with enforcing policies counted separately.
For your own domains, compare the providers sending TLS reports with your inbound mail logs to identify gaps in visibility. A published reporting record does not prove reports arrive, and TLS session counts do not equal message counts.
MTA-STS and TLS-RPT are different
MTA-STS and TLS-RPT are separate protocols. MTA-STS is the policy that receiving domains publish. TLS-RPT is the reporting protocol; its DNS record tells senders which mailbox or HTTPS endpoint should receive aggregate reports. TLS-RPT can report outcomes for MTA-STS, DANE, or a connection where no transport policy was found.
MTA-STS
- Purpose: In enforce mode, require supporting senders to use TLS and validate the MX certificate.
- Published at: A TXT record plus an HTTPS policy file on the mta-sts hostname.
- Modes: none, testing, or enforce.
- Risk: A bad enforce policy can cause supporting senders to defer and ultimately bounce mail.
TLS-RPT
- Purpose: Ask report-capable senders to send aggregate TLS delivery reports.
- Published at: A TXT record at _smtp._tls.example.com for the receiving domain example.com.
- Reports: JSON reports, often gzip-compressed, with aggregate success and failure counts.
- Risk: Low delivery risk, but reports are noisy without parsing and ownership.
You can publish TLS-RPT before you enforce MTA-STS. That is usually the safest first move because it gives you visibility before you create a policy that supporting senders use for enforcement. If you need the protocol basics, start with MTA-STS and then decide how you want to host the policy.
Testing mode is the right first rollout step
Testing mode lets supporting senders evaluate your policy without treating a mismatch as a delivery-blocking condition. TLS reports arrive only when you also publish a TLS-RPT record and the sender generates reports. Testing is the right staging point when you have multiple MX hosts, third-party filtering, or separate teams owning DNS and mail routing.
- Use testing: When the policy is new or when MX ownership is unclear.
- Use enforce: After reports and direct checks confirm that every MX host matches a policy entry and has a publicly trusted certificate valid for its hostname.
MTA-STS does not require DNSSEC; DANE uses DNSSEC-validated TLSA records. Both address server-to-server SMTP transport, not end-to-end message encryption. Before a sender has a cached MTA-STS policy, an attacker can suppress initial policy discovery, as RFC 8461's security considerations explain.
MTA-STS deployment steps: publish TLS-RPT, test the policy, review reports, and enforce TLS.
How to deploy without breaking mail
The practical path is conservative: publish reporting, publish a policy in testing mode, watch real reports, fix certificate or MX problems, then enforce. Validate every MX route before enforcement, including backup hosts, and use direct checks alongside reports to cover senders that do not report.
- Check MX: Confirm every advertised MX host is intentional and still receives mail.
- Check certificates: Confirm names, chains, expiry dates, and SNI behavior for each MX endpoint.
- Publish TLS-RPT: Create a working report destination and publish _smtp._tls; confirm reports arrive before enforcement changes delivery behavior.
- Publish MTA-STS: Host a testing policy, verify HTTPS retrieval, then publish _mta-sts to advertise it. Use a short max_age during rollout.
- Review failures: Fix policy fetch, certificate, and unsupported STARTTLS problems before enforcement.
- Enable enforcement: Move to enforce after reports and direct checks are clean across normal mail cycles.
TLS-RPT TXT recorddns
_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"
MTA-STS TXT recorddns
_mta-sts.example.com. 3600 IN TXT "v=STSv1; id=20260810000000Z"
Host the policy at https://mta-sts.example.com/.well-known/mta-sts.txt. It must return HTTP 200 directly, without redirects, with a publicly trusted certificate valid for mta-sts.example.com. Publish the policy before advertising it in DNS.
MTA-STS policy in testing modetext
version: STSv1 mode: testing mx: mail.example.com mx: backup.example.com max_age: 86400
After the testing period, change the HTTPS policy to enforce, then update the TXT id. Keep max_age short during initial enforcement checks and raise it once delivery is stable. An id change signals a refresh after DNS caches expire; it does not instantly replace every sender's cached policy.
MTA-STS policy after stable enforcementtext
version: STSv1 mode: enforce mx: mail.example.com mx: backup.example.com max_age: 1209600
If enforcement causes delivery failures, change the policy back to testing, publish a new TXT id, and investigate the affected MX hosts. Cached enforce policies can remain active until supporting senders retrieve the changed policy, so rollback is not guaranteed to be immediate. Keep the HTTPS policy endpoint reachable while senders refresh their caches.
What TLS reports actually tell you
TLS reports are aggregate diagnostics. They do not contain message content or individual sender and recipient email addresses. They identify the reporting organization, policy, affected MX host, successful session count, failed session count, and broad failure type. Reports normally cover a full UTC day and arrive after a delay, so they are not real-time delivery alerts. Failure categories can overlap for one connection, so summing every failure detail can overcount affected sessions. The SMTP TLS Reporting specification defines the report format and timing.
Common TLS-RPT failure reasonstext
starttls-not-supported certificate-host-mismatch certificate-expired validation-failure sts-policy-fetch-error
The most useful failures point to something you own: an expired MX certificate, a hostname mismatch, a missing policy file, or a stale MX entry. One-off sender behavior and transient network conditions need context. Parse the reports because recurrence and scope matter more than a single event.
TLS-RPT triage signals
Prioritize failures by recurrence and scope because RFC 8460 defines no universal failure-rate threshold.
Isolated
Monitor
One event with no repeat from the same source or MX host.
Repeated
Investigate
The same sender, MX host, or failure reason recurs across reports.
Widespread
Pause rollout
Several reporting senders show the same failure or counts rise after a change.
No reports
Verify record
No data means reporting coverage is unknown, not that TLS is perfect.
Use TLS reports to diagnose transport failures
MTA-STS and TLS-RPT help verify secure transport and catch misconfiguration. They do not replace SPF, DKIM, DMARC, list hygiene, complaint control, or reputation work. They also do not fix user-supplied SMTP credentials or weak application authentication.
- Good signal: Repeated certificate mismatch for one of your MX hosts.
- Weak signal: One isolated failure from a sender that never appears again.
- Missing signal: No reports from a sender that does not generate TLS-RPT.
Manage MTA-STS and TLS-RPT with Suped
MTA-STS and TLS-RPT address transport security alongside DMARC authentication. Keep DNS and mail-routing ownership clear so a policy change reaches the team responsible for the affected MX host.
Suped's product combines DMARC monitoring with MTA-STS hosting and TLS-RPT report collection. Use the hosted policy to stage testing and enforcement, then review successful and failed TLS sessions by reporting provider and policy domain.
- Hosted policy: Suped can manage the MTA-STS policy without requiring a custom web server.
- Policy staging: Choose testing or enforce and keep the policy's MX entries consistent with your mail routing.
- Report review: Compare successful and failed sessions, then inspect raw JSON for the reporter's failure details.
- Multi-domain scale: Agencies, MSPs, and security teams can manage many domains from one dashboard.
Hosted MTA-STS/TLS-RPT configuration dialog showing policy mode, MX hosts, CNAME records, TLS reporting, and verification
The hosted approach is useful when different teams own DNS and mail routing. A self-hosted setup adds an HTTPS endpoint and policy file that need ongoing maintenance. Suped's Hosted MTA-STS workflow lets you configure the MX hosts and policy mode, publish the DNS records shown in the dialog, and review incoming reports under TLS-RPT.
Review authentication alongside transport security. Use the domain health checker to inspect published domain records, and validate the MTA-STS policy and MX certificates separately before enforcement.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
DMARC, SPF and DKIM address sender authentication, while MTA-STS addresses TLS transport. Authentication problems need their own fixes and do not prevent an otherwise valid MTA-STS deployment. Resolve stale MX records and TLS certificate failures before enforcement.
Which receiving domains should prioritize deployment
Prioritize domains that receive sensitive or business-critical mail. MTA-STS is a receiving-domain control: in enforce mode, it tells supporting senders to use the MX hosts allowed by your policy and validate TLS properly.
|
|
|
|---|---|---|
Bank or insurer | High | Deploy, test, enforce |
Government domain | High | Deploy early |
SaaS platform | High | Stage carefully |
Small mailbox | Medium | Start reporting |
No inbound mail | Low |
Practical priority by domain type
The January 2026 Top 1 million scan is a dated adoption baseline. For your receiving domain, check which sending providers honor MTA-STS and generate TLS-RPT. Publishing a receiving policy does not enforce TLS for mail your domain sends; outbound enforcement depends on your sending provider.
Roll out reporting before enforcement
Deploy TLS-RPT first, deploy MTA-STS in testing mode second, and enforce after reports and direct checks confirm that the policy matches the real MX setup. Keep monitoring after enforcement and after any MX or certificate change.
