The problem: STARTTLS is opportunistic
Most email between servers is encrypted with STARTTLS, an SMTP extension that upgrades the connection from plaintext to TLS. However, STARTTLS has a fundamental flaw: it is opportunistic. If the TLS negotiation fails for any reason — an attacker blocking the STARTTLS command, an expired certificate, a configuration error — most sending servers proceed in plaintext, sending emails without encryption. An attacker positioned on the network (man-in-the-middle) can simply intercept the STARTTLS command and force the connection to plaintext, reading all emails in transit.
MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) solves this problem by allowing the recipient domain to declare: "emails for my domain must only be delivered over valid TLS connections." If the sending server supports MTA-STS and TLS negotiation fails, the email is not sent in plaintext — it is held and the sender is notified. This eliminates the possibility of downgrade attacks.
How MTA-STS works
MTA-STS requires two components: a DNS TXT record at _mta-sts.domain.com that signals the presence of the policy and includes a unique ID (typically a timestamp) that is updated with each change, and a policy file served via HTTPS at https://mta-sts.domain.com/.well-known/mta-sts.txt. The fact that the policy is served via HTTPS (not DNS) adds an extra layer of security: an attacker would also need to compromise the HTTPS certificate to forge the policy.
The policy specifies: the version (STSv1), the mode (testing or enforce), the hostnames of authorized mail servers (mx:), and the policy cache duration (max_age in seconds). The testing mode reports issues in TLS-RPT reports without blocking delivery, allowing you to identify and resolve problems before switching to enforce.
MTA-STS and TLS-RPT: the perfect pair
MTA-STS without TLS-RPT Lookup is like a security system without an alarm: it blocks problems but does not alert you. TLS-RPT (RFC 8460) provides detailed reports on TLS failures, allowing you to monitor how many TLS connections succeed, how many fail, and why. Always configure TLS-RPT alongside MTA-STS to have full visibility into the security of inbound email connections.
Our MTA-STS Lookup verifies both components: the DNS record and the HTTPS policy. It checks that the record exists and has a valid ID, that the policy file is reachable via HTTPS with a valid certificate, that the MX servers in the policy match the domain's actual MX records, and that the mode and max_age are configured correctly.
Step-by-step implementation
Implementing MTA-STS requires an HTTPS web server to serve the policy. If you already have a website for the domain, you can create an mta-sts.yourdomain.com subdomain with a valid SSL certificate. Alternatively, services like Cloudflare Workers or GitHub Pages can host the policy file for free. The HTTPS certificate must be valid and issued by a public CA — self-signed certificates are not accepted.
Start with mode: testing to collect data without impacting delivery. Monitor TLS-RPT reports for at least 2 weeks. Verify that your certificate SSL Check is valid and that your MX servers support TLS 1.2+. Once you confirm there are no issues, switch to mode: enforce. Update the ID in the DNS record with every policy change to force cache refresh on sending servers.