ServerRecords

MTA-STS: Forcing Encrypted SMTP, and How to Check It Is Actually On

MTA-STS turns opportunistic SMTP encryption into an enforced policy. Here is how the DNS record and policy file work, and how to verify both are live.

mta-stsemail-securitysmtptlsstarttlsdeliverability

Email encryption between mail servers has a quiet problem: it is polite, not strict. When one server hands a message to another over SMTP, the two can wrap the connection in TLS so nobody in the middle reads your invoices, password resets, and internal threads. The catch is that TLS on SMTP was bolted on after the fact, and by default it only happens if both sides feel like it.

That "if they feel like it" is the weak point, and MTA-STS is the fix. If you want to know whether a domain has it switched on, the MTA-STS lookup reads the pieces that have to be in place and tells you what it finds.

Why STARTTLS alone is not enough

The mechanism that upgrades a plain SMTP session to an encrypted one is called STARTTLS. The sending server connects in the clear, the receiving server announces "I support STARTTLS", and the two negotiate a TLS tunnel before any mail flows. It works, and most mail is delivered this way.

The trouble is that the announcement itself travels in plaintext. An attacker sitting between the two servers can simply delete it. The sending side never hears the offer, shrugs, and falls back to plaintext delivery — the message goes out completely unencrypted, and nothing logs an error. This is STARTTLS stripping, and it is a downgrade attack that classic SMTP has no defense against.

There is a second gap. Even when STARTTLS does succeed, standard SMTP does not insist on a valid certificate. A self-signed cert, an expired one, a certificate for the wrong hostname — all of it is accepted, and the mail is sent anyway. So an attacker who can answer for your mail servers can present any certificate at all and read what comes through.

What MTA-STS actually declares

RFC 8461, published in 2018, closes both holes. Think of MTA-STS as HSTS for email: a domain publishes a standing declaration that says, in effect, "mail to me must arrive over TLS, with a certificate that checks out — if you cannot do that, do not deliver." Sending servers that understand the policy will refuse to fall back to plaintext, which is exactly what defeats the stripping attack.

1_mta-sts TXT
2Fetch policy (HTTPS)
3mode: enforce
How a sender discovers and applies your MTA-STS policy.

The declaration lives in two places, and both have to agree.

The first is a DNS TXT record at _mta-sts.yourdomain.com. It is short:

v=STSv1; id=202607221000;

The v=STSv1 tag marks the version. The id is a serial that you bump whenever the policy changes; when a sending server sees a new id, it knows to go and fetch the policy again rather than trust its cache.

The second piece is the policy file itself, served over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. A typical one looks like this:

version: STSv1
mode: enforce
mx: mail.yourdomain.com
max_age: 604800

Each line does a job:

  • version is again STSv1.
  • mode is the important one. mode: enforce means a sending server must use valid, matching TLS or abort the delivery. testing means failures are reported but mail still goes through — the safe way to roll out. none effectively turns the policy off.
  • mx lists the hostnames allowed to receive your mail, so a sending server can confirm the certificate it is shown belongs to a server you actually named.
  • max_age is how long, in seconds, a sender may cache the policy. A week (604800) is common.

What the ServerRecords lookup checks

Because the policy is split across DNS and a web server, a single mistake in either half can quietly disable protection or, worse, block your inbound mail. The MTA-STS lookup focuses on the two facts that matter most for knowing whether the policy is live at all.

First, it reads the DNS side: the TXT record at _mta-sts.<domain>, confirming it is present and carries a valid v=STSv1 tag and an id= value. Second, it fetches the policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt, checks that the file is actually reachable, and reads the mode: it declares — whether you are in enforce, testing, or none.

It is worth being clear about the edges of that check, because MTA-STS has more moving parts than any one tool inspects. The lookup does not validate the TLS certificate of the policy host, and it does not parse the mx: or max_age: lines or compare them against your live mail servers. So treat the full policy — the mode, the MX list, the cache lifetime — as the model you are aiming for, and treat the lookup as a fast, honest answer to two practical questions: is the DNS record there, and is the policy file reachable and what mode does it claim? If you want to see the actual mail servers your domain points at, run an MX record lookup alongside it and eyeball those hostnames against the mx: lines in your policy yourself.

Pair it with TLSRPT before you enforce

Strict encryption comes with a real operational risk. Once you are in mode: enforce, an expired certificate or a broken TLS setup on your side does not degrade gracefully — sending servers stop delivering. You want to hear about those failures before they pile up.

That is what TLSRPT (RFC 8460) is for. It is a separate DNS TXT record at _smtp._tls.yourdomain.com that asks other providers to email you daily JSON summaries of any TLS negotiation failures they hit talking to you. It is the early-warning system that makes enforcing MTA-STS safe to live with. On ServerRecords it is a companion feature with its own page, so once your MTA-STS policy checks out, run the TLS-RPT lookup too to confirm reporting is wired up.

If you are auditing more than transport security, the Email Health Check rolls MTA-STS in with SPF, DKIM, DMARC and the rest for a fuller picture of a domain's mail posture.

A sensible rollout

If you are turning this on for the first time, do it in the order that keeps mail flowing. Publish the policy file at testing first and set up TLSRPT so you can watch for failures without dropping a single message. Read the reports for a couple of weeks, fix whatever they surface, and only then flip the file to mode: enforce and bump the id in your DNS record so senders refetch.

After any change — a new mail host, a certificate swap, a provider migration — check both halves again. The DNS record and the policy file drifting out of sync is the failure people miss, and the lookup exists to catch exactly that.