Why is Google sending MTA-STS TLS reports to my domain?

Current requirements

TLS-RPT publication for aggregate feedback

• Applies to: A receiving domain that wants participating senders to send SMTP TLS aggregate reports.
• Effective: When the domain publishes a valid TLS-RPT TXT record. RFC 8460 does not define a Google-specific enforcement date.
• Required evidence: A TXT record at _smtp._tls.yourdomain.com with a v=TLSRPTv1 version tag and at least one rua report destination.
• Consequence: Participating senders can send aggregate reports to the declared destination. Publishing the record does not prove that every sender supports TLS-RPT or that every delivery attempt will appear in a report.

_smtp._tls.yourdomain.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com"

MTA-STS policy matching

• Applies to: A domain that publishes an MTA-STS policy and has senders that apply it.
• Effective: When the sender has retrieved a valid MTA-STS policy and the policy is in enforce mode.
• Required evidence: The live _mta-sts.yourdomain.com TXT record, the HTTPS policy file, current MX answers, and a production connection test for each receiving MX host.
• Consequence: RFC 8461 says a sender applying an enforce-mode policy must not deliver when it cannot establish an authenticated TLS connection to an MX host authorized by that policy.

Google Workspace report content

• Applies to: Google Workspace administrators receiving reports about connections to their domain.
• Effective: Google documents reports as daily. Google does not publish a numeric sender threshold for this reporting behavior.
• Required evidence: The report's policy domain, reporting interval, summary counts, and failure details, compared with current receiving infrastructure.
• Consequence: Google says its reports can provide information about detected MTA-STS policies, traffic statistics, failed connections, and undelivered messages. The report does not identify every possible sender or establish the cause of an individual recipient's non-delivery.

Implementation and validation

1. Confirm that the report was requested

Check DNS for the exact receiving domain named in the report. The TLS-RPT record is distinct from the MTA-STS policy record. A domain can request reports without publishing MTA-STS, because RFC 8460 can report on other applicable TLS policies.

Use the MTA-STS checker for the public record and policy inputs. A public check cannot inspect Google's report stream, your inbound mail logs, future DNS state, or every sender's connection path.

2. Read the reporting interval and totals

RFC 8460 reports aggregate outcomes for a date range. Start with the policy domain and the start and end timestamps. Then compare the successful and failed session counts before treating a report as an incident.

A report that contains successful sessions only is expected feedback. A small isolated failure count can be an operational signal, but it does not establish a persistent fault. Compare several report periods before drawing that conclusion.

3. Match each failure to the current receiver path

Review the report's failure details alongside the MX host that handled the connection. Then compare the report's policy description with the current MTA-STS policy, DNS answers, certificate name, certificate chain, and SMTP TLS negotiation from outside your network.

The report format can identify the policy context and failure category. Mapping a category to one local root cause is an operational inference until your DNS, certificate, load balancer, and MTA evidence confirms it.

Do not remove an MX host from an MTA-STS policy or disable enforce mode as a first response. A rushed policy change can make a legitimate backup route unavailable to senders that honor MTA-STS.

4. Test every advertised MX host

Test primary and backup MX hosts. Include hosts with lower MX preference because senders can reach them during a failover. Confirm that each authorized hostname resolves as expected, accepts SMTP connections, offers STARTTLS, and presents a certificate valid for the host name under the policy.

An illustrative MTA-STS policy has this shape:

version: STSv1
mode: enforce
mx: mx1.yourdomain.com
mx: mx2.yourdomain.com
max_age: 604800

The policy file belongs at the HTTPS location specified by RFC 8461. Increment the policy ID in the _mta-sts TXT record when you publish a changed policy so senders can detect that they should retrieve it again.

5. Validate at four independent layers

A working DNS record is only one layer of evidence.

• DNS: Query the authoritative DNS provider and at least one public resolver for _smtp._tls, _mta-sts, and the MX records.
• Vendor: Review the Google-generated report for the covered interval and policy details. Google's report reflects its own observed connections.
• Message and transport: Use inbound MTA logs or a controlled external SMTP test for each production MX host. DNS does not prove a successful TLS session.
• Ongoing DMARC evidence: Use DMARC aggregate reports to inventory mail sent using your domain. Those reports do not replace receiver-side TLS evidence.

Change log

August 12, 2026

Rechecked Google's MTA-STS and TLS reporting documentation, RFC 8460, and RFC 8461. Confirmed that Google documents daily TLS reports with policy, traffic, failed-connection, and undelivered-message information. Confirmed that RFC 8460 defines aggregate reporting through a published TLS-RPT destination and that RFC 8461 defines enforce-mode delivery behavior. No Google-published numeric threshold or universal TLS-RPT mandate was found.

July 18, 2026

Published the initial tracker with the distinction between expected aggregate reports and persistent receiver-side failures. Recorded the need to compare report evidence with live DNS, MTA-STS policy, TLS certificates, and inbound SMTP service.

Check the public MTA-STS configuration before changing it

Run your receiving domain through the MTA-STS checker to inspect the public TLS-RPT record, MTA-STS DNS record, policy file, and advertised MX host patterns. Compare that result with the report's policy domain and failure details before changing a certificate or policy.

Palisade is DMARC software. It can analyze DMARC aggregate-report data, identify sending sources and authentication or alignment issues, and propose a next policy step for human review. It does not repair an inbound TLS failure, control Google's delivery decision, or make a public check continuous proof of SMTP transport behavior.

Start with Palisade