You want visibility into failed opportunistic TLS connections to your mail server — the encryption-in-transit half of email security that DMARC doesn't cover — but aren't sure what DNS record actually enables it.
TLS-RPT (RFC 8460) is a separate reporting mechanism from DMARC: it reports on STARTTLS/TLS negotiation failures between mail servers, not on DKIM/SPF/DMARC authentication. It's enabled by publishing a TXT record at _smtp._tls.<yourdomain> with the value v=TLSRPTv1; rua=mailto:you@yourdomain (or an HTTPS rua endpoint). The single most common setup mistake is writing _smtp-tls (hyphen) instead of _smtp._tls (dot) — a typo that silently means no sending mail server will ever find your record, with zero error and zero reports. Source: RFC 8460 §3 “The _smtp._tls TXT Record” · verified 2026-07-17.
_smtp._tls.yourdomain.com with v=TLSRPTv1; rua=mailto:you@yourdomain (or your monitoring tool's rua address)._smtp._tls — two labels separated by a dot, not a hyphen._dmarc record.No. DMARC authenticates who is allowed to send as your domain; TLS-RPT and MTA-STS protect how mail travels in transit between servers. They're complementary, independent DNS records — not substitutes for each other.
They work well together but are independent: TLS-RPT is reporting-only (you find out about failures), MTA-STS is enforcement (failing connections get blocked in enforce mode). Most domains set up TLS-RPT first to see what's actually happening before committing to MTA-STS enforce mode.
TLS-RPT can't break anything — it's report-only. MTA-STS in enforce mode can, if your policy file lists the wrong MX hosts or your mta-sts. subdomain's certificate is invalid — which is exactly why RFC 8461 and every practical guide recommend a testing-mode period first.