What is MTA-STS? SMTP Security Policy Explained

MTA-STS (Mail Transfer Agent Strict Transport Security) is an email security standard that forces mail sent to your domain to travel over an encrypted, authenticated TLS connection between mail servers (MTAs). Defined in RFC 8461, it closes a long-standing weakness in SMTP: by default, TLS on server-to-server mail is opportunistic, so an attacker who can intercept the connection can strip encryption or redirect mail without either side noticing. MTA-STS lets a domain owner publish a policy that says "always use TLS to reach me, and verify my certificate" — turning best-effort encryption into a firm requirement.

How does MTA-STS work?

MTA-STS works by publishing a policy that sending servers discover and cache before they deliver mail to you:

How a sending server discovers and enforces an MTA-STS policy.

• Policy publication. You host a policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. It lists the enforcement mode (enforce, testing, or none), the authorised mail servers (matching your MX records), and a max_age cache lifetime.
• DNS record. A DNS TXT record at _mta-sts.yourdomain.com advertises that your domain supports MTA-STS and signals when the policy changes, for example v=STSv1; id=20260716T000000;.
• Policy discovery. Before delivering, a supporting sending server checks that TXT record. If the id has changed since it last looked, it fetches the current policy file over HTTPS.
• Secure delivery. In enforce mode, the sender must open a TLS connection and validate the receiving server's certificate against a trusted CA and your MX host names. If TLS is unavailable or the certificate fails validation, the message is not delivered rather than falling back to plaintext.
• Caching. Senders cache the policy for the max_age period, so they keep enforcing it even if an attacker later blocks the DNS or policy lookup.

MTA-STS works alongside SPF, DKIM, and DMARC to form a complete email security framework — those three authenticate who sent a message, while MTA-STS protects the channel the message travels over.

MTA-STS and TLS-RPT

MTA-STS is almost always deployed with its companion standard, TLS Reporting (TLS-RPT, RFC 8460). You publish a second TXT record at _smtp._tls.yourdomain.com naming a reporting address, and supporting senders then email you daily JSON summaries of their TLS connections — including any that failed. Without TLS-RPT, a broken certificate or a downgrade attempt could quietly block your mail; with it, you get the visibility to catch problems before they turn into lost email.

Why MTA-STS matters

• Prevents eavesdropping. By mandating TLS, it keeps message content encrypted in transit, out of reach of passive interception.
• Blocks downgrade attacks. It stops an attacker from forcing a plaintext connection by tampering with the STARTTLS handshake — a classic man-in-the-middle technique against SMTP.
• Enforces certificate validation. Mail is only delivered to servers presenting a valid certificate for your MX host names, reducing the risk of redirection to an attacker's server.
• Supports compliance. For regulated industries like healthcare and finance, enforced transport encryption helps satisfy requirements for protecting data in transit.

Things to keep in mind

Rolling MTA-STS out carelessly can block legitimate mail, so setup matters:

Key setup and maintenance points for a smooth MTA-STS rollout.

• TLS support. Confirm your mail servers support modern TLS (1.2 or 1.3) and hold valid, trusted certificates that match your MX host names.
• Start in testing mode. testing mode reports failures via TLS-RPT without blocking mail. Move to enforce only after reports confirm every sender can reach you over valid TLS.
• HTTPS hosting. The policy file must sit on an HTTPS server with a valid certificate for the mta-sts subdomain — an expired certificate there can break policy fetches.
• Adoption is partial. Major providers including Gmail and Microsoft 365 honour MTA-STS, but not every sender does; it protects mail from those that do and is ignored (safely) by those that don't.
• Maintenance. Update the policy id every time you change the file, and keep an eye on TLS-RPT reports so you notice certificate expiry or new senders having trouble.

You can confirm what a domain currently publishes with the MTA-STS checker, and see how transport security fits alongside your authentication records with the Email Security Score.

Related reading

• What is an MX record?
• What is SPF?
• What is spoofing?