What TLS-RPT reports are
TLS-RPT (SMTP TLS Reporting, RFC 8460) is a mechanism for receiving servers to get daily JSON reports from sending mail servers. These reports describe what happened when a sender tried to establish a TLS connection to deliver mail to your domain. Did the TLS handshake succeed? Did it fail because the certificate expired? Was the MTA-STS policy unreachable?
You enable TLS-RPT by publishing a DNS TXT record at _smtp._tls.example.com:
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"
Once published, compliant senders will deliver daily JSON reports (typically gzipped as .json.gz) to the address you specified. These reports cover TLS negotiation outcomes for mail delivered to your domain, not from it. That distinction matters, and we will come back to it.
No reports received
Symptom
You published a _smtp._tls record, waited several days, and received nothing. No reports, no errors, no bounces.
Root causes
This is the single most common TLS-RPT complaint, and it usually comes down to one of three things.
1. Low sender adoption
TLS-RPT adoption is far lower than DMARC aggregate reporting. As of 2026, only a handful of major providers send TLS-RPT reports in meaningful volume:
- Google (Gmail, Workspace)
- Microsoft (Outlook.com, Microsoft 365)
- Comcast
- Mail.ru
- Mimecast
If your domain primarily receives mail from senders outside this list, you may legitimately get zero reports. That does not mean your setup is broken.
2. Wrong rua address
A typo in the rua value, a wrong subdomain, or a mailbox that does not exist will silently eat your reports. Verify the DNS record matches an active mailbox:
dig TXT _smtp._tls.example.com +shortConfirm that the address in the output actually receives mail. Send yourself a test message to that address and verify delivery.
3. Reports going to spam
TLS-RPT emails carry .json.gz attachments from automated senders. Spam filters flag these aggressively. Check your spam and junk folders. If you use a dedicated reporting mailbox, verify that no upstream filter is quarantining messages with compressed attachments.
Timeline
TLS-RPT reports are daily aggregates. After publishing your DNS record, allow 24 to 48 hours for DNS propagation and the first reporting cycle to complete. If you still have nothing after 72 hours and you confirmed the DNS record and mailbox are correct, the issue is likely sender adoption for your specific mail volume.
Microsoft sends to first rua only
Symptom
You configured multiple rua endpoints in your TLS-RPT record (your inbox plus a monitoring service). Google and Comcast deliver to both. Microsoft delivers only to the first one.
Diagnosis
The TLS-RPT spec (RFC 8460 section 3) allows multiple reporting URIs separated by commas. Most implementations send to all of them. Microsoft's implementation only sends to the first address in the list.
# Your record
"v=TLSRPTv1; rua=mailto:[email protected],mailto:[email protected]"
# Microsoft sends only to: [email protected]
# Google sends to both addressesSolution
Put your most important endpoint first. If you use a monitoring service and want to ensure Microsoft data is captured, place the monitoring service address before your personal mailbox:
"v=TLSRPTv1; rua=mailto:[email protected],mailto:[email protected]"Google reports flagged as spam or phishing
Symptom
Emails from [email protected] arrive in spam, or colleagues flag them as phishing because they contain compressed attachments and come from an unfamiliar automated sender.
Solution
These are legitimate TLS-RPT reports from Google. The sender is [email protected] and the attachments are .json.gz files containing report data.
- Whitelist
[email protected]in your spam filter - If using Exchange Online, create a transport rule to bypass junk filtering for this sender
- Inform your team that these emails are expected automated reports, not phishing
TLS-RPT failure types explained
Each TLS-RPT JSON report contains a result-type field that tells you exactly what went wrong during the TLS handshake. Here is a reference for every failure type you will encounter.
certificate-expired
The TLS certificate on your MX server has expired. The sending server attempted a TLS connection, received a certificate with a notAfter date in the past, and either downgraded to plaintext or refused delivery (depending on whether MTA-STS or DANE is enforced).
Fix: Renew the certificate on your MX host immediately. If you use Let's Encrypt, check that your Certbot renewal cron is running. Verify with:
openssl s_client -connect mx.example.com:25 -starttls smtp 2>/dev/null | openssl x509 -noout -datescertificate-host-mismatch
The certificate presented by your MX server does not include the MX hostname in its Subject Alternative Name (SAN) list. For example, your MX record points to mail.example.com, but the certificate is only valid for example.com and www.example.com.
Fix: Reissue the certificate with the correct MX hostname in the SAN field. Verify the SAN entries:
openssl s_client -connect mx.example.com:25 -starttls smtp 2>/dev/null | openssl x509 -noout -ext subjectAltNamecertificate-not-trusted
The certificate is self-signed, or the server is not sending the complete certificate chain (missing intermediate certificates). The sending server cannot build a trust path to a recognized root CA.
Fix: Install the full certificate chain on your MX server. Most CAs provide a "full chain" or "bundle" file that includes the intermediates. Self-signed certificates will always trigger this failure for senders that enforce certificate validation.
starttls-not-supported
Your MX server does not advertise the STARTTLS SMTP extension. The sending server connected on port 25, issued an EHLO, and the response did not include 250-STARTTLS. Without STARTTLS, no TLS negotiation is possible.
Fix: Enable STARTTLS in your MTA configuration (Postfix: smtpd_tls_security_level = may, Exim: tls_advertise_hosts = *). Verify:
openssl s_client -connect mx.example.com:25 -starttls smtpIf you get a connection refused or no TLS handshake, STARTTLS is not enabled.
sts-policy-fetch-error
The sending server could not retrieve your MTA-STS policy file at https://mta-sts.example.com/.well-known/mta-sts.txt. The server responded with a non-200 status, timed out, or the DNS record at _mta-sts.example.com was not found.
Fix: This is the most common MTA-STS failure. See our dedicated guide: MTA-STS policy fetch errors.
sts-policy-invalid
The policy file was fetched successfully, but its content has syntax errors. Common causes: missing version: STSv1 line, invalid mode value, missing mx: entries, or extra whitespace/BOM characters.
Fix: Verify the exact content of your policy file:
curl -v https://mta-sts.example.com/.well-known/mta-sts.txtThe file must follow this exact format (no blank lines before the first field, no trailing characters):
version: STSv1
mode: testing
mx: mx1.example.com
mx: mx2.example.com
max_age: 86400sts-webpki-invalid
The HTTPS certificate on mta-sts.example.com is invalid. The sending server could not establish a trusted TLS connection to fetch the policy file. This is different from sts-policy-fetch-error. Here the server was reachable, but the certificate itself was the problem.
Fix: Ensure mta-sts.example.com has a valid, publicly trusted TLS certificate. Check it:
curl -I https://mta-sts.example.com/.well-known/mta-sts.txtIf curl reports a certificate error, fix the certificate on the web server hosting the MTA-STS policy.
validation-failure
A general TLS handshake failure that does not fit the more specific categories. This is a catch-all. The TLS negotiation failed, but the sending server did not classify the reason into a more specific type. Possible causes include cipher suite mismatches, protocol version incompatibilities (e.g., server only supports TLS 1.0), or transient network issues.
Fix: Check your MX server's TLS configuration. Ensure it supports TLS 1.2 or later and offers modern cipher suites. Test with:
openssl s_client -connect mx.example.com:25 -starttls smtp -tls1_2tlsa-invalid
The DANE TLSA record published in DNS does not match the certificate presented by the MX server. This only applies if you have published TLSA records for your MX hosts (DANE, RFC 6698). If you do not use DANE, you will not see this failure type.
Fix: Regenerate and republish your TLSA records to match the current certificate. See the DANE + Let's Encrypt section below for a common cause of this failure.
Direction confusion: TLS-RPT is about inbound mail
TLS-RPT reports tell you what happened when other servers delivered mail to your domain. They describe the TLS connection from the sender's perspective. Did the sender successfully establish an encrypted connection to your MX servers?
TLS-RPT does not tell you about your outbound mail. If you want to know whether your server successfully used TLS when sending to gmail.com, TLS-RPT will not help. For outbound TLS visibility, check your SMTP server logs (Postfix: grep "TLS connection established" /var/log/mail.log).
This confusion is especially common in organizations where the same team manages both inbound and outbound mail infrastructure. TLS-RPT is strictly a receiver-side diagnostic tool.
DANE + Let's Encrypt TLSA renewal breakage
Symptom
Every 60 to 90 days, you see a burst of tlsa-invalid failures in your TLS-RPT reports. They appear after a Let's Encrypt certificate renewal and resolve themselves after DNS propagation completes.
Diagnosis
Let's Encrypt certificates renew every 90 days. By default, Certbot generates a new private key with each renewal. Since DANE TLSA records (usage 3, selector 1) are pinned to the public key hash, a new key means the TLSA hash no longer matches the certificate. During the window between certificate renewal and TLSA record update (plus DNS propagation, which can take hours to a full day), every DANE-validating sender will report tlsa-invalid.
Solution
Two approaches:
-
Reuse the private key. Add
--reuse-keyto your Certbot renewal command. The public key stays the same across renewals, so the TLSA hash remains valid.certbot renew --reuse-key -
Pin with TLSA type 3 1 1. Use certificate association type 3 (DANE-EE), selector 1 (SubjectPublicKeyInfo), and matching type 1 (SHA-256). Combined with
--reuse-key, this gives you a stable TLSA record that survives renewals. If you must rotate keys, pre-publish the new TLSA record with a low TTL and wait for full DNS propagation before the renewal runs.
Prevention
Automate report parsing
Manually downloading .json.gz files, decompressing them, and reading raw JSON is not sustainable. DMARCTrust's Receiver Shield parses TLS-RPT JSON reports automatically. It surfaces failure types, identifies which MX hosts have problems, and tracks trends over time so you can catch certificate expirations or misconfigurations before they affect delivery.
Monitor your MX certificates
Most TLS-RPT failures trace back to certificate problems. Set up automated certificate monitoring for every hostname listed in your MX records. At minimum, alert when a certificate is within 14 days of expiration.
Validate your MTA-STS policy
If you publish an MTA-STS policy, validate that the policy file is reachable and syntactically correct after every change. Use our domain checker to verify your MTA-STS configuration, or read the MTA-STS fundamentals guide for a full walkthrough of policy setup and validation.