# What is MTA-STS? SMTP Security Policy Explained > What MTA-STS is, how it forces TLS on inbound SMTP, the DNS record and policy you publish, and how it pairs with SPF, DKIM, and DMARC to secure email. 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)](/learning/what-is-an-mta). Defined in [RFC 8461](https://datatracker.ietf.org/doc/html/rfc8461), it closes a long-standing weakness in [SMTP](/learning/what-is-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: ![Five-step flow showing how MTA-STS works, from publishing a policy file to senders caching it.](/images/figures/what-is-mta-sts-fig1.webp) *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](/learning/what-is-an-mx-record)), and a `max_age` cache lifetime. - **DNS record.** A [DNS](/learning/what-is-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](/learning/what-is-spf), [DKIM](/learning/what-is-dkim), and [DMARC](/learning/what-is-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](https://datatracker.ietf.org/doc/html/rfc8460)). 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: ![Checklist of five things to verify when setting up MTA-STS, from TLS support to policy maintenance.](/images/figures/what-is-mta-sts-fig2.webp) *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](/tools/mta-sts), and see how transport security fits alongside your authentication records with the [Email Security Score](/tools/email-security-score). ## Frequently asked questions ### Is MTA-STS a replacement for DMARC? No — they solve different problems. DMARC, with SPF and DKIM, authenticates the *sender* of a message and controls what happens when authentication fails. MTA-STS secures the *transport* between mail servers so the message can't be intercepted or downgraded in transit. Run both. ### What's the difference between MTA-STS and DANE? Both enforce TLS on inbound SMTP, but they anchor trust differently. DANE uses DNSSEC-signed TLSA records to pin certificates, so it requires DNSSEC on your domain. MTA-STS uses the web PKI (standard CAs) and HTTPS policy hosting instead, which makes it easier to deploy on domains without DNSSEC. Some organisations publish both for the widest coverage. ### Will MTA-STS cause my email to bounce? Only if a sender can't establish valid TLS to your servers while your policy is in `enforce` mode — for example, an expired MX certificate. That's exactly why you start in `testing` mode with TLS-RPT enabled: it surfaces those failures as reports first, so you fix them before enforcing. ### How long does it take a policy change to take effect? Senders cache your policy for its `max_age`, and they detect changes by watching the `id` value in your TXT record. Bump the `id` whenever you edit the policy file so caching servers know to re-fetch; the DNS TTL on the TXT record governs how quickly they see the new `id`. ## Related reading - [What is an MX record?](/learning/what-is-an-mx-record) - [What is SPF?](/learning/what-is-spf) - [What is spoofing?](/learning/what-is-spoofing)