What Is MTA-STS and Why It Matters Now

Short answer: MTA-STS (Mail Transfer Agent Strict Transport Security) is a standard that forces email between mail servers to travel over encrypted TLS. Without it, an attacker on the network path can strip encryption and read or alter your mail in plaintext. SPF, DKIM, and DMARC stop someone from forging your address. MTA-STS protects the message while it moves. Most companies have done the first and skipped the second. Across the top one million domains, MTA-STS adoption is still below 1 percent.

That last number is the whole point of this article. If you run email authentication for an enterprise, you have likely closed the spoofing gap and left the transit gap wide open. Here is what MTA-STS does, why it matters to a security program, and how to deploy it without breaking mail flow.

 

The gap nobody mapped: spoofing vs transit

Email security splits into two separate problems. The first is identity. Can a stranger send mail that looks like it came from your domain? SPF, DKIM, and DMARC answer this. They let receiving servers verify that a message claiming to be from you was actually authorized by you. This is the layer regulators and mailbox providers now demand. The second is confidentiality in transit. When your mail server hands a message to a recipient server, is that connection encrypted, and can it be forced open? This is where MTA-STS lives, and it is the layer almost everyone forgets. The two problems are independent. You can have a perfect DMARC setup at p=reject and still send every message in plaintext across the open internet. Closing one gap does nothing for the other.

 

Why SMTP is encrypted only when it feels like it

SMTP, the protocol that moves mail between servers, was built with no encryption at all. TLS was bolted on later through a command called STARTTLS. The problem is that STARTTLS is opportunistic. The sending server asks the receiving server, "do you support encryption?" If the answer is yes, they encrypt. If the answer is no, or if the answer never arrives, the sender quietly delivers the message in plaintext anyway.

An attacker positioned on the network path can abuse this. They sit between the two servers, intercept the STARTTLS offer, and remove it. Each server thinks the other cannot do TLS, so they fall back to plaintext. The attacker now reads, copies, or modifies the email in the clear. This is called a downgrade attack or STARTTLS stripping, and it is invisible to both ends.

For a security team, the takeaway is simple. Opportunistic encryption is not a control. It is a preference that any attacker on the path can override.

 

What MTA-STS actually does

MTA-STS, defined in RFC 8461, turns that preference into a rule. It lets your domain publish a policy that says: "Mail to my servers must use TLS with a valid certificate. If a sender cannot negotiate that, do not deliver the message in plaintext. Hold it or fail it instead."

A sending server that supports MTA-STS fetches your policy, caches it, and from then on refuses to downgrade. The stripping attack stops working, because falling back to plaintext is no longer an option the sender will accept.

The setup has three parts.

1. A DNS TXT record

   at _mta-sts.yourdomain.com. It is tiny and carries a policy version and an ID that changes when your policy changes.

2. A policy file

   served over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. It lists your mode, your valid mail servers, and how long senders should cache the policy.

3. A companion standard called TLS-RPT

   (RFC 8460), which sends you aggregate reports on TLS connection failures so you can see problems before they cause outages.

The HTTPS hosting requirement is the one detail teams underestimate. Your policy lives behind a web certificate, so a lapsed certificate on that subdomain can quietly break the policy. This is also why a managed or hosted MTA-STS setup removes most of the operational risk.

 

How MTA-STS fits with SPF, DKIM, and DMARC

The four standards are layers, not alternatives. Here is the role each one plays.

Standard	Protects against	What it controls
SPF	Spoofing	Which servers may send mail as your domain
DKIM	Tampering and spoofing	A signature proving the message was authorized and unaltered
DMARC	Spoofing	What receivers do with mail that fails SPF or DKIM, plus reporting
MTA-STS	Eavesdropping and downgrade attacks	That inbound mail to you arrives over enforced TLS

SPF, DKIM, and DMARC all answer "is this message really from you?" MTA-STS answers a question none of them touch: "is this message safe while it travels?" A complete email security posture needs all four.

 

Why this matters now, not later

Three forces make transit encryption a board level concern in 2026, not a nice to have.

Mandates already cover the easy half. As of May 2025, Microsoft requires bulk senders of more than 5,000 messages a day to Outlook, Hotmail, and Live to publish SPF, DKIM, and DMARC, matching the rules Google and Yahoo set in 2024. Mailbox providers have made the spoofing layer non negotiable. The transit layer is the next obvious place for scrutiny, and it is the layer your competitors have not built.

