Security

MTA-STS and TLS-RPT: Audit the Transport Layer, Not Just SPF and DMARC

How transport policy and TLS reporting complement sender authentication.

8 minUpdated 2026-08-17

Authentication and transport security solve different problems

SPF, DKIM and DMARC help receivers reason about sender identity. MTA-STS and TLS-RPT address transport between mail systems. A domain can have excellent DMARC and still lack a policy that tells supporting senders how its MX hosts should be reached over TLS.

MTA-STS has both DNS and HTTPS state

The DNS TXT record under _mta-sts advertises a policy identifier, while the actual policy is retrieved from a standardized HTTPS location on mta-sts.<domain>. A useful checker validates both pieces. Seeing only the TXT record is not enough to prove that the policy file is reachable or meaningful.

TLS-RPT closes the visibility gap

TLS-RPT publishes a reporting destination for transport-security failure summaries. That gives operators evidence about failed TLS negotiation or policy validation that ordinary application logs may not show. It is particularly useful when tightening transport policy because failure reports can reveal destinations or certificate conditions that need attention.

Audit them together

Check MTA-STS policy mode, allowed MX patterns, max age and HTTPS reachability together with the TLS-RPT record. Then compare those controls with the actual MX records. Transport policy is useful only when it accurately describes the infrastructure receiving the mail.

Verify the evidence

Use the live analysis that matches this workflow instead of relying on a generic status check.

Primary references