Is a Google TLS report evidence of an attack?

No. It is routine aggregate feedback requested by the domain's TLS-RPT record. Investigate the failure categories and trend.

Does the report contain email content?

No. TLS-RPT is designed around aggregate transport results, policies, and failure details rather than message content.

Why do I receive reports without publishing MTA-STS?

TLS-RPT can report on applicable SMTP TLS policies, including other mechanisms. The smtp.tls record requests reporting separately from the mta-sts policy signal.

Should I delete smtp.tls to stop the messages?

Only if the organization no longer wants transport feedback. Deleting it hides evidence and does not fix a TLS failure.

Are Google reports enough to validate all senders?

No. They describe Google's observed attempts. Other senders can produce separate reports or encounter different routes and failures.

Why is Google sending MTA-STS TLS reports?

Google sends MTA-STS TLS reports because your domain publishes an SMTP TLS Reporting record that requests aggregate delivery data. The report summarizes Google's attempts to deliver mail to your MX hosts, the TLS policy it found, successful sessions, and categorized failures. Receiving a report is expected and does not by itself mean mail was lost. Read the date range, policy, totals, and failure type, then compare persistent failures with the domain's current MTA-STS file, MX records, certificates, and inbound servers.

Quick takeaways

TLS-RPT reports are aggregate transport-security feedback, not DMARC reports.
Google can send them when _smtp._tls publishes a report destination.
A report can contain only successful sessions.
Persistent certificate, MX, DNS, or negotiation failures need receiver-side investigation.
Do not disable MTA-STS because of one transient count without checking the actual policy and infrastructure.

TLS reports describe policy application, shown as a four-step technical sequence.

This diagram summarizes the article's diagnostic sequence. Use the linked standards, current provider documentation, and production evidence for exact decisions. Open the full-size diagram.

What does the failure mean?

RFC 8460 defines a JSON report that groups TLS delivery outcomes over a time range. It records the policy the sending system applied, successful-session counts, failed-session counts, and failure categories. Google Workspace documents daily reports with traffic and connection information.

The report is about mail traveling to your receiving domain. It does not evaluate SPF, DKIM, or DMARC. Those authenticate sender identity after or alongside transport.

What usually causes it?

The report records normal successful traffic

An aggregate file can arrive because reporting is enabled, even when every covered session succeeded. Check totals before treating the message as an alert.

The MTA-STS policy does not match current MX hosts

A migrated or backup MX host may be missing from the policy's mx patterns. Under RFC 8461, a compliant sender applying enforce mode will not deliver to an MX that the policy does not authorize.

TLS authentication or negotiation fails

Expired certificates, hostname mismatch, incomplete chains, unsupported negotiation, or an unavailable inbound host can produce persistent failure categories.

How do I diagnose the failure?

1. Validate the report envelope and JSON

Confirm the report covers your domain, the date range is plausible, and the policy domain and report identifier are consistent. Treat unexpected attachments cautiously.

2. Read summary counts before details

Compare total-successful-session-count with total-failure-session-count. Identify whether the failures are isolated, concentrated on one MX, or increasing over several reports.

3. Compare the reported policy with production

Query _mta-sts and retrieve the HTTPS policy file. Compare its mode, ID, max age, and mx patterns with live MX records.

4. Test every inbound MX host

Check DNS, TCP reachability, STARTTLS, certificate names, chain validation, and supported TLS versions from outside the network. Include lower-priority backup hosts.

How do I fix it?

Correct the component named by the persistent failure. Update the policy when MX hosts changed, renew and install a valid certificate chain, restore an unavailable listener, or fix DNS and routing. Change the policy ID when publishing a new policy so senders know to refresh it.

Use testing mode while validating a new deployment. Do not leave a broken enforce policy in place if it prevents compliant senders from reaching every authorized MX, but preserve transport protection while applying a controlled repair.

How do I validate the repair?

Test every MX externally and confirm the HTTPS policy matches it. Then compare subsequent reports across at least one full reporting period. Failure counts should fall for the corrected category without a drop caused by removing the report destination.

Use Palisade's DNS lookup tool to inspect MX and TXT records and Email Security Score for public posture. TLS reports and direct connection tests remain the transport proof.