TLS-RPT record generator: how do you build the _smtp._tls TXT record?
How does this check work, and what does the result tell you?
AdminKit's TLS-RPT record generator builds the exact v=TLSRPTv1 TXT record for _smtp._tls.<your domain> from the mailto: or https: report destinations you list, entirely in your browser, with nothing sent to any server. You still have to publish the record yourself, then confirm it with AdminKit's live TLS-RPT check.
Part of the Email authentication cluster — more tools, guides and terms on email authentication.
One per line or comma-separated — each must start with mailto: or https:, e.g. mailto:[email protected] or https://reports.example.com/tlsrpt.
- Publish this value as a TXT record at _smtp._tls.<your domain> — not at the bare domain.
This is built in your browser only — nothing here is sent to AdminKit or anywhere else. Publish the TXT record at _smtp._tls.<your domain>, then confirm it with the live TLS-RPT check.
What the result means
This is the TXT record text built from the rua destinations you entered — it says nothing about what your domain currently publishes. To see what is actually live today, run AdminKit's TLS-RPT check.
Next step
Publish the TXT record above at _smtp._tls.<your domain>, then confirm it with the live
TLS-RPT check once DNS
has propagated. TLS-RPT is independent of MTA-STS —
each is its own DNS record — but the two are almost always deployed together: MTA-STS can enforce TLS, and
TLS-RPT is the only channel that reports back when that enforcement actually blocks something.
Keep this result
Copy a link to this check so you can share it or run it again later. Want a heads-up if something changes? That's early access, not a live feature yet — tell us and we'll set it up by hand.
How it works and limits
Add one or more rua report destinations below, and this tool assembles the v=TLSRPTv1 TXT record as you type,
entirely in your browser — nothing you enter is sent to AdminKit or anywhere else. Once you are happy with the
result, publish it yourself at _smtp._tls.<your domain>, then confirm it took effect with AdminKit’s live
TLS-RPT check, which queries DNS for real and reports back what it actually found.
Where does the record this tool builds actually need to live?
RFC 8460 §3 fixes the lookup name a sending server performs after it hits
a TLS failure (a certificate problem, a failed STARTTLS negotiation, or a delivery blocked by the receiving domain’s
own MTA-STS policy) at _smtp._tls.<domain> — not the bare domain, and not any other
subdomain. The TXT value itself starts with v=TLSRPTv1 to identify the record, followed by an rua tag listing
where to send the resulting JSON report:
_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:[email protected]"What can the rua destinations point to?
RFC 8460 §3’s own worked examples, on the IETF
Datatracker’s canonical copy of the RFC, use exactly two URI schemes for rua: a mailto: address, which receives
the report as an email attachment, and an https: endpoint, which receives it as an HTTPS POST. This tool
validates every destination you add against those two schemes and rejects anything else — a bare email address
with no mailto: prefix, or a plain http:// URL — since a sending server parsing the record has no other way to
know where the report should go. You can list more than one destination; RFC 8460 §3 treats rua as a
comma-separated list, and this tool joins them the same way.
Limits
- This tool only builds the TXT record text. It never queries DNS and never publishes anything — you still have to add the record yourself, then confirm it with a live check.
- It validates the scheme and basic shape of each destination you enter but has no way to know whether a
mailto:inbox exists or anhttps:endpoint is actually listening — only that the value is syntactically a report destination RFC 8460 recognizes.
TLS-RPT is almost always deployed alongside MTA-STS rather than on its own — the two are independent records (TLS-RPT is RFC 8460, MTA-STS is RFC 8461), but MTA-STS without TLS-RPT means a misconfigured policy can silently block legitimate mail with no way for the domain owner to find out. See how to publish and test MTA-STS for the full rollout path, and once your record is live, confirm it with AdminKit’s TLS-RPT check and check your domain’s MTA-STS status next, since the two protect different parts of the same mail flow — MTA-STS can enforce TLS, TLS-RPT only reports on it.
Frequently asked questions
Does this tool send anything to AdminKit's servers?
No — every destination you type is read directly by your browser, and the v=TLSRPTv1 TXT record string is built there with plain JavaScript. Nothing you type is sent to AdminKit or anywhere else. That also means it cannot check what your domain currently publishes; for that, use AdminKit's live TLS-RPT check, which does query DNS for the real _smtp._tls record.
What can the 'rua' value actually point to?
RFC 8460 §3 defines rua as a comma-separated list of URIs, and its own worked examples use only two schemes: mailto: for an inbox that receives the JSON report as an email attachment, and https: for an HTTPS endpoint that receives it as a POST. This tool rejects anything else — a bare email address without mailto:, or a plain http:// URL — because a receiving server has no other way to know where to deliver the report.
Where does this TXT record actually get published?
At _smtp._tls.<your domain>, not at the bare domain and not at a www subdomain — RFC 8460 §3 fixes that exact name as the lookup a sending server performs after a TLS failure. Publishing the value anywhere else means no sending server will ever find it, even though the record text itself would be perfectly valid.
I already set up MTA-STS — do I still need TLS-RPT too?
Yes — the two are independent DNS records defined in separate RFCs (TLS-RPT is RFC 8460, MTA-STS is RFC 8461) and neither one implies the other is published. MTA-STS can tell senders to enforce TLS, but without TLS-RPT there is no channel for a sender to report back when that enforcement actually blocks a message, so a misconfigured MTA-STS policy can silently drop mail with no visibility at all.
What happens if I generate a record with no rua destination?
RFC 8460 §3's grammar technically allows a bare v=TLSRPTv1 record with no rua tag, and AdminKit's own TLS-RPT check reports that exact state as published, but no rua destination rather than treating it as broken — this tool will still build that record for you, but it warns that no sending server will have anywhere to actually deliver a report, since an rua destination is the entire point of publishing TLS-RPT.