[ Transport security ]
TLS-RPT reporting destinations and report delivery
Define approved mailto or HTTPS collection paths, report integrity, timing and processing responsibilities without assuming guaranteed duplicate delivery.
By the EmailAuth research team · 8 min read
[ Key points ]
- TLS-RPT collection and transport enforcement are separate dependencies.
- Multiple rua destinations do not guarantee a copy at every endpoint.
- Verify receipt, integrity, parsing and attribution as distinct stages.
[ Takeaway ]
Treat the reporting destination as an owned service contract with approved data sharing and observable delivery-to-processing stages.
[ By role ]
What this means for you
Choose your role for practical next steps.
IT / Mail Admin
Trace the report through collection
Endpoint acceptance is not the same as successful parsing.
Next steps
- Verify the exact reporting record and supported URIs.
- Preserve report identifiers through ingestion.
- Check compression, integrity and attribution separately.
CISO / SecOps
Approve and protect the reporting channel
Reports carry operational metadata and untrusted content.
Next steps
- Approve third-party recipients and retention.
- Preserve required SMTP report-signature checks.
- Avoid assuming report transport is always encrypted.
Founder / Non-technical
Assign collection accountability
Publishing a destination does not make someone responsible for acting on failures.
Next steps
- Name the collector and incident owner.
- Define the archive and dashboard relationship.
- Set realistic participation and timing expectations.
[ FAQs ]
Frequently asked questions
Where is the TLS-RPT record published?
At _smtp._tls under the policy domain, using TXT with version TLSRPTv1 and rua destinations. This is separate from the MTA-STS policy file.
Which destination schemes does RFC 8460 support?
The supported schemes are mailto and https. HTTPS reports use POST; mailto reports use the specified mailbox delivery path.
Does an external destination require a DMARC-style authorization record?
RFC 8460 does not define that DMARC-style DNS handshake. Confirm organizational approval and any collector-specific onboarding separately; do not invent a protocol record.
Will two rua URIs each receive every report?
Not necessarily. A reporter may attempt multiple supported destinations or choose one. Successful acceptance at one endpoint can satisfy delivery.
What integrity check applies to SMTP reports?
They require a valid reporting-domain DKIM signature without l=. The key should declare s=tlsrpt; a receiver may ignore reports lacking that service declaration.
Does HTTPS acknowledgment prove processing succeeded?
No. A successful response acknowledges delivery, and the collector may process later. Track queue, parser and attribution outcomes separately.
Are daily reports guaranteed?
No. A full UTC-day interval and delayed delivery are recommended, but reports are optional and no universal daily receipt promise follows.
What happens if two valid TLS-RPT policy records are published?
After discarding TXT resource records that do not begin with the literal prefix "v=TLSRPTv1;", the sender must find exactly one remaining record. If it finds zero or more than one, RFC 8460 requires it to assume TLS-RPT is not implemented. Record boundaries matter: multiple strings within one TXT record do not by themselves mean multiple policy records.
[ Sources ]
Sources
- RFC 8460
Sections §3. Reporting Policy · §4.1 Report Time Frame · §4.3 Result Types · §5.2 Compression · §5.3 Email Transport · §5.4 HTTPS Transport · §5.5 Delivery Retry · §5.6 Metadata Variances · §7. Security Considerations
[ Glossary ]
Glossary
- Report acceptance
- The destination’s successful receipt acknowledgment, distinct from later processing.
- Collector contract
- The proposed agreement covering destination ownership, data handling and processing evidence.
Enterprise provenance
Why top financial institutions and governments retired their email security dashboards.
Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.
EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.
SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption