MTA-STS & TLS-RPT Email Security Inspector
Inspect RFC 8461 Mail Transfer Agent Strict Transport Security and RFC 8460 SMTP TLS Reporting. Audit DNS TXT discovery records, HTTPS policy configurations, and generate hardened mail transport policies.
🛠️ MTA-STS & TLS-RPT Policy Generator
Frequently Asked Questions
What is MTA-STS and why is it necessary for inbound email security?
Mail Transfer Agent Strict Transport Security (MTA-STS, RFC 8461) enables domain owners to declare that incoming emails must be delivered over encrypted TLS connections with valid certificates. Without MTA-STS, opportunistic STARTTLS is vulnerable to man-in-the-middle downgrade attacks where adversaries strip encryption in transit.
How do the DNS TXT record and the HTTPS policy file work together?
A domain publishes a DNS TXT record at _mta-sts.yourdomain.com containing a version tag and policy ID (e.g., v=STSv1; id=20261001). Sending mail servers read this record and then fetch the full policy document over HTTPS from https://mta-sts.yourdomain.com/.well-known/mta-sts.txt, which defines the mode, MX hosts, and max cache age.
What is the difference between testing mode and enforce mode in MTA-STS?
In testing mode, sending mail servers that encounter TLS negotiation failures still deliver the message over plaintext, but report the failure via TLS-RPT. In enforce mode, messages that fail TLS verification are strictly rejected, preventing unencrypted eavesdropping.
What is TLS-RPT (RFC 8460) and how should it be configured?
SMTP TLS Reporting (TLS-RPT) enables sending servers to dispatch daily JSON telemetry reports regarding TLS connection failures. It is configured via a TXT record at _smtp._tls.yourdomain.com specifying destination mailboxes or HTTPS endpoints (e.g., rua=mailto:[email protected]).