MTA-STS and TLS-RPT

Everything so far in this course – SPF, DKIM, DMARC – authenticates who is allowed to send as a domain. MTA-STS and TLS-RPT protect something entirely different: whether the mail was actually encrypted while it traveled, regardless of who sent it.

The threat: STARTTLS downgrade

SMTP's opportunistic encryption (STARTTLS) has a well-known weakness – a network attacker positioned in the path can strip the STARTTLS offer before the receiving server sees it, forcing the connection to fall back to plaintext. Neither side necessarily notices; the mail still arrives, just readable in transit.

MTA-STS closes that gap

MTA-STS (Mail Transfer Agent Strict Transport Security) publishes a policy telling sending servers "always use TLS to reach my mail servers, and here's exactly which hostnames are valid – if you can't get a secure connection, don't downgrade, just fail." It requires two things published together:

_mta-sts.example.com   TXT   "v=STSv1; id=20260101000000Z"

...plus an HTTPS-hosted policy file at a well-known URL (https://mta-sts.example.com/.well-known/mta-sts.txt) listing the actual policy mode and valid mail server hostnames.

TLS-RPT is the reporting half

Just like DMARC's rua tag gives you visibility into authentication failures, TLS-RPT gives you visibility into TLS negotiation failures – a separate DNS TXT record telling other mail providers where to send daily reports on any connection that couldn't establish the expected encrypted session.

_smtp._tls.example.com   TXT   "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Neither of these appears in a DMARC aggregate report – they're a genuinely separate check, worth adding to a client's rollout plan alongside authentication, not instead of it. Check a domain's current MTA-STS posture with ActiScan's MTA-STS checker.