SMTP TLS Reporting
Extracted elements (28)
Certificate validation is intentionally allowed to be skipped when submitting reports via HTTPS POST because a misconfigured SMTP server likely also has a misconfigured HTTPS server, and failing to deliver reports on benign misconfigurations outweighs the risk of an attacker intercepting reports (who could already obtain the metadata passively).
For HTTPS transport, the receiving system MUST return a successful HTTP response (typically 200 or 201); other codes may indicate failure and can trigger retry per local sender policy.
If metadata declared via email subject or filename disagrees with the report body, the report body MUST be considered the authoritative source.
If multiple TXT records for '_smtp._tls' are returned and the number of records beginning with 'v=TLSRPTv1;' is not exactly one, senders MUST assume the recipient domain does not implement TLSRPT.
In the event of delivery failure, a sender SHOULD attempt redelivery for up to 24 hours after the initial attempt, ideally with exponential backoff for multiple retries.
Internationalized domain names in the 'domain' and 'mx-host-pattern' fields MUST consist of Punycode-encoded A-labels (RFC 3492) and not U-labels.
Reports sent via SMTP MUST contain a valid DKIM signature by the reporting domain, and reports lacking such a signature MUST be ignored by the recipient. DKIM signatures MUST NOT use the 'l=' attribute to limit body length.
The 'policies' field of the report body MUST be a JSON array (not a singular value) even when only a single policy was applied, because reporters may report multiple applied policies.
The report SHOULD be gzip-compressed for both email and HTTPS transport; a commonly observed receiver limit is 10 megabytes, making compression critical for acceptance.
The 'TLS-Report-Submitter' header value MUST match the domain of the 'contact-info' in the report body. Both 'TLS-Report-Domain' and 'TLS-Report-Submitter' MUST be included and SHOULD be covered by the DKIM signature.
When sending failure reports via SMTP (mailto), Sending MTAs MUST deliver reports despite any TLS-related failures and SHOULD NOT include that SMTP session in the next report, meaning reports may be delivered unencrypted.
When sending failure reports via SMTP, Sending MTAs MUST NOT honor MTA-STS or DANE TLSA failures for the report delivery session itself, ensuring reports reach their destination even when the normal policy would block the connection.
Sending TLS failure reports may reveal information about the sender's TLS implementation, operating system, or geographic region to the receiving site, since the inability to negotiate a session may indicate a known incompatibility between two specific implementations.
Defined failure result types include negotiation failures (starttls-not-supported, certificate-host-mismatch, certificate-expired, certificate-not-trusted, validation-failure), DANE-specific failures (tlsa-invalid, dnssec-invalid, dane-required), and MTA-STS failures (sts-policy-fetch-error, sts-policy-invalid, sts-webpki-invalid).
Email-transported reports use Content-Type 'multipart/report; report-type="tlsrpt"' with a human-readable first part (text/plain) and a machine-readable second part (application/tlsrpt+json or application/tlsrpt+gzip). Two new header fields 'TLS-Report-Domain' and 'TLS-Report-Submitter' MUST be included.
The JSON report schema includes: organization-name, date-range (start-datetime/end-datetime in RFC 3339 format), contact-info (email), report-id, and a 'policies' array each containing policy metadata, a summary with success/failure counts, and a 'failure-details' array.
The TLSRPT reporting policy is published as a DNS TXT record under '_smtp._tls.<policy-domain>'. It contains a version field ('v=TLSRPTv1') and one or more aggregate report URIs ('rua=') supporting 'mailto' and 'https' schemes.
The 'total-successful-session-count' field serves as a heartbeat confirming that reporting is functional and TLS is being successfully negotiated; 'total-failure-session-count' aggregates all failed connection attempts.
Creates the 'Report Type Registry' for the 'report-type' parameter of the 'multipart/report' Content-Type header, with 'Specification Required' update procedure. Initial entry: 'tlsrpt' mapped to application/tlsrpt+json and application/tlsrpt+gzip.
Creates the 'STARTTLS Validation Result Types' registry with 11 initial entries (starttls-not-supported, certificate-host-mismatch, certificate-expired, tlsa-invalid, dnssec-invalid, dane-required, certificate-not-trusted, sts-policy-invalid, sts-webpki-invalid, validation-failure, sts-policy-fetch-error). New entries require Expert Review.
Registers media types 'application/tlsrpt+json' (.json extension) and 'application/tlsrpt+gzip' (.gz extension, magic bytes 0x1f 0x8b) for use with SMTP TLS Reporting.
Registers the '+gzip' structured syntax suffix for media types whose representation follows the application/gzip format (RFC 1952/RFC 6713).
Administrators are encouraged to deploy TLSRPT TXT records with a large TTL or use DNSSEC on the zone to prevent attackers who can perform downgrade attacks from also suppressing TLSRPT TXT record discovery and hiding the attack.
An attacker can flood the rua endpoint to prevent the receiving domain from accepting reports (DoS), leaving the domain blind to ongoing attacks. Attackers can also inject malicious content into reports to exploit vulnerabilities in report-handling systems.
TLSRPT allows report destinations outside the Policy Domain's authority, enabling an attacker controlling the Policy Domain DNS to direct reports to an unwitting victim as a DDoS amplifier. The risk is lower than DMARC because the attacker must induce the third party to send mail to the attacker first.
The 'date-range' fields use RFC 3339 Internet Date/Time Format strings. IP addresses use dot-decimal (IPv4, defined via ABNF dec-octet) or colon-hexadecimal (IPv6, per RFC 5952) string encoding.
The report filename ABNF is 'sender!policy-domain!begin-timestamp!end-timestamp[!unique-id].extension', where extension MUST be 'json' for plain JSON or 'json.gz' for gzip-compressed JSON.
The TLSRPT TXT record ABNF defines 'tlsrpt-record' as a version field followed by one or more semicolon-delimited fields; URIs within 'rua=' values must have commas (0x2C), exclamation points (0x21), and semicolons (0x3B) percent-encoded.