MTA-STS Lookup & Policy Generator

What Is MTA-STS and Why Does It Matter?

SMTP Mail Transfer Agent Strict Transport Security (MTA-STS, published in RFC 8461) is an internet security standard designed to secure email communication across mail servers. By default, traditional SMTP connections rely on opportunistic TLS via the STARTTLS command. Because opportunistic encryption does not authenticate server identity or mandate encryption, an attacker positioned along the network route can strip the STARTTLS negotiation, forcing servers to exchange messages in plain cleartext.

MTA-STS closes this vulnerability by allowing domain owners to declare that receiving mail transfer agents (MTAs) must use modern TLS encryption with trusted certificates matching authorised mail servers.

How MTA-STS Works: The Three Pillars

A complete MTA-STS deployment relies on three coordinating components:

• 1. DNS Discovery Record (_mta-sts TXT): A DNS record informing sending mail servers that an MTA-STS policy exists and providing a policy version identifier (such as a timestamp or hash). When domain owners update their policy file, incrementing this ID instructs senders to refresh their cached copy.
• 2. HTTPS Policy File (mta-sts.txt): A static text file hosted over HTTPS at https://mta-sts.[domain]/.well-known/mta-sts.txt. Because it is delivered over HTTPS with a valid certificate from a trusted public certificate authority, senders can retrieve the policy securely without risk of DNS spoofing.
• 3. Mail Exchange (MX) Host Alignment: The policy file explicitly declares which mail server hostnames (e.g. mx: mail.example.com or mx: *.google.com) are authorised to receive email for the domain. Senders verify the recipient server's TLS certificate against these hostnames during the handshake.

What Is TLSRPT (RFC 8460)?

SMTP TLS Reporting (TLSRPT) is the operational telemetry companion to MTA-STS. By publishing a TXT record at _smtp._tls.[domain], domain owners designate an aggregate mailbox (such as rua=mailto:tls-reports@domain.com). Sending providers (including Google, Yahoo, and Comcast) transmit daily reports summarising successful TLS sessions and highlighting handshake failures, certificate mismatches, or network interception attempts.

Safe Rollout Lifecycle: From Testing to Enforcement

When adopting MTA-STS, adopting a staged implementation prevents accidental mail delivery disruption:

• Phase 1: Testing Mode: Deploy your policy with mode: testing and a short cache duration (e.g. max_age: 86400). In testing mode, sending MTAs will still deliver messages if TLS negotiation encounters an issue, but will report any failures via TLSRPT.
• Phase 2: Review Telemetry: Monitor incoming TLSRPT reports to verify that all legitimate mail servers present valid, unexpired certificates with matching hostnames.
• Phase 3: Enforce Mode: Once zero TLS negotiation errors are reported, update the policy to mode: enforce and increase max_age to 604800 (1 week) or 2592000 (1 month). Sending MTAs will now strictly reject cleartext transmission and protect your organisation against interception.