What Is MTA-STS? Enforced TLS for Inbound Email Explained

So what is MTA-STS? MTA-STS — SMTP MTA Strict Transport Security — is the standard defined in RFC 8461 that lets your domain publish a rule: any server sending mail to you must use TLS, and that connection must be authenticated with a valid certificate. If a sender cannot meet the rule, it refuses to deliver rather than fall back to an unencrypted connection.

The problem it solves is specific. Server-to-server email runs on SMTP, which encrypts opportunistically through a command called STARTTLS. Opportunistic means optional: if the encrypted handshake does not happen, most servers just send the message in plaintext. An attacker positioned between two mail servers can force that by stripping the STARTTLS offer, and neither side notices the downgrade.

MTA-STS removes that silent fallback. It gives a receiving domain a way to say — in a place an attacker cannot quietly rewrite — that a downgrade is not acceptable. This guide covers the three moving parts (a DNS record, an HTTPS-hosted policy file, and the none / testing / enforce modes) plus the deployment order most vendor write-ups skip.

How does MTA-STS work?#

MTA-STS has three parts: a DNS record that advertises a policy exists, an HTTPS-served file that spells the policy out, and a caching model that tells senders how long to trust it. A sending server that supports MTA-STS runs the same sequence before delivery.

1. 1

   Check the DNS TXT record

   The sender looks up a TXT record at _mta-sts.<your-domain>. It carries two fields, v=STSv1 and an id string. The id is a version tag: change your policy, change the id, and senders know to re-fetch.

2. 2

   Fetch the policy over HTTPS

   If the id is new, or nothing is cached, the sender requests https://mta-sts.<your-domain>/.well-known/mta-sts.txt. It must be served over HTTPS with a certificate valid for that host and return HTTP 200. Per RFC 8461, senders must not follow a redirect to it.

3. 3

   Validate the receiving server

   Before delivering, the sender checks that the receiving MX host matches an mx pattern in the policy and that its certificate chains to a trusted authority. STARTTLS has to be offered and succeed.

4. 4

   Apply the mode, then cache

   The mode field decides what happens on a failure. The sender then caches the policy for up to max_age seconds, so it does not re-fetch on every message.

What goes in the mta-sts.txt policy file?#

The policy file is plain text, one key-value pair per line. Four fields carry the whole policy. Here is a complete example for a domain served by two MX hosts.

Why MTA-STS matters: what breaks without it#

Without MTA-STS, TLS between mail servers is opportunistic, so it is optional. If the encrypted handshake is disrupted, the message goes out in plaintext instead of failing — convenient for delivery, useless for security, because an on-path attacker can quietly turn encryption off.

The concrete attack is STARTTLS stripping. An attacker between two servers removes the STARTTLS offer, both sides fall back to plaintext, and the mail — password resets, invoices, contracts — crosses the wire in the clear. A related attack spoofs the MX record to route mail through a server the attacker controls. Enforce mode blocks both, because it requires a matching MX and a valid certificate before any message is handed over.

One limit is worth stating plainly: MTA-STS protects a sender that has already cached your policy. On the very first contact, before any policy is cached, there is a window an attacker could exploit. The protection is strong, but not first-contact-proof — DANE, below, closes that gap differently.

The three modes, and why testing comes before enforce#

The mode field is where rollouts go wrong, because the tempting move — publish enforce and be done — is the one that can silently drop legitimate mail. The three modes are a deployment path, not three equal options.

• none — an explicit opt-out. Senders treat your domain as though it has no active policy. It mainly lets you wind a policy down cleanly.
• testing — senders fetch and evaluate the policy but do not block on failure. If they support TLS reporting, they send you a report of what would have failed. Mail keeps flowing.
• enforce — senders must not deliver to an MX host that fails MX matching, fails certificate validation, or does not support STARTTLS. This is the mode that actually protects you.

MTA-STS vs DANE: what's the difference?#

MTA-STS and DANE for SMTP (RFC 7672) solve the same problem — stopping TLS downgrade between mail servers — but rest on different trust anchors. MTA-STS uses public certificate authorities and an HTTPS-hosted policy. DANE uses DNSSEC-signed records and needs no public CA.

Neither standard obsoletes the other, and some domains publish both. DANE needs DNSSEC, which many domains and registrars still do not deploy; MTA-STS works with the public CA system every domain already uses, which is why large mailbox providers adopted it widely. If you already run DNSSEC, running both adds first-contact protection on top of a familiar policy.

Common misconceptions about MTA-STS#

MTA-STS sits next to several other email standards, and the overlap breeds confusion.

• It does not encrypt your email end to end. It secures the server-to-server hop, and only on mail arriving at a domain that publishes a policy. The message is still readable on each server it passes through, unlike PGP or S/MIME.
• It does not replace SPF, DKIM, or DMARC. Those authenticate who sent a message; MTA-STS secures how the message travels. Different jobs — you want both.
• Enforce is not the safe way to start. Publishing enforce before testing can silently block real mail from a misconfigured MX or a certificate problem. Start in testing.
• It is not set-and-forget. A lapsed certificate on mta-sts.<your-domain>, or an MX change you forget to reflect, can make senders refuse your inbound mail. TLS-RPT is what catches that.
• Sending and receiving are two sides. As a sender, your provider applies recipients' policies for you. As a domain owner, your policy only protects mail others send to you.

Where AI Emaily fits (and where it doesn't)#

MTA-STS is a control you set at the DNS and web-hosting layer, and it protects mail in transit between servers before it reaches a mailbox. AI Emaily is not part of that layer. It does not publish MTA-STS policies, act as a mail server, or host your policy file — that job belongs to your DNS provider and web host, and no email client can do it for you.

What AI Emaily does starts once a message has landed. It is an AI-native email client for Gmail, Outlook, and IMAP that triages the inbox, drafts replies you approve before they send, and defends against spam and phishing that get through. Mail you send rides your provider's outbound path — and as of August 2026 both Gmail and Exchange Online already apply recipients' MTA-STS policies for you. Sensitive data it stores, such as OAuth tokens and message bodies, is encrypted. So MTA-STS hardens the pipe; AI Emaily handles what comes out of it. We build AI Emaily.