Everyone Talks About DMARC. Almost Nobody Turns On MTA-STS.

Every call I take about email security goes the same way for the first twenty minutes. DMARC. Is it published, is it enforced, p=quarantine or p=reject. Then SPF — is it under the 10-lookup limit. Then DKIM — is it actually signing. All the right questions. I ask them myself.

Then I ask one more: "what's your MTA-STS policy set to?" and the call goes quiet in a very specific way. Not "we haven't gotten to it yet" quiet. "We've never heard of it" quiet.

That gap is the actual subject of this post. DMARC, SPF and DKIM all answer one question: is this email really from who it says it's from. None of them — not one — say anything about what happens to the email once it leaves the sending server and starts traveling toward yours. That's a completely different question, and it has its own completely different answer: MTA-STS.

Who this is for:

IT and security people who have DMARC enforced and assumed that meant email was "secure"
MSPs auditing a customer domain who see SPF, DKIM and DMARC all green and stop looking
Anyone who wants the actual mechanics of a mail interception attack explained in plain terms, not just the acronym

The one-sentence version

DMARC proves an email came from your domain; MTA-STS makes sure nobody sitting on the network path in between could read or tamper with it while it was getting to you — and without MTA-STS, standard email delivery will silently fall back to sending in plain text the moment anything interferes with encryption.

The explanation I actually give people

I don't start with RFC numbers. I start with the version I use on customer calls, because it's the one that makes people sit up.

Say you send me an email. Under the hood, that's not really "you to me" — it's your mail server having a conversation with my mail server, handing the message across. That conversation is supposed to happen over an encrypted connection. Supposed to.

Now imagine there's a dishonest server sitting in the middle of that path — not on your laptop, not on mine, but somewhere on the network your server's connection actually crosses to reach mine. When your server reaches out to start that encrypted handshake, my dishonest server steps in and answers first: "I can't handle your encrypted request. Malformed. Try again." Your server tries again. Same response. This goes back and forth a few times, and eventually your server does exactly what it was built to do when encryption keeps failing — it says, in effect, "fine, here it is in plain text," and sends the message unencrypted. The message still arrives. It looks completely normal on my end. But it crossed the network in the clear, past a server that was never supposed to be part of that conversation at all, and could read every word of it.

That's not a hypothetical I made up for the call — it's a real, named attack, and the technical explanation lines up with the story almost exactly.

A simple back-and-forth diagram showing a sending mail server attempting an encrypted handshake, an attacker positioned in the middle repeatedly rejecting it as unreadable, and the sending server eventually giving up and resending the message in plain text, which the attacker then reads

What's actually happening: STARTTLS and why it fails open

The mechanism behind that story has a name: STARTTLS stripping, and it exploits a design decision made back in 2002.

Standard SMTP — the protocol mail servers use to hand messages to each other — didn't launch with encryption built in. STARTTLS was added later as an upgrade a server offers, not a requirement. Two mail servers start talking in plain text, and if both sides support it, one offers to upgrade the connection to TLS partway through. If that upgrade succeeds, the rest of the conversation, including the actual message, is encrypted.

Here's the part that matters: if the upgrade doesn't happen — for any reason — the servers don't stop and refuse to proceed. They just... continue. In plain text. This is called opportunistic TLS, and "opportunistic" is doing a lot of work in that name. Encryption happens if the opportunity is there. If it isn't, delivery still goes ahead unencrypted, because in 2002 the priority was making sure email kept working everywhere, even against old servers with no TLS support at all. Reasonable tradeoff for its time. Still the default today.

An attacker positioned on the network path between two mail servers can force that fallback deliberately. They intercept the STARTTLS offer and interfere with it — refuse it, corrupt it, or just drop it — so the sending server never completes the encrypted upgrade. Because SMTP fails open by design, the sending server does exactly what it's built to do when TLS isn't available: it delivers the message anyway, unencrypted, to whatever is answering on the other end. Neither the sender's IT team nor the recipient sees an error. The email arrived. It just arrived having crossed the network readable to whoever was sitting on that path.

This is a documented attack class, not a theoretical one — well-known enough that the IETF built a standard specifically to close it: MTA-STS, published as RFC 8461 in 2018.

Where DMARC's protection actually stops

This is the part that catches even careful IT teams off guard, because it feels like it should already be covered.

DMARC, backed by SPF and DKIM, is genuinely strong at what it does: it makes sure nobody can send email claiming to be your domain without getting caught. A fully enforced DMARC record at p=reject is real, meaningful protection against impersonation.

None of that touches the scenario above. The STARTTLS-stripping attack doesn't forge anything. It doesn't touch the From: address, doesn't fail SPF, doesn't fail DKIM, doesn't fail DMARC — because the email genuinely is from you, signed correctly, aligned correctly, exactly as it should be. The only thing that happened is it took an unencrypted detour past an attacker on its way to the recipient. DMARC has no mechanism to notice that, because DMARC was never built to look at the transport layer at all. It's checking identity, not the path the message traveled.

A domain can have a perfect DMARC score and still have every legitimate email readable in transit to anyone positioned correctly on the network. Those are two separate problems with two separate fixes, and fixing one does nothing for the other.

Two email security layers shown side by side: identity protection covering SPF, DKIM and DMARC checking whether a message is genuinely from the claimed domain, and transport protection covering MTA-STS and TLS-RPT checking whether the message stayed encrypted on its way to the recipient — with a marked gap showing a fully DMARC-enforced domain still exposed to interception if MTA-STS is missing

What MTA-STS actually does about it

