Standard / Protocol
RFC 8460
IETF Standard
Adoption / Scope
JSON Telemetry
Daily Diagnostic Feed
Operational Target
11 Error Types
RFC Failure Classification
Failure Impact
MTA-STS & DANE
Direct Policy Telemetry
Executive Summary

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.

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

  1. DNS Declaration: The recipient domain publishes a DNS TXT record at _smtp._tls.<domain> declaring reporting endpoints via rua=.
  2. 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.
  3. 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>:

DNS TXT Record • Hostname: _smtp._tls.example.com TTL: 3600
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:

RFC 8460 JSON Telemetry Payload Sample application/tlsrpt+json
{
  "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
The AutoSMTP Enterprise Advantage

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.

Dedicated Bare-Metal MTAsHigh-speed PowerMTA and KumoMTA clusters provisioned with dedicated IPv4 addresses and custom PTR records.
Automated Gas-Pedal WarmupContinuous volume throttling aligned with real-time Google Postmaster spam ratios (<0.1%) and Microsoft SNDS metrics.
Native Socket Interceptors & FBLAutomated RFC 5321 bounce handling and real-time complaint ingestion across Yahoo, Microsoft, and major global mailbox providers.
Full Authentication AutomationAutomated 2048-bit DKIM key rotation, strict SPF syntax generation, DMARC policy enforcement, and BIMI integration.

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 →