Email & DNS
TLS-RPT setup: receive reports about mail transport security failures
SMTP TLS reporting (TLS-RPT) gives a domain aggregate reports about transport-security success and failure seen by participating senders. It is most useful alongside MTA-STS or DANE planning because it can show certificate, negotiation, and policy failures that are hard to infer from mailbox delivery alone.
Choose a report destination you will actually process
Publish a _smtp._tls TXT record containing v=TLSRPTv1 and a rua destination supported by your reporting workflow. If reports go to an external domain, follow any authorization rules required by the specification/provider.
Protect the mailbox or endpoint from becoming an ignored dump. Reports only help if someone reviews trends.
Baseline before enforcement changes
Collect reports while current mail routing is stable. Identify receiving MX hosts, successful session counts, and recurring failure reasons such as certificate mismatch, expired certificates, DNS errors, or negotiation failures.
Correlate with mail-server logs because aggregate reports may not contain enough detail for one incident.
Use failures to test policy readiness
Before tightening MTA-STS, verify each MX has the expected certificate identity and supported TLS behavior. A recurring policy failure is evidence to fix the receiving path, not a reason to suppress the report.
Watch for providers still attempting retired MX hosts after DNS changes due to caching/retries.
Retain comparable periods
Compare report volume and failure categories before and after certificate, MX, or policy changes. One quiet day is not enough to establish that every sender path is healthy.
- Publish a monitored rua destination.
- Baseline current TLS health.
- Correlate reports with SMTP logs.
- Compare before/after policy changes.