Regulators are starting to expect encryption in transit. In the UK, National Cyber Security Centre guidance pushed government domains to the highest MTA-STS adoption of any sector, near 40 percent, while most other sectors sit in the low single digits. Where a regulator leads, audits follow. EU obligations under frameworks like NIS2 raise the same expectation for encrypting communications.

The data crossing your mail path is sensitive. Contracts, invoices, payment confirmations, password resets, and personal data all move by email. A downgrade attack does not just read that traffic, it can alter it. In the UK alone, payment fraud and scams took more than 629 million pounds in the first half of 2025, much of it set up through manipulated email. Transit security is a direct fraud control, not a checkbox.

 

The adoption numbers, and why they are an opportunity

The state of MTA-STS adoption is striking, and for a security leader it cuts two ways.

• Across the top one million domains, fewer than 1 percent publish an MTA-STS policy, even though that count has more than doubled in two years.

• In Norway, 96 percent of domains have not deployed MTA-STS at all.

• In Sweden, fewer than 3 percent of domains have a valid MTA-STS record.

• Among UK banks, the enforcement gap is around 95 percent, meaning sensitive financial mail still travels paths that can be downgraded.

• The deployments that do exist are mostly correct: roughly four in five domains that publish a policy configure it properly.

On the risk side, near universal absence means most organizations are exposed. On the strategy side, it means closing this gap puts you ahead of almost everyone, including most of your peers and most regulators. It is a rare control that is both genuinely protective and easy to evidence in an audit.

 

How to deploy MTA-STS without breaking mail

The safe rollout is staged, not flipped on overnight.

1. Inventory your mail servers.

   List every MX host that receives mail for your domain. The policy must match these exactly.

2. Confirm valid TLS everywhere.

   Each MX host needs a valid, trusted certificate. A self signed or expired certificate will cause enforced policies to reject mail.

3. Start in testing mode.

   Publish the policy with mode set to testing. Senders honor your TLS preference but still deliver if it fails, and TLS-RPT shows you what is happening.

4. Read the reports.

   Use TLS-RPT data to find misconfigurations before they cost you delivery.

5. Move to enforce.

   Once reports are clean, switch the mode to enforce. Now downgrade attacks fail and mail to you must be encrypted.

6. Watch the HTTPS certificate.

   The policy file depends on a valid web certificate on the mta-sts subdomain. Monitor its expiry, or use a managed setup that handles it.

The whole deployment is DNS records and a static file. There is no software to install on your mail servers and no change to how users send mail. That is what makes it one of the highest value, lowest effort controls in email security.

You can do the whole proces safely with dmarcdkim.com. Check it out here.

 

Frequently asked questions

Is MTA-STS a replacement for DMARC? No. DMARC stops people from forging your domain. MTA-STS stops people from intercepting mail in transit. They solve different problems and work together.

Does MTA-STS encrypt the message itself, like PGP or S/MIME? No. MTA-STS enforces encryption of the connection between mail servers. It does not encrypt the message at rest in a mailbox. For end to end content encryption you still need S/MIME or PGP. For most organizations, enforced transit encryption closes the larger and more common gap first.

What is the difference between MTA-STS and DANE? Both enforce TLS for inbound mail. DANE ties the policy to DNSSEC and a cryptographic record in DNS. MTA-STS publishes its policy over HTTPS and does not require DNSSEC, which makes it simpler to deploy. Many organizations adopt MTA-STS first because the operational bar is lower.

Will MTA-STS cause email to be lost? Only if a sending server cannot negotiate TLS to a misconfigured MX host while you are in enforce mode. This is exactly why you start in testing mode and use TLS-RPT reports to clean up problems before enforcing.

How hard is it to set up? The artifacts are a small DNS record, a static policy file on an HTTPS subdomain, and a reporting record. The hard part is operational discipline: matching the policy to your MX hosts and keeping the HTTPS certificate valid. A managed MTA-STS service handles both. Dmarcdkim.com offers hosted MTA-STS as a service.

 

The bottom line

Your spoofing defenses are probably mature. Your transit defenses probably do not exist. MTA-STS closes a gap that mailbox providers and regulators are moving toward, that protects the sensitive data crossing your mail path, and that fewer than 1 percent of domains have addressed. Deploying it puts you in a very small group, and it is one of the few security wins that is both real and quick.