Definition
MTA Strict Transport Security (MTA-STS) is a protocol that enables a receiving domain to declare that sending MTAs must use TLS when delivering email to that domain. Without MTA-STS, an attacker can perform a downgrade attack by stripping TLS during SMTP negotiation, forcing the connection to use plain text. MTA-STS prevents this by publishing a policy that specifies which MX servers are authorised and that TLS is mandatory.
The policy is published in two places: a DNS TXT record at _mta-sts.example.com containing the policy ID, and an HTTPS-hosted JSON file at https://mta-sts.example.com/.well-known/mta-sts.txt. The JSON policy includes version, mode (testing, enforce, or none), a list of authorised MX hostnames, and a maximum age (max_age) that controls how long senders cache the policy before refreshing. The DNS record acts as a discovery mechanism pointing senders to the HTTPS endpoint where the full policy is fetched.
Best Practices
Start with mode: testing to evaluate your MTA-STS configuration without risk. In testing mode, sending MTAs apply the policy but do not enforce TLS failures; they report connection issues via TLSRPT. Review testing reports for at least one to two weeks before moving to enforce mode.
Ensure the HTTPS endpoint for your MTA-STS policy file returns a valid certificate and a 200 status code. The certificate must be valid for mta-sts.example.com. Sending MTAs that cannot fetch the policy fall back to the cached version if one exists, or to default behaviour if none is cached.
Set a reasonable max_age value. A duration of one to two weeks (864000 to 1728000 seconds) provides a good balance between caching benefits and the ability to update the policy quickly if your MX infrastructure changes. Longer max_age values mean senders will continue using an outdated policy for longer.
Keep the MX list in your MTA-STS policy synchronised with your actual MX records. If an MX server is removed from DNS but still listed in the policy, senders will attempt TLS connections to that server and may fail delivery when it is unavailable.
Deploy TLSRPT alongside MTA-STS. TLS reporting sends detailed failure reports to your monitoring infrastructure when TLS connections fail. Without TLSRPT, you have no visibility into connection problems that your MTA-STS policy might be causing.
Related Glossary Terms
Bounce Classification
Bounce classification uses SMTP codes (550, 551, 552, 553, 554, 450, 451, 452) and enhanced status codes to categorise permanent and transient delivery failures.
DMARC Alignment
DMARC identifier alignment determines whether the domain in the From header matches the domains used in SPF and DKIM authentication. Strict or relaxed.
Email Active Subscriber
An active email subscriber has opened or clicked an email within a defined recency period, typically 30-90 days by industry. Active subscriber rate of 40-60% is typical for healthy email lists.
Email Blacklist
An email blacklist (DNSBL) is a real-time database of IP addresses or domains known for sending spam or unwanted email.
Email Bounce
The return of an undelivered email to the sender, categorized as hard, soft, or transient with distinct handling rules for each.
Email Bulk
Bulk email classification distinguishes mass commercial messages from transactional emails, with specific authentication requirements for senders over 5,000 daily.
Frequently Asked Questions
MTA-STS prevents TLS downgrade attacks during email delivery. Without it, an attacker can intercept the SMTP STARTTLS negotiation and trick the sending server into sending email over an unencrypted connection. MTA-STS mandates that senders must use TLS to the authorised MX servers.
DANE (DNS-based Authentication of Named Entities) uses DNSSEC to publish TLS policy in DNS. MTA-STS uses a combination of DNS for discovery and HTTPS for policy delivery. DANE requires DNSSEC, which many domains do not have. MTA-STS works without DNSSEC and is more widely adopted by mailbox providers.
Each policy includes a `max_age` value. Sending MTAs cache the policy for this duration. When the policy expires, the sender re-checks the DNS record and re-fetches the HTTPS policy. If the HTTPS endpoint is unreachable during refresh, the sender uses default behaviour until the next refresh attempt.
Yes, MTA-STS functions without TLSRPT, but you lose visibility into connection failures. TLSRPT is the reporting component that sends aggregate reports about TLS connection successes and failures. Without it, you cannot distinguish between normal delivery and blocked TLS connections.
No. MTA-STS is supported by Google, Microsoft, Yahoo, and other major providers, but many smaller MTAs do not implement it. The protocol is defined in RFC 8461 and adoption is growing, but it is not yet universal. MTA-STS is optional; senders that do not support it fall back to standard SMTP delivery.