SMTP TLS Reporting (TLS-RPT), standardized under RFC 8460, provides receiving domains with aggregated daily JSON telemetry from sending MTAs regarding TLS connection success rates and policy failures under MTA-STS and DANE. TLS-RPT gives email operators visibility into expired certificates, cipher mismatches, and active downgrade attacks across their mail exchangers.
In This Technical Guide
The Inbound Encryption Blind Spot
While DMARC aggregate reports (RFC 7489) provide comprehensive visibility into sender identity and message authentication, they offer zero diagnostic insight into transport layer encryption. If an MX server certificate expires, if a firewall strips STARTTLS, or if a cipher incompatibility prevents an encrypted socket from forming, domain administrators typically remain oblivious until inbound customer emails fail.
SMTP TLS Reporting (TLS-RPT, RFC 8460) eliminates this visibility blind spot. Published in DNS alongside MTA-STS or DANE, TLS-RPT instructs sending MTAs (including Google, Microsoft, and Comcast) to generate daily machine-readable JSON reports detailing successful encrypted sessions and diagnostic breakdowns of every transport failure.
How TLS-RPT Operates: The Reporting Flow
- DNS Declaration: The recipient domain publishes a DNS TXT record at
_smtp._tls.<domain>declaring reporting endpoints viarua=. - Delivery Session Logging: When an external MTA (such as Gmail’s outbound cluster) attempts delivery to the domain’s MX servers, it records TLS handshake metrics, certificate validation results, and policy checks.
- Report Aggregation & Compression: Every 24 hours, the sending MTA aggregates connection statistics into a standardized JSON payload, compresses it with gzip, and dispatches it via email (
mailto:) or HTTPS POST.
TLS-RPT DNS Discovery Record (_smtp._tls)
The TLS-RPT policy is published as a DNS TXT record located at the designated subdomain _smtp._tls.<domain>:
v=TLSRPTv1; rua=mailto:tls-reports@example.com,https://api.example.com/v1/tls-rpt
| Tag | Requirement | Allowed Values | Description |
|---|---|---|---|
v= |
Mandatory | TLSRPTv1 |
Protocol version identifier. Must appear first. |
rua= |
Mandatory | URI List | Comma-separated list of reporting destinations. Supports mailto: and https://. |
Deconstructing the RFC 8460 JSON Telemetry Payload
Each report contains structured JSON metadata divided into policies, session counts, and detailed failure arrays:
{
"organization-name": "Google LLC",
"date-range": {
"start-datetime": "2026-10-26T00:00:00Z",
"end-datetime": "2026-10-26T23:59:59Z"
},
"contact-info": "smtp-tls-reporting@google.com",
"report-id": "2026-10-27-google-to-example.com-001",
"policies": [
{
"policy": {
"policy-type": "sts",
"policy-string": ["version: STSv1", "mode: enforce", "mx: mail.example.com", "max_age: 604800"],
"policy-domain": "example.com"
},
"summary": {
"total-successful-session-count": 48210,
"total-failure-session-count": 2
},
"failure-details": [
{
"result-type": "certificate-expired",
"sending-mta-ip": "209.85.220.41",
"receiving-mx-hostname": "backup-mail.example.com",
"receiving-mx-ip": "198.51.100.45",
"failed-session-count": 2
}
]
}
]
}
The 11 RFC 8460 Result Types & Diagnostic Fixes
| Result Type | Category | Technical Meaning & Remediation |
|---|---|---|
starttls-not-supported |
Negotiation | The receiving MX did not advertise STARTTLS in response to EHLO. Check MTA config. |
certificate-expired |
Certificate | The TLS certificate presented by the MX has expired. Renew SSL certificate on mail host. |
certificate-not-trusted |
Certificate | The certificate was issued by an untrusted or missing intermediate CA. Install full certificate chain. |
certificate-host-mismatch |
Certificate | The MX hostname does not match the SANs in the certificate. Re-issue certificate with correct FQDN. |
validation-failure |
MTA-STS | General policy validation error. Verify HTTPS policy syntax at mta-sts.txt. |
tlsa-invalid |
DANE | TLSA record syntax error or record data corruption in DNS. |
dnssec-invalid |
DANE | DNSSEC signature expired or failed validation on the MX domain. Check DNSSEC zone signing. |
Sender Support Matrix: Who Dispatches TLS-RPT Reports?
| Sending Entity | Dispatches TLS-RPT? | Delivery Method | Reporting Cadence |
|---|---|---|---|
| Google Workspace / Gmail | Yes (Largest Global Sender) | mailto: (gzip XML/JSON) |
Daily (UTC 00:00) |
| Microsoft 365 / Exchange Online | Yes | mailto: |
Daily |
| Comcast / Xfinity | Yes | mailto: |
Daily |
| Mail.ru / Yandex | Yes | mailto: |
Daily |
| Fastmail | Yes | mailto: |
Daily |
Turnkey Infrastructure Provisioned for Bulletproof Deliverability
Eliminate protocol configuration failures, manual DNS drift, and deliverability drops. AutoSMTP automates dedicated MTA deployment, IP ramp-ups, and live RFC compliance on unthrottled enterprise bare-metal.
Upgrade to Enterprise Dedicated Email Infrastructure
Deploy unthrottled bare-metal SMTP relay clusters with built-in warming, authentication, and 24/7 deliverability defense.
View Infrastructure Plans →