What is MTA-STS? Enforcing encryption for inbound email

SPF, DKIM and DMARC answer one question: is this email genuinely from who it claims to be from? Mail Transfer Agent Strict Transport Security (MTA-STS) answers a different one: was it protected on the journey?

It is the least known of the major email security standards, which is a shame, because the problem it solves is easy to grasp and quietly serious. The National Cyber Security Centre (NCSC) recommends it for UK organisations alongside DMARC, and it appears on SealedMail’s health check certificates for the same reason. Here is the plain-English version.

The polite encryption problem

When one mail server delivers a message to another, the two servers can encrypt the connection between them using Transport Layer Security (TLS) - the same technology behind the padlock on websites. Most modern servers do.

But here is the catch: for email, encryption is traditionally opportunistic. The sending server asks, in effect, “do you support encryption?” If the answer is yes, the conversation is encrypted. If the answer is no - or appears to be no - the sending server shrugs and delivers the message in plain text anyway, because email’s prime directive has always been that mail must get through.

Spot the weakness? The decision depends on an unprotected question and answer. An attacker positioned on the network path between the two servers can tamper with that exchange - stripping out the “yes, I support encryption” response so that both servers, each behaving correctly, fall back to an unencrypted conversation the attacker can read. This is a downgrade attack, and the troubling part is that neither server logs anything wrong: as far as each is concerned, the other simply did not offer encryption.

So “we use TLS” is true of most organisations and guarantees very little. Supporting encryption is not the same as being able to insist on it.

What MTA-STS does

MTA-STS lets your domain insist. You publish a policy declaring, in effect: mail for this domain must be delivered over an encrypted, certificate-verified connection to these named mail servers - and if that is not possible, do not deliver it at all.

Sending servers that honour MTA-STS (Google and Microsoft among them) fetch your policy in advance and cache it. Now the downgrade trick fails: if an attacker strips the encryption offer, the sending server does not fall back to plain text - it refuses to deliver, because your policy told it to. The attacker can still cause a delivery delay; what they can no longer cause is an unencrypted conversation.

For any organisation whose inbound email includes client matters, patient details or financial instructions, that is the difference that matters.

How it works mechanically - two pieces

MTA-STS has an unusual design quirk: it lives partly outside DNS.

1. A DNS record (_mta-sts.yourdomain.co.uk) announces that a policy exists and carries a version identifier that changes when the policy changes.
2. A policy file - a small plain-text file that must be served from a specific web address (https://mta-sts.yourdomain.co.uk/.well-known/mta-sts.txt) over HTTPS with a valid certificate. The file states the mode, the permitted mail servers, and how long senders may cache it.

That second piece is the standard’s notable operational obligation: the policy file must stay reachable, and its certificate must stay valid, indefinitely. If the file goes missing or the certificate expires while senders hold a cached policy in enforce mode, inbound mail from honouring providers can be refused. It is a small hosting job, but a permanent one - and exactly the kind of thing that breaks two years later when a website is migrated and nobody remembers the mta-sts subdomain existed. Continuous checking of this file is part of SealedMail’s weekly health check for precisely that reason.

Why starting in testing mode matters

The policy file’s mode field has three settings, and the order in which you use them is the whole craft:

• testing - senders check your policy and report what would have happened, but deliver mail normally even if the policy would have failed. Nothing can break.
• enforce - the real thing: non-compliant delivery is refused.
• none - policy published but inert (useful for orderly retirement).

The NCSC’s advice, and ours, is unambiguous: start in testing mode. An MTA-STS policy that names the wrong mail servers, or sits behind a faulty certificate, will - in enforce mode - block your legitimate inbound email, and the senders’ refusals happen far away where you cannot see them. Testing mode gives you a no-risk dress rehearsal: you publish the policy, then watch the reports for a few weeks to confirm that real-world senders can comply with it before you make it binding.

Which raises the obvious question - what reports? MTA-STS has a companion standard, TLS-RPT, through which receiving… rather, sending providers send you daily summaries of their delivery attempts: how many connections succeeded, how many failed, and why. Running MTA-STS without TLS-RPT means enforcing rules blindfolded; we cover it fully in What is TLS reporting?.

Where it fits in the stack

A useful way to hold the whole picture: SPF and DKIM prove who sent the mail, DMARC enforces it and reports back (What is DMARC?), and MTA-STS with TLS-RPT secures and monitors the delivery journey itself. Authentication without transport security leaves the conversation readable; transport security without authentication protects a message that might be fraudulent. They are complements, not alternatives - and UK guidance from the NCSC recommends adopting both sides.

MTA-STS is also, frankly, a differentiator: relatively few UK organisations have implemented it, so its presence on a security questionnaire or due-diligence review signals an organisation that has done email security properly rather than minimally.

Find out whether your domain has it

Most do not - and many that do have a lapsed certificate or unreachable policy file quietly undoing the work. SealedMail’s Free Domain Health Check checks your MTA-STS record and policy file alongside SPF, DKIM, DMARC, TLS-RPT, BIMI and blacklist status, and emails you a scored, plain-English certificate. Free, no sign-up, no sales call - and if you adopt MTA-STS, SealedMail’s weekly monitoring keeps watch over the policy file and certificate that the standard depends on.