What are MTA-STS reports and why am I getting them from Google?
Published 21 Jul 2025
Updated 23 Oct 2026
12 min read
Summarize with
Updated on 23 Oct 2026: We clarified how Google's TLS reports work and how to manage report delivery without changing MTA-STS enforcement.
MTA-STS reports from Google are usually TLS-RPT aggregate reports. They show whether Google's sending servers established policy-compliant TLS connections to your domain's incoming mail servers. They summarize detected policies, session totals, traffic statistics, and categorized connection failures for the reporting period.
The key detail is direction. These reports are about mail Google tried to send to you. They are not reports about mail you sent to Gmail. If the report says Google saw a TLS problem, the problem is usually on your inbound mail path: MX records, certificates, STARTTLS support, MTA-STS policy content, or DNS records.
- The attachment is normally a TLS-RPT JSON file, compressed with gzip.
- Google sends it because Google attempted delivery to your domain.
- Daily reports are normal when there is traffic and reporting is enabled. They normally cover a UTC day and arrive afterward.
- Zero failures means no failures were reported. Review failed sessions, especially when the same error repeats.
Short answer
Receiving a genuine Google TLS report confirms that your reporting address accepted it. Investigate reports with failed sessions, policy validation errors, certificate errors, or STARTTLS negotiation problems.
What Google sends: TLS-RPT aggregate reports
People call these MTA-STS reports because MTA-STS is the policy being checked, but the reporting mechanism is TLS-RPT. MTA-STS tells senders what secure delivery should look like for your domain. TLS-RPT tells senders where to send daily aggregate reports about TLS delivery results. TLS-RPT does not enforce encryption. MTA-STS in enforce mode requires supporting senders to use authenticated TLS for the SMTP connection to your MX host. It does not provide end-to-end encryption or replace DMARC. See MTA-STS policy application.
A sender such as Google discovers your TLS-RPT DNS record, tries to deliver mail to your MX hosts, then sends a compressed JSON report to the destination in the rua tag. If you want the protocol overview before reviewing a live report, the MTA-STS basics page explains the moving parts.
|
|
|
|---|---|---|
MTA-STS | Your TLS policy for inbound mail | Mode, MX names, max age, and TXT ID |
TLS-RPT | Daily aggregate delivery reporting | Report destination and parser |
rua | Where reports are sent | Email mailbox or HTTPS collector |
STARTTLS | TLS upgrade during SMTP | Certificate and negotiation result |
Core terms in a Google TLS report
TLS-RPT DNS recorddns
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"
If multiple teams or systems need a copy, the rua value can include multiple mailto destinations separated by commas. TLS-RPT also permits an https destination when you have a compatible collector that accepts report submissions. Publish TLS-RPT before moving toward MTA-STS enforcement so daily reports exist before delivery risk increases.
That record is separate from the MTA-STS policy TXT record. The TXT record at _mta-sts announces policy discovery. The HTTPS policy file tells senders which MX hosts are valid and whether the policy is in testing, enforce, or none mode.
Why Google reports can start suddenly
A sudden first report does not automatically mean something broke. It often follows new inbound traffic or a change that makes the TLS-RPT destination reachable. MTA-STS policy changes affect the results inside a report; they do not enable reporting by themselves.
How Google generates a TLS-RPT aggregate report for inbound email after DNS discovery and MX delivery.
- A Gmail or Google Workspace sender attempted delivery to one of your recipients.
- Google found your TLS-RPT record during DNS lookup.
- The TLS-RPT reporting destination was added or changed in DNS.
- Your reporting address started accepting the compressed report.
- Mail that stays inside one provider can avoid the external SMTP path covered by TLS-RPT.
If a report has STARTTLS failures, investigate the affected MX host. Compare those failures with SMTP logs if senders also see throttling. The Google STARTTLS errors article explains the related SMTP errors.
Do not read report volume as traffic volume
One daily report can cover many SMTP sessions or only a few. Reports depend on inbound traffic from senders that support TLS-RPT, and mail that stays inside one provider can produce no external TLS session to report. Low report volume does not prove that MTA-STS failed. Session counts measure connections, not individual email messages.
How to read the report
The report attachment is normally a compressed JSON file. Start with the organization name, contact information, report ID, date range, policy type, policy domain, MX host, successful session count, and failed session count. Use the report ID to detect duplicates. If failures are present, inspect each failure detail for its result type, receiving MX hostname, receiving IP, and failed session count. Compare the UTC date range with the timing of any mail-server change. The field definitions are in RFC 8460.
The policy-type value tells you what Google evaluated. sts means MTA-STS, tlsa means a DANE TLSA policy, and no-policy-found means neither policy was found for that policy entry.
A failed TLS session is not a final delivery status. Testing mode permits delivery despite MTA-STS validation failures. Enforce mode prevents delivery over a failing path, but another MX or a later retry can succeed. Check SMTP logs to confirm delivery or a bounce. These behaviors follow the MTA-STS policy modes.
Simplified Google TLS report excerptjson
{ "organization-name": "Google Inc.", "date-range": { "start-datetime": "2026-05-23T00:00:00Z", "end-datetime": "2026-05-24T00:00:00Z" }, "policies": [ { "policy": { "policy-type": "sts", "policy-string": ["version: STSv1", "mode: enforce"] }, "summary": { "total-successful-session-count": 120, "total-failure-session-count": 0 } } ] }
How to triage TLS-RPT failures
Use recurrence, affected MX hosts, and policy mode to prioritize work. TLS-RPT does not define universal percentage thresholds.
Clean
0 failed sessions
Keep the report as a baseline
Check
Any failure
Inspect the result type and receiving MX
Investigate
Repeated failure
Trace the affected host or address family
Fix first
Enforce mode
Policy failures can defer supported senders
Clean MTA-STS report
- The failed session count is zero.
- The policy type is sts.
- Keep monitoring and confirm reports keep arriving.
- Google completed policy-compliant TLS sessions.
Problem report
- The failed session count is above zero.
- The result type identifies the failed TLS or policy check.
- Check the named MX host, IP address, certificate, and policy.
- Some Google sessions did not meet the evaluated policy.
When Google says no policy found
A Google TLS-RPT report with policy-type set to no-policy-found means Google found neither an MTA-STS policy nor a DANE TLSA policy for that policy entry. Treat it as a policy discovery result, not proof that TLS delivery failed. TLS-RPT can report without MTA-STS; a domain that has not published either policy can legitimately receive this result.
MTA-STS discovery locationstext
DNS TXT: _mta-sts.example.com HTTPS policy: https://mta-sts.example.com/.well-known/mta-sts.txt
- Check the TXT record at _mta-sts.example.com. It should contain v=STSv1 and an id value.
- Fetch https://mta-sts.example.com/.well-known/mta-sts.txt. The TXT record does not contain the policy URL.
- Confirm the file is plain text, has version: STSv1 on the first line, and includes mode, mx, and max_age.
- Google's setup guidance lists a max_age range of 86400 to 31557600 seconds. Its testing recommendation is 604800 to 1209600 seconds; RFC 8461 permits non-negative values up to 31557600.
- Publish the revised HTTPS policy first, then update the TXT id so senders can detect the change. DNS caches and unexpired cached policies can delay when a sender uses the replacement.
Do not fix only the TLS-RPT record when Google reports no policy found. TLS-RPT controls reporting. The MTA-STS TXT record and HTTPS policy file control whether Google can discover and apply your policy.
What to check when Google reports failures
When Google reports a failure, use its result type to decide whether to check policy discovery or an MX connection. Verify DNS, the HTTPS policy file, MX hostname coverage, certificate names, STARTTLS support, TLS 1.2 or later, and IPv4 plus IPv6 behavior. Test every primary and backup MX host because a clean aggregate report only covers paths that Google used during that reporting interval.
You can run a quick domain health check before opening the JSON report by hand. It gives you a fast view of the DNS and MTA-STS issues that can affect secure inbound delivery.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A common MTA-STS mismatch is an MX hostname in DNS that does not appear in the policy file. Senders validate the mail exchanger they actually connect to, not the provider name you expected them to use.
Example MTA-STS policy filetext
version: STSv1 mode: enforce mx: mail.example.com mx: backup.example.com max_age: 604800
Treat enforce mode carefully
In enforce mode, a sender that supports MTA-STS must not deliver to an MX host that fails policy validation. Google recommends two weeks in testing mode. Move to enforce only after every inbound MX path has passed direct checks and the reports stay clean.
How Suped helps with MTA-STS reports
Suped's product collects TLS-RPT reports and shows the policy domain, reporting provider, successful session count, and failed session count. Open TLS-RPT in the sidebar, then use View report to inspect the raw JSON and any failure details supplied by Google.
Hosted MTA-STS/TLS-RPT configuration dialog showing policy mode, MX hosts, CNAME records, TLS reporting, and verification
For MTA-STS specifically, Suped's Hosted MTA-STS lets you publish and manage the policy without maintaining separate web hosting for the policy file. You configure the policy, publish the two required CNAME records, then add the separate TLS-RPT reporting record shown by Suped to collect delivery reports.
- Use two CNAME records instead of running your own policy host.
- Keep the policy in testing mode while you validate every inbound MX path.
- Publish the separate TLS-RPT reporting record shown in Suped; policy hosting alone does not collect reports.
- Review the reported counts, then inspect the raw JSON for the affected receiving MX host or IP address when supplied.
Use the receiving MX hostname and IP address in a failure detail to investigate that endpoint. After fixing its configuration, review later reports to check whether the same error recurs.
How to interpret TLS-RPT failure types
When a Google report has failures, read the exact result-type value before changing DNS or certificates. Then use the receiving MX hostname and receiving IP to identify the affected endpoint.
|
|
|
|---|---|---|
starttls-not-supported | The receiving MX did not advertise STARTTLS | Enable and test STARTTLS on the named MX |
certificate-expired | The MX certificate expired | Renew the certificate and check automation |
certificate-host-mismatch | Certificate names do not cover the MX hostname | Install a certificate that covers the MX name |
certificate-not-trusted | The chain is untrusted or incomplete | Install a publicly trusted complete chain |
sts-policy-fetch-error | The HTTPS policy file could not be retrieved | Fix policy hosting, HTTPS, or availability |
sts-policy-invalid | The fetched policy did not validate | Correct the policy syntax and required fields |
sts-webpki-invalid | The policy host failed HTTPS certificate validation | Fix the certificate on mta-sts.example.com |
validation-failure | A general TLS or policy validation check failed | Use the failure reason and endpoint fields |
Common TLS-RPT result types
Failure categories are non-exclusive, so the detail counts do not always form a clean partition of the total failure count. Also check IPv6. A domain can pass over IPv4 but fail over IPv6 because that endpoint has a different certificate, lacks STARTTLS, or routes to an older mail server.
A clean report still has value
A report with successful sessions and zero failures confirms policy-compliant TLS connections for the sessions counted. It does not test an unused backup MX or prove that every sender supports MTA-STS. With no policy found, successful TLS does not prove MTA-STS enforcement. Keep clean reports as a baseline before DNS or MX changes.
How to manage unexpected Google TLS reports
Check that the policy domain is yours and the report destination matches your TLS-RPT configuration. RFC 8460 requires emailed reports to have a valid DKIM signature by the reporting domain. Check your receiving mail system's authentication results before trusting an unexpected report; a Google display name alone is insufficient.
- Route reports to a dedicated mailbox or compatible report collector to keep them out of a personal inbox.
- To redirect future reports, change the rua destination in your _smtp._tls TXT record, or update the reporting configuration if that record is delegated.
- To stop reporting entirely, remove the TLS-RPT record at _smtp._tls. This removes reporting visibility without changing your MTA-STS enforcement policy.
- Allow for DNS caching and reports already generated before expecting inbox delivery to stop.
Keep your MTA-STS discovery record and HTTPS policy file in place when changing report delivery. Google's TLS reporting setup instructions explain where report destinations are configured in DNS.
What to do next
If you started receiving Google reports, verify the message authentication before opening the attachment. Check whether failures are present and confirm that the policy Google evaluated matches the policy you intended to publish.
- Verify that the report was sent to a destination in your TLS-RPT DNS record.
- Read the session totals, then review every result type and affected MX host.
- Check TLS 1.2 or later, certificates, policy files, and DNS after mail platform changes.
- Keep daily history so a recurring failure has context.
Frequently asked questions
In casual wording, people often use the terms together, but they are separate standards. TLS-RPT defines reporting. MTA-STS defines the policy evaluated in many of those reports.
Not every sender supports TLS-RPT, and reports depend on inbound SMTP sessions to your domain. Mail that stays inside one provider can avoid the external SMTP path, while a sender that rarely emails your domain has few results to summarize.
No. The report includes successful and failed TLS sessions. A failed session does not establish that a message ultimately bounced: delivery can succeed on another compliant MX or a later retry. Testing mode also permits delivery despite MTA-STS validation failures.
It means neither an MTA-STS policy nor a DANE TLSA policy was found for that policy entry. This is expected if you enabled only TLS-RPT. If you intended to publish MTA-STS, check the _mta-sts TXT record, fixed HTTPS policy location, max_age value, and TXT id.
Start in testing mode for two weeks, as Google recommends. Move to enforce after every primary and backup MX hostname, TLS certificate, policy file, and address family has passed checks and the reports stay clean.
Use a dedicated mailbox or a compatible HTTPS collector that can parse compressed JSON reports, retain history, detect duplicates, and alert on failures. A normal personal inbox becomes hard to manage quickly.
