/ Glossary — Authentication
What is MTA-STS?
SMTP MTA Strict Transport Security — the policy that forces encrypted, authenticated delivery to your domain and refuses to fall back to plaintext. Transport hardening, not identity. Here's how it works.
/ Definition
MTA-STS, or SMTP MTA Strict Transport Security, lets your domain tell other mail servers to require valid, authenticated TLS encryption when delivering to you — and to refuse to fall back to unencrypted plaintext if that fails. It closes a gap in SMTP's default behavior, where encryption is optional and an attacker in the middle can strip it, downgrading the connection to read or alter mail.
Unlike SPF, DKIM, and DMARC, which protect your identity — proving mail is really from you — MTA-STS protects the transport, ensuring the connection delivering your mail is encrypted and authenticated. It's a different layer for a different threat. Check any domain's MTA-STS setup with our MTA-STS validator.
/ In practice
How MTA-STS works
MTA-STS has two parts. A DNS record at _mta-sts.yourdomain.com carries an id that changes whenever your policy changes, signalling senders to re-fetch it. The policy file itself lives over HTTPS at mta-sts.yourdomain.com/.well-known/mta-sts.txt and contains the real rules: the mode, the valid MX hostnames, and a max_age controlling how long senders cache it. A sending server that supports MTA-STS reads the record, fetches and caches the policy over validated HTTPS, and enforces it on every delivery until the cache expires. It's usually paired with TLS-RPT, which reports TLS failures back to you.
Testing before enforce
The mode field decides whether you're protected or just observing. In testing mode, senders perform the TLS checks but still deliver if they fail, reporting the failure — this is how you find problems without blocking mail. In enforce mode, a failed TLS check means the message isn't delivered, which is full protection but also where a misconfiguration has consequences. The correct path is always testing first: publish the policy, collect TLS-RPT reports until every legitimate sender connects cleanly, then promote to enforce. It belongs after your authentication foundation, as transport hardening on top.
/ Reporting and priority
MTA-STS and TLS-RPT together
MTA-STS is almost always deployed alongside TLS-RPT, and the pairing is what makes it safe. TLS-RPT — TLS Reporting — is a separate DNS record at _smtp._tls.yourdomain.com that tells sending servers where to send daily reports about TLS connection successes and failures when delivering to you. On its own, MTA-STS in enforce mode is a blunt instrument: if some legitimate sender can't establish TLS, their mail to you fails and you may never know why. TLS-RPT gives you that visibility, which is exactly the information you need before promoting a policy from testing to enforce. Our MTA-STS validator checks both records together for this reason.
Where MTA-STS belongs in your priorities
MTA-STS protects a different surface than the authentication trio, and that tells you where it fits. SPF, DKIM, and DMARC answer whether a message is really from the domain it claims — they protect identity. MTA-STS answers whether the connection delivering that message is encrypted and authenticated — it protects transport. Both matter, but the order is foundation first: get the authentication trio to enforcement, because it's effectively mandatory and stops the most common attack, then add MTA-STS as transport hardening on top. It takes you from authenticated and trusted to authenticated, trusted, and encrypted end to end. Deploying the two together is standard practice, because enforcing encryption without visibility into failures silently blocks legitimate mail.
Publishing MTA-STS is one thing. Moving to enforce safely is another.
We deploy MTA-STS with TLS-RPT, watch the reports, and promote to enforce when it's safe — without blocking legitimate mail. Bring us your domain and we'll harden delivery.
Book infrastructure reviewRelated capabilities