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 maxage, 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.

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:

Five-step flow showing how MTA-STS works, from publishing a policy file to senders caching it.

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:

Checklist of five things to verify when setting up MTA-STS, from TLS support to policy maintenance.

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.