MTA-STS Explained: Enforce Email Encryption in Transit

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) is a standard that lets your domain tell other mail servers: "only deliver my mail over TLS, to these MX hosts, with a valid certificate." You publish a DNS TXT record and a small policy file over HTTPS. Sending servers that support MTA-STS then refuse to fall back to unencrypted or spoofed connections.

The problem MTA-STS solves

Email between servers travels over SMTP. When SMTP was designed, encryption wasn't part of it. Later the STARTTLS command was added: the sending server asks "do you support TLS?" and upgrades the connection if the answer is yes.

The catch is that STARTTLS is opportunistic. If the answer is no, or the TLS handshake fails, most servers deliver in plain text anyway. They also usually don't check that the certificate is valid for the host. That leaves two openings for an attacker who sits on the network path:

• Downgrade (STARTTLS stripping): remove the "I support TLS" line from the conversation, so the mail is sent unencrypted.
• MX spoofing: tamper with DNS answers so mail goes to the attacker's server, which then presents any certificate it likes.

MTA-STS closes both gaps for mail sent to your domain. Senders that support it learn, through a channel authenticated by HTTPS, that your domain requires TLS with a certificate matching one of the listed MX hosts.

How MTA-STS works, step by step

1. A sending server wants to deliver mail to anna@example.com.
2. It looks up the TXT record _mta-sts.example.com and finds an id.
3. It fetches the policy over HTTPS from https://mta-sts.example.com/.well-known/mta-sts.txt. The web server's certificate must be valid, which is what makes the policy hard to forge.
4. The policy lists the allowed MX patterns and a mode. The sender caches it for max_age seconds.
5. In enforce mode, the sender delivers only if it can make a TLS connection with a valid certificate to an MX host that matches the policy. Otherwise it keeps the mail queued and retries later. It doesn't fall back to plain text.

The id value changes whenever you update the policy. That tells senders to fetch the file again before their cache expires.

The records you need

An MTA-STS setup has three parts. Here they are for example.com:

_mta-sts.example.com.   TXT   "v=STSv1; id=20261008T120000"

The policy file, served at https://mta-sts.example.com/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mx.example-provider.com
max_age: 604800

And the TLS reporting record (TLS-RPT, RFC 8460):

_smtp._tls.example.com. TXT   "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Requirements that often trip people up:

• mta-sts.example.com must have a valid HTTPS certificate. Without it, the policy is ignored.
• Every MX host you really use must match an mx: line. Wildcards such as *.example-provider.com are allowed.
• When you change MX hosts, update the policy and the id before you switch.

The three modes

Start in testing with a short max_age (for example one day). Read the reports, fix any certificate or MX mismatches, then switch to enforce with a longer max_age (one to several weeks is common).

A practical rollout looks like this:

1. Publish the TLS-RPT record first, so reports start arriving before anything can break.
2. Create the mta-sts subdomain, give it a valid HTTPS certificate and host the policy file in testing mode.
3. Publish the _mta-sts TXT record with a new id.
4. Read the reports for a couple of weeks. Look for certificate errors, hostname mismatches and MX hosts you forgot to list.
5. Switch the policy to enforce, raise max_age, and change the id so senders fetch the new version.
6. Add a reminder to your change process: any future MX change starts with a policy update.

TLS-RPT: why reports matter

TLS reporting tells you when senders couldn't set up a secure connection to your servers. Typical causes are an expired certificate, a hostname mismatch, or an MX host missing from your policy. Large mailbox providers send daily JSON reports to the address in your rua. Without TLS-RPT, an enforce policy with a mistake in it could quietly delay incoming mail, and you would only find out when someone complains.

MTA-STS vs DANE

DANE for SMTP (RFC 7672) solves the same problem in a different way. It publishes the expected certificate details in DNS as TLSA records, protected by DNSSEC.

They aren't rivals. Many security-minded operators publish both. MTA-STS is the easier choice if your DNS host doesn't offer DNSSEC.

What MTA-STS does not do

Be clear about the scope:

• It protects server-to-server transport for mail delivered to your domain. It doesn't encrypt messages at rest, and it isn't end-to-end encryption, so the receiving provider can still read and filter the content.
• It only works with senders that support it. Most large providers do, but not every server on the internet.
• Your own outgoing mail is protected by the recipients' MTA-STS or DANE settings, as long as your provider honours them.

For a full picture of how transport security fits with authentication and phishing defence, see email security best practices. Since MTA-STS lists your MX hosts, it is also worth reading MX records explained.

How Zomail handles MTA-STS

On the inbound side, Zomail's guided DNS page includes MTA-STS and TLS-RPT alongside MX, SPF, DKIM and DMARC, and it checks each record so you can see what is missing. You keep your domain at your registrar. You can add the records by hand, download a zone file for providers such as Cloudflare, or use one-click Domain Connect where your DNS provider supports it. The getting started guide walks through every record.

Beyond your DNS records, Zomail encrypts mail in transit with TLS, runs MTA-STS in enforce mode, and validates DANE on outbound delivery. Mail to partners who publish DANE records goes over a verified connection rather than an opportunistic one.

If you would like transport security handled by a guided setup rather than hand-built policy files, Zomail Cloud is priced per mailbox per month. Current prices are on the pricing page. Questions about a specific DNS provider can go to support.

FAQ

Is MTA-STS the same as email encryption?

It enforces encryption in transit between mail servers. Messages are still readable by the sending and receiving providers. It isn't end-to-end encryption such as S/MIME or PGP.

Do I need MTA-STS if I already have SPF, DKIM and DMARC?

They solve different problems. SPF, DKIM and DMARC prove who sent a message. MTA-STS protects the connection the message travels over. A well-secured domain uses all of them, plus TLS-RPT to catch problems.

What happens if my MTA-STS policy is wrong?

In enforce mode, senders that support MTA-STS will hold mail they can't deliver securely and retry. So a broken policy can delay incoming mail. That's why you should start in testing mode, read TLS-RPT reports and keep the mx: lines in step with your real MX records.

How do I check whether my domain's MTA-STS works?

Confirm that the _mta-sts TXT record exists. Open https://mta-sts.yourdomain/.well-known/mta-sts.txt in a browser and check that it loads without certificate errors and lists your MX hosts. Then watch the TLS-RPT reports for failures.