Does MTA-STS encrypt my email?

It does not add encryption; it prevents encryption from being silently removed. TLS between mail servers already exists, but is optional and can be stripped in transit. MTA-STS makes the sender treat encryption as required for your domain.

Why is the policy served over HTTPS instead of DNS?

Because the certificate is what proves the policy is yours. DNS without DNSSEC can be spoofed, and MTA-STS was designed to work for domains that do not deploy DNSSEC: the web certificate substitutes for that trust.

What is the difference between MTA-STS and DANE?

Both prevent downgrade attacks. DANE puts the assurance in DNSSEC-signed records; MTA-STS puts it in an HTTPS certificate. MTA-STS is more widely deployed because it does not require DNSSEC, and the large mailbox providers support it.

Will this break inbound mail?

Not in testing mode, which reports without blocking. In enforce mode it can, if the policy lists a hostname that does not match your actual mail exchangers, which is exactly what the testing period exists to catch.

InfoInfrastructure

MTA-STS is not configured

The domain has no MTA-STS policy, so mail sent to it is delivered over opportunistic TLS: encryption that a network attacker can strip by removing the STARTTLS offer, causing the sending server to fall back to plaintext without warning. MTA-STS closes that gap by publishing, over HTTPS, a policy that says encryption is required and which mail servers are legitimate.

Check your own domainMTA-STS checker

What causes this

SMTP encryption is opportunistic by default: a sending server offers TLS, and if the handshake fails it may simply deliver in the clear. MTA-STS lets you state that mail to your domain must be delivered over TLS to a mail exchanger whose certificate matches your policy, which closes off downgrade attacks. It requires a TXT record plus a policy file served over HTTPS at a fixed URL.

What it breaks

No immediate problem. Without it, a network attacker positioned between a sender and your mail server can strip TLS and read mail in transit.

What the receiving server does

Without MTA-STS, a sending server connects to your mail exchanger and encrypts only if STARTTLS is offered. An attacker positioned in the path can delete that offer from the conversation, and the sender, having no way to know it was ever there, continues in the clear. Nothing bounces and nothing is logged as a failure. With a policy published, a sender that supports MTA-STS caches it and will refuse to deliver over an unencrypted connection or to a host the policy does not list, which makes the downgrade attack fail closed rather than open.

The three pieces, all of which are required

MTA-STS is deliberately split between DNS and HTTPS. The DNS record announces that a policy exists and carries a version identifier; the policy itself is served over HTTPS, where the certificate proves it came from you.

DNS_mta-sts.example.com TXTv=STSv1; id=20260101000000Z (change id whenever the policy changes)

hostmta-sts.example.commust serve HTTPS with a valid certificate for that name

path/.well-known/mta-sts.txtthe policy file itself, served as text/plain

modetesting then enforcestart at testing so failures are reported rather than blocking mail

How to fix it

Publish an MTA-STS policy file and the accompanying TXT record.

Serve a policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt listing your MX hostnames.
Start the policy in testing mode so failures are reported but mail is not blocked.
Publish a TXT record at _mta-sts.yourdomain.com with a version and a unique id.
Once TLS reports show no failures, change the policy mode to enforce.

If you send with

Start in testing mode: A policy in testing mode is evaluated and reported on but never blocks delivery. Publish it alongside TLS-RPT, read the reports for a few weeks, confirm every mail exchanger you list is correct, and only then switch to enforce. Going straight to enforce with a wrong hostname in the policy blocks inbound mail.
The certificate is the hard part: The policy is trusted because it is served over HTTPS with a certificate valid for mta-sts.yourdomain.com. That means a real certificate and a renewal process. A policy served on an expired certificate is ignored, so the certificate quietly becomes part of your mail infrastructure.
Hosted mail platforms: Google Workspace and Microsoft 365 both support inbound MTA-STS, but neither publishes the policy for you. You host the file and the DNS record; they simply need to be listed correctly as the mail exchangers.

Confirming the fix worked

Publish the policy file first and confirm it loads over HTTPS with a valid certificate before adding the DNS record.
List every hostname from your MX records in the policy, exactly as they appear.
Start with mode: testing, and publish a TLS-RPT record so failures are reported to you.
Switch to mode: enforce only after the reports show clean results, and update the id value in DNS whenever the policy changes.

Common questions

Does MTA-STS encrypt my email?: It does not add encryption; it prevents encryption from being silently removed. TLS between mail servers already exists, but is optional and can be stripped in transit. MTA-STS makes the sender treat encryption as required for your domain.
Why is the policy served over HTTPS instead of DNS?: Because the certificate is what proves the policy is yours. DNS without DNSSEC can be spoofed, and MTA-STS was designed to work for domains that do not deploy DNSSEC: the web certificate substitutes for that trust.
What is the difference between MTA-STS and DANE?: Both prevent downgrade attacks. DANE puts the assurance in DNSSEC-signed records; MTA-STS puts it in an HTTPS certificate. MTA-STS is more widely deployed because it does not require DNSSEC, and the large mailbox providers support it.
Will this break inbound mail?: Not in testing mode, which reports without blocking. In enforce mode it can, if the policy lists a hostname that does not match your actual mail exchangers, which is exactly what the testing period exists to catch.