Separate the request to receive reports from transport protection
TLS-RPT asks sending systems to report SMTP TLS observations. It does not itself require encrypted delivery or repair an MTA-STS or DANE configuration. A checker should first explain whether the reporting request is discoverable and parseable, then separately explain whether a destination can accept reports and what any received report actually establishes.
This article is a proposed checker guide, not an implemented EmailAuth capability. No domain, mailbox, report endpoint or message was tested. The exact working-tool requirement remains open: Implement and test the promised function. An article, mock-up or specification alone is not a working tool.
Validate the discovery record at the right owner
For a policy domain, RFC 8460 places the request at _smtp._tls followed by that domain. Retain the queried owner, TXT record boundaries, response status and collection time. A proposed checker should distinguish failed collection from confirmed absence. Filtering the returned records for the supported TLSRPT version must leave exactly one usable record; multiple strings inside that one record are concatenated without spaces.
Parse the required v=TLSRPTv1 and rua information according to the specification, including its URI escaping rules. RFC 8460 supports mailto and https report destinations. Do not paste DMARC-specific external-destination authorization syntax into TLS-RPT merely because both protocols use a rua field. Validate the actual protocol and endpoint contract. RFC 8460, section 3.
Distinguish endpoint syntax from operational acceptance
A syntactically valid address does not prove that the mailbox exists, accepts the report size or runs a compatible processor. Likewise, an HTTPS destination that serves a webpage does not prove it accepts the specified report POST. Record the endpoint owner, supported transport, import format and separately approved acceptance evidence. Do not send a test report or disclose customer material just to turn a status indicator green.
Report delivery has special transport semantics. RFC 8460 allows HTTPS submitters to ignore certificate-validation errors, and requires SMTP reporting to proceed despite TLS-related failures, potentially without encryption. Those protocol allowances are not permission for this checker to bypass certificate warnings or transmit sensitive data insecurely. A deployment must explicitly review the confidentiality consequences and its own security policy before choosing or testing a destination.
Apply the SMTP reporting signature requirements precisely
Reports carried by SMTP must have a valid DKIM signature from the reporting domain; the recipient must ignore reports lacking it. RFC 8460 section 3 also prohibits the DKIM l= body-length attribute for these signatures. A generic DKIM pass is insufficient if the reporting signature relies on l=, because the requirement protects against appended misleading report content.
The public-key record should declare the tlsrpt service type, and the recipient may ignore a report if that declaration is absent. Preserve which signing domain, selector and signature support the report's acceptance decision. These SMTP-specific requirements must not be described as a DKIM-signature requirement for an HTTPS POST. RFC 8460, section 3.
Parse the report with explicit import limits
TLS-RPT reports use I-JSON, with metadata, a reporting interval and a policies array. Email transport uses the prescribed report MIME structure; gzip compression is supported and recommended by the specification. Treat both compressed and plain input as untrusted. Bound incoming and expanded size, processing time, memory, nesting and policy or failure-entry counts before importing records into analysis.
Use an I-JSON-aware validation path, including rejection of duplicate object member names, rather than trusting whichever value a permissive JSON library retains. Preserve raw input provenance and parser version, and quarantine unsupported or malformed reports without labelling them domain transport failures. No import limits or parser have been implemented here. RFC 8460, sections 4–5, RFC 7493 and OWASP file-upload guidance.
Interpret the observation and its denominator
Link each finding to the reporting organization, policy domain, policy type, interval, receiving host and relevant failure details. An sts-policy-fetch-error concerns retrieving an MTA-STS policy; a certificate-host-mismatch concerns certificate identity validation. Neither label alone identifies the exact repair. Correlate the report's time and context with separately authorized endpoint, policy or MX evidence before selecting a change.
Counts describe sessions, not necessarily individual messages. Failure categories can overlap for the same attempt, and a report can contain multiple applied policies. Adding every failure-detail count into a unique-message total can therefore exaggerate the affected population. Preserve the summary and detail semantics instead of flattening them into one universal failure rate. RFC 8460, sections 4.2–4.3.
An absent report does not establish that transport succeeded. The sender may not participate, the reporting path may fail or the local processor may reject the input. Conversely, a successful session count indicates a policy-compliant TLS connection for the reporting system's observation, not final inbox delivery or message authentication. Keep collection health and transport findings in separate output fields.
Require a demonstrated problem before claiming a fix
In a fictional diagnostic plan, repeated policy-fetch errors would lead the owner to compare the reported interval with policy-host availability and certificate evidence. The tool should preserve alternative explanations until a cause is confirmed. It must not automatically replace the reporting destination, relax enforcement or publish a new policy.
The exact original-evidence gate is: A redacted TLS-RPT JSON example linked to a confirmed endpoint or policy problem. No actual report or confirmed incident has been supplied. References were reviewed on 8 November 2026. The proposed workflow still needs a tested implementation, secure-import fixtures, independent and human technical review, visual checks and owner publication authorization.