What is the current adoption of TLS reporting with MTA-STS for domains?
Updated on 9 Aug 2026: We updated this guide with policy validity data and clearer guidance on measuring coverage and enforcing MTA-STS safely.
The short answer: TLS reporting with MTA-STS is still low by domain count, but it has real value because adoption is concentrated among large mailbox providers and security-conscious organizations. 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.
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: Detect TLS failures, resist downgrade paths for supporting senders, and verify authenticated transport on reporting paths.
- Main caveat: MTA-STS and TLS-RPT are related protocols, but they measure different things and can be deployed separately.
What adoption looks like now
MTA-STS policy publication has more than doubled in two years, 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 remains below 1%, but the measured direction has been upward each year.
|
|
|
|---|---|---|
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, shown by comparable yearly snapshots.
Adoption share
The number needs context. MTA-STS is a receiving-domain policy. It tells supporting senders that mail for the domain must use authenticated TLS to the listed MX hosts. TLS-RPT is the reporting layer that sends aggregate reports when TLS negotiation, certificate validation, policy fetches, or policy checks fail.
Provider support matters more than raw domain count. Google's setup guidance covers MTA-STS and TLS reporting records for Workspace administrators. Microsoft's current MTA-STS guidance explains inbound and outbound support in Exchange Online. When large providers honor the protocol as senders and publish it for receiving domains, a small domain-count percentage still touches substantial mail volume.
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.
|
|
|
|---|---|---|
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 lacked the required A or AAAA record.
- 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. No broad public census provides a reliable combined deployment rate or global traffic-weighted coverage rate.
MTA-STS and TLS-RPT are different
A lot of confusion comes from treating MTA-STS and TLS-RPT as one setting. They fit together, but they are not the same control. MTA-STS is the policy that receiving domains publish. TLS-RPT is the mailbox or HTTPS endpoint where aggregate TLS reports are sent. TLS-RPT can report outcomes for MTA-STS, DANE, or a connection where no transport policy was found.
MTA-STS
- Purpose: Tell supporting senders to require 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 under the SMTP TLS reporting name.
- 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 show stable TLS and every MX certificate name matches the policy.
MTA-STS and TLS-RPT rollout from reporting and testing to enforcement.
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. Starting with enforce is unsafe unless the mail architecture is simple and every MX hostname already has a valid publicly trusted certificate.
- 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: Start receiving aggregate reports before enforcement changes delivery behavior.
- Publish MTA-STS: Use testing mode first, with a short max age during rollout.
- Review failures: Fix policy fetch, certificate, and unsupported STARTTLS problems before enforcement.
- Enforce slowly: Move to enforce after the reports have been 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"
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, move the HTTPS policy to enforce and raise max_age. Keep the TXT id value versioned. Changing the id when the policy changes signals supporting senders to fetch the updated policy instead of waiting for the cached policy's max_age to expire.
MTA-STS policy in enforce modetext
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.
What TLS reports actually tell you
TLS reports are aggregate diagnostics. They do not contain message content. They identify the reporting organization, policy, affected MX host, successful session count, failed session count, and broad failure type. Failure categories can overlap for one connection, so summing every failure detail can overcount affected sessions.
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.
TLS reporting is visibility, not an inbox ranking trick
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.
Where Suped fits
MTA-STS and TLS-RPT sit next to DMARC, SPF, DKIM, MTA-STS hosting, blocklist monitoring, blacklist checks, and delivery troubleshooting. Treating each one as a separate project creates separate owners and separate alerts. The practical workflow is one domain health view, one set of issues, and clear fix steps.
Suped's product brings DMARC monitoring, SPF and DKIM monitoring, Hosted SPF, SPF flattening, Hosted MTA-STS, Hosted MTA-STS reporting, Hosted MTA-STS policy staging, blocklist monitoring, blacklist visibility, and real-time alerts into one workflow. For teams operating multiple domains, it turns authentication and transport signals into issue detection and fix steps instead of leaving raw reports in a mailbox.
- Hosted policy: Suped can manage the MTA-STS policy without requiring a custom web server.
- Policy staging: Move through testing and enforce with clearer change control.
- Issue detection: Surface certificate, DNS, authentication, and reporting problems as actionable items.
- 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 especially useful when DNS is owned by one team, web hosting by another, and mail routing by a third. A basic self-hosted setup works, but it creates one more HTTPS endpoint and one more policy file that has to stay correct. Suped's Hosted MTA-STS workflow reduces that operational burden to DNS records and policy choices.
Before enabling enforcement, check the basic authentication records. Use the domain health checker to inspect DMARC, SPF, DKIM, and adjacent domain settings before treating TLS reports as the only source of truth.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The tool gives you a clean baseline, while TLS reports show transport outcomes from reporting senders. If DMARC is missing, SPF has too many DNS lookups, DKIM is not in place, or MX records are stale, fix those basics before treating MTA-STS enforcement as the next security milestone.
When adoption matters most
The value is highest when your domain receives important mail and when a delivery failure is easier to tolerate than silent downgrade risk. MTA-STS is a receiving-domain assurance control: it tells senders that support the policy to use the MX hosts you published and to 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 | Wait for MX |
Practical priority by domain type
Adoption remains below 1%. Decide whether your mail paths include enough report-capable senders and policy-aware destinations to justify the work. For a serious receiving domain, the answer is usually yes because the setup cost is small compared with the value of knowing when secure transport fails.
The most defensible rollout rule
Deploy TLS-RPT first, deploy MTA-STS in testing mode second, and enforce only after the reports show that the policy matches the real MX setup. That gives you value even while broader adoption is still growing.
Views from the trenches
Best practices
Start in testing mode, collect reports, then enforce after MX and certificates stay clean.
Keep TLS-RPT separate from MTA-STS so reporting survives a policy hosting change later.
Use traffic-weighted coverage as the real measure, not only raw domain adoption rates.
Common pitfalls
Assuming low domain adoption means low value misses traffic sent to large mailbox domains.
Publishing enforce before certificate names match every MX host creates delivery risk.
Expecting MTA-STS to fix user-submitted SMTP credentials confuses separate problems.
Expert tips
Review TLS report failures weekly and route certificate issues to the team owning MX hosts.
Use a hosted policy when DNS and web ownership are split across different internal teams.
Raise max_age gradually so a bad policy can be corrected quickly during early rollout.
Marketer from Email Geeks says MTA-STS adoption by raw Top 1 million domain count is still below 1%, but it has more than doubled since 2024.
2026-01-06 - Email Geeks
Marketer from Email Geeks says traffic-weighted impact can be much higher because large consumer mailbox domains account for a large share of real mail.
2026-01-07 - Email Geeks
The practical answer
The current adoption of TLS reporting with MTA-STS is low if you count domains, but meaningful on important mail paths. The 2026 Top 1 million domain signal sits around 0.7% for MTA-STS policy publication. TLS-RPT adoption is harder to summarize because it is a separate reporting record, and usable report coverage depends on which senders generate reports.
The value is clearest when TLS reports catch MX certificate problems before users notice and confirm secure inbound transport on reporting paths. For a domain that receives important mail, publish TLS-RPT, publish MTA-STS in testing mode, and move to enforce after the reports are clean.
DMARC, SPF, DKIM, and reputation monitoring remain necessary. MTA-STS adds transport assurance, and TLS-RPT adds transport reporting. Managed alongside the other controls, both are small enough to deploy and useful enough to keep.
