MTA-STS & TLS-RPTSMTP MTA Strict Transport Security & SMTP TLS Reporting
DMARC, SPF, and DKIM all answer "is this email really from who it claims to be from." MTA-STS and TLS-RPT answer a different question: "was this email actually encrypted on its way to me, or could someone on the network have read or altered it in transit?"
By default, SMTP's encryption (STARTTLS) can be silently downgraded by an attacker sitting on the network path — the two mail servers just fall back to sending in plaintext, with no warning to either side. MTA-STS closes that gap by making encryption a published, enforceable policy instead of an on-the-fly negotiation. TLS-RPT is its companion: a reporting channel that tells you when something failed.
How MTA-STS works
MTA-STS (RFC 8461) moves the "does this domain require TLS?" decision out of the SMTP conversation itself — which an attacker in the middle controls — and into a signed policy fetched over HTTPS before delivery is attempted. Setup has two parts: a TXT record at _mta-sts.yourdomain.com (v=STSv1; id=<a version string you bump on every policy change>) and a policy file hosted at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt declaring mode (testing, then enforce) and which mail server hostnames are valid.
How TLS-RPT works
TLS-RPT (RFC 8460) is DMARC's aggregate reporting, but for transport security instead of message authentication. A TXT record at _smtp._tls.yourdomain.com (v=TLSRPTv1; rua=mailto:[email protected]) tells other mail servers where to send daily JSON reports about TLS negotiation failures and MTA-STS policy violations they experienced sending to you — visibility you'd otherwise have zero way to get, since a downgrade to plaintext produces no error on either side.
Why testing mode exists
MTA-STS's mode=testing setting enforces nothing but generates TLS-RPT reports as if it were live — the safe way to confirm every legitimate mail server can actually reach you over TLS before switching to mode=enforce, which will refuse delivery attempts that don't meet the policy. Going straight to enforce without this step risks silently dropping mail from senders with older or misconfigured TLS.
How Trustliant handles this
Trustliant checks for MTA-STS and TLS-RPT DNS records on every scan, flags a missing MTA-STS policy or TLS-RPT reporting address as findings, and tracks both as part of DNS change monitoring across rescans. Fetching and validating the HTTPS policy file's contents, and ingesting the TLS-RPT JSON reports themselves the way Trustliant already ingests DMARC aggregate reports, are not built yet — today's checks confirm the DNS records exist and are well-formed, not the full end-to-end enforcement chain.
Questions we get about MTA-STS & TLS-RPT
- Do I need MTA-STS if I already have DMARC, SPF, and DKIM?
- Yes, if transport encryption matters to you — they solve different problems. DMARC/SPF/DKIM authenticate who sent a message; MTA-STS and TLS-RPT protect whether the message was actually encrypted in transit. A domain can have perfect DMARC alignment and still be vulnerable to a TLS downgrade attack without MTA-STS.
- Is MTA-STS required by any compliance framework?
- Not by name in the frameworks Trustliant tracks (PCI DSS 4.0, CIS Controls v8.1) — those name DMARC/SPF/DKIM specifically. MTA-STS is best understood as a best-practice hardening step rather than a named mandate today.