What is MTA-STS?
MTA-STS is a standard that forces inbound email to your domain to be delivered over an encrypted, authenticated connection. Its full name is Mail Transfer Agent Strict Transport Security, and it fixes a long-standing weakness in how mail servers talk to each other. While the web moved to enforced HTTPS years ago, email between servers still often falls back to plain, unprotected connections. MTA-STS lets you tell other mail servers that they must use proper encryption when delivering to you, or not deliver at all.
What problem does MTA-STS solve?
When one mail server sends a message to another, it normally tries to use TLS encryption, but this is opportunistic: if the encryption is missing, invalid or stripped by an attacker, most servers quietly fall back to sending the message in the clear. An attacker in the right position can force that downgrade and read or alter mail in transit. MTA-STS removes the silent fallback. Once you publish a policy, compliant senders will refuse to deliver your mail over an insecure or unauthenticated connection.
How MTA-STS works
MTA-STS combines two published elements. The first is a small DNS TXT record on the host _mta-sts under your domain, which signals that a policy exists and carries a version identifier that changes whenever you update the policy. The second is the policy file itself, served over HTTPS from a dedicated subdomain, conventionally mta-sts followed by your domain. A sending server fetches the policy over a valid HTTPS connection, which authenticates it, then applies the rules to its delivery attempt.
MTA-STS policy modes
- none indicates no active policy, used when winding one down.
- testing asks senders to report problems but still deliver, so you can trial the policy safely.
- enforce tells senders to refuse delivery if the connection is not encrypted and authenticated to a server named in your policy.
The safe path is to start in testing mode, confirm from the reports that legitimate mail is not being affected, and only then switch to enforce.
MTA-STS and TLS-RPT work together
MTA-STS is far more useful when paired with TLS reporting. A companion standard, TLS-RPT, asks sending servers to send you daily summaries of their delivery attempts, including any that failed to negotiate secure encryption. Those reports are how you spot problems before flipping to enforce, and how you keep an eye on delivery afterwards. See our guide on what TLS-RPT is for the details.
How to set up MTA-STS
Setting up MTA-STS means publishing the DNS record, hosting the policy file over valid HTTPS on the mta-sts subdomain, and listing the mail servers that are allowed to receive your email. Because the policy is fetched over HTTPS, the subdomain needs a valid certificate, which also protects the policy from tampering. Begin in testing mode alongside TLS-RPT, watch the reports, and move to enforce once everything looks clean.
Do you need MTA-STS if you already use TLS?
This is the most common question, and the answer is yes, because the two things are not the same. Supporting TLS means your mail server is willing to encrypt a connection when the other side asks for it. MTA-STS means the other side is required to encrypt, and to verify it is really talking to your server, or else abandon the delivery. Ordinary opportunistic TLS can be silently stripped by an attacker sitting between the two servers, and neither side will complain; the message simply goes out in plain text. MTA-STS is what turns that optional, strippable encryption into a firm rule that a network attacker cannot quietly bypass. So having TLS enabled is necessary groundwork, but it is not a substitute for MTA-STS. If your domain handles anything sensitive by email, and almost every business does, publishing an MTA-STS policy on top of your existing TLS support is the step that actually guarantees the encryption is used.
How to check MTA-STS
Because MTA-STS depends on a DNS record and an HTTPS-hosted file staying in sync, it is easy to half-configure. Run a security scan with EzyAudit AI and you will see whether MTA-STS is published, whether the policy is reachable, and how it fits with the rest of your email security, all in plain language. Review the full list of checks we run. For the formal specification, MTA-STS is defined in IETF RFC 8461.
MTA-STS makes the encryption of your inbound email mandatory rather than optional, closing a gap most domains still leave open. Scan your website now to see whether MTA-STS is protecting your mail in transit.