Skip to content

TLS-RPT #315

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
gunnim wants to merge 1 commit into
base: develop
Choose a base branch
from
Draft

TLS-RPT #315

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 34 additions & 1 deletion docs/pages/infrastructure/domain-and-dns-security/dnssec-and-email.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -180,7 +180,7 @@ MTA-STS enforces encrypted connections between mail servers, preventing man-in-t

4) **Testing and enforcement**
- Start with `mode: testing` to monitor without blocking
- Collect and review TLS failure reports
- Collect and review TLS failure reports using TLS-RPT (See dedicated section below)
- Once confident, change to `mode: enforce`
- Update the `id` in DNS TXT record after policy changes

Expand All @@ -194,6 +194,39 @@ MTA-STS enforces encrypted connections between mail servers, preventing man-in-t
- All MX servers must support TLS with valid certificates
- Monitor policy file availability - if unreachable, mail delivery may fail in enforce mode

#### TLS-RPT
Copy link
Collaborator

@Raiders0786 Raiders0786 Dec 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey, solid work on this @gunnim!

The MTA-STS → TLS-RPT flow is accurate, and I especially like the RFC8460 citation addressing the report delivery concern.

Quick notes:

  1. Should we also consider adding a note about max_age tuning during testing vs. production?
  2. Might be worth mentioning MX record alignment with policy
  3. The example could clarify that fallback only happens in testing mode, as if deployed on enforce mode = hard fail

Optional but nice to have: verification commands (dig, curl) and mention of report parsing tools since
TLS-RPT comes as JSON.

Overall, this is useful and technically correct - it just needs minor polish.
Good stuff, thanks for the contributions 👍


TLS-RPT collects delivery reports for messages transmitted using MTA-STS and SMTP DANE.

Most major providers (Google, Microsoft, etc.) send one aggregated report per day per domain summarizing all failures for that day and some also indicate how many transmissions were successful.
This is crucial for already established projects to ensure current email communication is not broken when enabling these security features.

**Example**
MTA-STS is deployed in "testing" mode
TLS-RPT is configured for domain example.com
An email provider attempts to deliver mail to example.com
It fetches example.com's MTA-STS policy and attempts delivery using TLS according to the policy
The failure is logged and reported using TLS-RPT
Provider finishes mail delivery by falling back to classic SMTP

**Setup**
Create a new DNS TXT record with the following structure and chosen email address to receive the reports
_smtp._tls.yourdomain.com. TXT "v=TLSRPTv1; rua=mailto:reports@yourdomain.com"

This will give you visibility into failures during testing.

##### Report receiver in same email domain
It is perfectly reasonable for the report receivers email address to reside in the same domain that is using MTA-STS or SMTP DANE even after those security features have been fully enabled.

See the following snippet from [RFC8460](https://www.rfc-editor.org/rfc/rfc8460) which defines TLS-RPT

*In the case of "mailto", reports should be submitted to the
specified email address [RFC6068]. When sending failure reports
via SMTP, Sending MTAs MUST deliver reports despite any TLS-
related failures and SHOULD NOT include this SMTP session in the
next report. This may mean that the reports are delivered
unencrypted.*

### DMARC (Domain-based Message Authentication)

DMARC builds on SPF and DKIM to provide policy enforcement for email authentication. It tells receiving mail servers what to do with emails that fail authentication checks.
Expand Down