MTA-STS closes the specific gap that lets the fallback happen. A domain publishes a policy — in DNS, plus a small file hosted over HTTPS — that says, in effect: mail delivered to me must use a properly validated encrypted connection, from one of these specific servers, full stop. Any sending server that respects the policy now knows that in advance.

That changes the outcome of the attack completely. The attacker in the middle can still try to interfere with the handshake. But instead of the sending server shrugging and falling back to plain text, it does the opposite: it refuses to deliver the message at all rather than send it unencrypted. The message queues, retries, and — if the interference doesn't clear — eventually bounces back to the sender. That's a real inconvenience. It's also the correct outcome, because a bounced message is recoverable and a silently intercepted one isn't.

Its companion standard, TLS-RPT (RFC 8460), is what makes turning this on safe rather than a leap of faith — it reports back which delivery attempts failed the policy and why, so you can see the picture before you flip from monitoring to actually enforcing it. The rollout shape is deliberately similar to DMARC's own: start in a mode that only reports, confirm nothing legitimate breaks, then move to the mode that actually blocks.

Rollout path for MTA-STS shown as two stages: mode testing, where the policy is published and TLS-RPT reports collect any delivery failures without blocking anything, followed by a deliberate switch to mode enforce once the reports show no legitimate mail is affected, at which point delivery failing the policy is refused rather than sent in plain text

The full mechanics — the exact DNS record, the policy file format, the three modes, and the mistakes that leave a published policy doing nothing at all — are covered in detail in What is MTA-STS? A Complete Guide to Email Transport Security and TLS Reporting. This post is about why it gets skipped; that one is the reference for actually setting it up correctly.

Why it gets skipped

It's not that people disagree MTA-STS matters once it's explained. It's that it almost never comes up unprompted, and I think there are three fairly ordinary reasons for that.

It requires infrastructure DMARC doesn't. SPF, DKIM and DMARC are all just DNS TXT records. MTA-STS needs that too, but it also needs a small file reachable over valid HTTPS at a fixed path. For a domain with an existing website that's a minor lift. For a domain that sends mail but doesn't otherwise run a public website — more common than people expect, especially for internal or transactional-only domains — it means standing up hosting for exactly one file, which is a task that's easy to keep deferring.

The attack it stops doesn't show up in normal reporting. DMARC failures show up in aggregate reports whether or not anyone reads them. A STARTTLS-stripping interception, without MTA-STS and TLS-RPT in place, produces no report anywhere. The message was delivered successfully, from every system's point of view. There's no failure log to notice, no dashboard that goes red. The absence of evidence looks a lot like the absence of a problem, right up until it isn't.

Compliance checklists ask about DMARC by name and rarely ask about this. A lot of DMARC rollouts start because a cyber-insurance form or a customer's security questionnaire specifically asked "do you have DMARC." Very few ask about MTA-STS by name yet, so it doesn't get the same forcing function. The checklist gets satisfied, the project gets marked done, and the transport gap never comes up because nobody was required to ask about it.

None of that makes it less real. It just explains why a domain can look fully covered — DMARC enforced, SPF clean, DKIM signing everything — and still have this specific hole open.

Checking where you actually stand

This is public, checkable information, the same as everything else in this space. grimDMARC's Domain Scanner checks MTA-STS and TLS-RPT alongside DMARC, SPF, DKIM and BIMI, and reports them as a separate score rather than folding everything into one pass/fail — deliberately, because a domain that can't be impersonated but can still be silently intercepted in transit isn't actually done, and blending the two together would hide exactly which one still needs attention.

If you've already got DMARC enforced and haven't looked at this yet, it's worth the few minutes it takes to check. If you're earlier in the process and still working through DMARC, SPF and DKIM first, that's a reasonable place to be — DMARC Explained and What is SPF? are good starting points — just don't mistake finishing that stage for finishing the whole picture.

Frequently asked questions

If DMARC is fully enforced at p=reject, is my email still at risk from this? Yes, if MTA-STS isn't separately configured. DMARC protects identity — whether email claiming to be from your domain really is. It does nothing to protect the transport path of email that's genuinely, correctly, legitimately yours.

Does this attack require the sender or recipient to do anything wrong? No. Neither side has to click anything, misconfigure anything, or make a mistake. The interference happens on the network path between the two mail servers, somewhere neither party directly controls.

How would I even know if this happened to us? Without TLS-RPT, you likely wouldn't — that's exactly the problem. With TLS-RPT configured, you'd see a report showing a delivery attempt that failed to establish the required encrypted connection, which is the signal worth investigating.

Is this only a risk for large or high-profile companies? No. The attack targets the network path, not the company. Any domain sending or receiving mail across a network segment an attacker can position on is a potential target, regardless of size.

Do we need MTA-STS if we already use a major provider like Microsoft 365 or Google Workspace? Your provider handles plenty of infrastructure for you, but MTA-STS is a policy you publish for your own domain, specifying which servers are authorized to receive your mail. It's not automatically on just because a major provider hosts your mailboxes — check current provider documentation, since managed setup support varies and changes over time.

What's the actual first step? Run your domain through the Domain Scanner to see where you currently stand, then use What is MTA-STS? as the setup reference — it covers the DNS record, the policy file, and the testing-to-enforce rollout in full detail.

About this article

I'm part of the team building grimDMARC, a managed DMARC, SPF and BIMI platform for MSPs and their customers. Questions about MTA-STS, or think I've got the mechanics wrong somewhere above — reach me at hello@grimdmarc.com.

Last updated: August 2026 · Reading time: 11 minutes