SPF and DMARC stop criminals from sending email as you. MTA-STS stops attackers from intercepting email sent to you. They defend different things, and you need all three. Here’s what each one actually protects against — and why MTA-STS, the one almost nobody has enabled, is the obvious next step.

The two problems with email

Email was designed in a more trusting era, and it ships with two structural weaknesses:

1. Anyone can claim to be you. Nothing in plain SMTP stops a spammer from putting @your-domain.com in the “From” line and blasting out invoices or password-reset phishing. This is spoofing.
2. Mail in transit can be intercepted. SMTP encryption (STARTTLS) is opportunistic — an active attacker on the network can strip it away or redirect the connection, and the sending server will quietly fall back to plaintext. This is a downgrade / man-in-the-middle attack.

SPF and DMARC address the first problem. MTA-STS addresses the second. They are complementary, not alternatives.

At a glance

Control	What it protects	Threat it combats
SPF	Which servers may send as your domain	Spammers sending from unauthorised servers using your domain
DMARC	The visible “From:” address users actually see	Direct-domain spoofing & phishing; tells receivers to reject forgeries
MTA-STS	Mail in transit to your servers	STARTTLS downgrade/stripping & man-in-the-middle interception

SPF — say which servers are allowed to send as you

SPF (Sender Policy Framework) is a DNS TXT record listing the mail servers permitted to send email for your domain:

v=spf1 include:_spf.google.com include:servers.mcsv.net -all

When a receiving server gets a message claiming to be from you, it checks the sending server’s IP against this list. Threat combated: a spammer sending from some random server while forging your domain in the envelope — SPF lets the receiver say “that server isn’t on the list” and reject it.

Its limits (and why SPF alone isn’t enough): SPF only checks the hidden “envelope sender”, not the “From:” address the human reads — so an attacker can pass SPF on their own domain while still showing your name in the From line. SPF also breaks when mail is forwarded. End the record with -all (hard-fail), not ~all (soft-fail), once you’re confident your record is complete.

DMARC — protect the address people actually see, and enforce it

DMARC (Domain-based Message Authentication, Reporting & Conformance) closes SPF’s gap. It ties authentication to the visible From: header (called alignment), tells receivers what to do with messages that fail, and sends you reports. It builds on SPF and DKIM (the cryptographic signature that proves a message wasn’t forged or tampered with in flight).

v=DMARC1; p=reject; rua=mailto:[email protected]

Threat combated: exact-domain impersonation — the CEO-fraud / fake-invoice / credential-phishing emails that put your real domain in the From line. With DMARC at enforcement, receiving mail systems quarantine or reject those outright.

The trap: p=none protects nothing. A DMARC record at p=none only collects reports — it tells receivers to take no action on forgeries. It’s a useful first step for visibility, but you must progress to p=quarantine and then p=reject to actually block impersonation. In our scan of the top million domains, ~45% of mail domains published DMARC but only ~20% actually enforced it — most are stuck at none, getting little protection.

Its limit: DMARC stops spoofing of your exact domain. It doesn’t stop look-alike “cousin” domains (your-d0main.com), and — crucially for what comes next — it does nothing about whether the message is encrypted in transit.

MTA-STS — the step almost everyone is missing

SPF and DMARC are about identity. They say nothing about confidentiality in transit. When another mail server sends a message to you, it looks up your MX records and opens an SMTP connection. TLS on that connection is opportunistic: if the server offers STARTTLS, great — but if an attacker sitting on the network path strips the STARTTLS offer, or redirects the connection to a server they control, the sender simply delivers your mail in cleartext, to the wrong place, with no warning.

MTA-STS (SMTP MTA Strict Transport Security) fixes this. You publish a policy that says: “Mail to my domain MUST be delivered over TLS, with a valid certificate matching my published MX hosts. If you can’t do that, don’t deliver — fail closed.” The policy is served over HTTPS at https://mta-sts.your-domain.com/.well-known/mta-sts.txt and advertised with a small DNS TXT record at _mta-sts.your-domain.com.

version: STSv1
mode: enforce
mx: mail.your-domain.com
max_age: 604800

Threat combated: active interception of inbound email — STARTTLS-stripping downgrade attacks and man-in-the-middle redirection. With MTA-STS in enforce mode, a compliant sender (Google, Microsoft and others honour it) will refuse to hand your mail to an attacker in plaintext.

Why MTA-STS and not DANE? DANE achieves similar transport security but requires DNSSEC, which is operationally demanding and risky to run (a bad key rollover takes your whole domain offline). MTA-STS deliberately leans on the same Web PKI / HTTPS trust you already use for your website — no DNSSEC required. For most organisations it’s the pragmatic way to get enforced SMTP encryption. Pair it with TLS-RPT (a _smtp._tls TXT record) to receive reports of delivery/TLS failures.

Despite being easy and low-risk, MTA-STS is the rarest of these controls by a wide margin — in our top-million scan barely 1% of mail domains had it. That makes it the single highest-leverage improvement most organisations can make to their email security right now.

The recommended baseline

1. SPF — publish a complete record ending in -all.
2. DKIM — enable signing on your mail platform (the cryptographic half DMARC relies on).
3. DMARC — start at p=none with rua reporting to see your traffic, then move to p=quarantine and finally p=reject. Publishing it is not the goal; enforcing it is.
4. MTA-STS — publish an enforce policy (plus TLS-RPT for visibility). This is the step most domains are missing.

SPF and DMARC protect the rest of the world from email forged in your name. MTA-STS protects the email people send to you. Together they cover both the identity and the confidentiality of your mail — and the first three without the fourth leaves the wire wide open.

Adoption figures from a scan of the full Majestic Million (top one million domains): of domains that run mail, ~86% publish SPF, ~57% publish DMARC (only ~26% at an enforcing policy), and ~1% publish MTA-STS.