MTA-STS / TLS-RPT for the security-curious

The problem MTA-STS solves

SMTP, the protocol mail servers use to talk to each other, has supported opportunistic TLS for over two decades — a feature called STARTTLS. The handshake goes like this: a sending mail server connects to a receiving one, the receiver advertises "I support encryption," and the sender upgrades the connection to TLS before delivering the message.

The catch: that "I support encryption" announcement happens BEFORE the connection is encrypted, so a network attacker between the two servers can strip it out. The sending server then sees no encryption advertised, falls back to plaintext, and delivers the message in clear. Both servers think they did the right thing. The attacker reads (or modifies) the mail.

This is called a downgrade attack, and it's been used in practice — most famously by various nation-state actors and ISPs that intentionally strip STARTTLS announcements at the network edge to keep mail readable in transit.

MTA-STS (RFC 8461, "SMTP MTA Strict Transport Security") fixes the opportunistic-encryption problem by letting your domain publish a policy that says: any sender attempting to deliver to me MUST use TLS. If the connection can't be encrypted, the sender refuses to deliver. Downgrade attempts are rejected at the source.

How MTA-STS actually works — the two halves

MTA-STS is a two-part protocol. Both halves have to be live for it to work, and missing one creates an explicitly broken state ("DNS orphan" or "policy orphan") worse than not deploying at all.

Half 1: a DNS TXT pointer

At _mta-sts.<your-domain> you publish a TXT record that looks like:

v=STSv1; id=20260429T120000

The id is an arbitrary version string — typically a timestamp. When you change the policy file (the second half), you bump the id so receivers know to re-fetch.

Half 2: an HTTPS-served policy file

At https://mta-sts.<your-domain>/.well-known/mta-sts.txt you serve a plain-text file with the actual policy:

version: STSv1
mode: testing
mx: *.protection.outlook.com
max_age: 604800

The interesting fields:

• mode — one of none / testing / enforce. See the next section.
• mx — the list of MX hostnames that are valid receivers for this domain. Wildcards allowed. Typically copied from your published MX records.
• max_age — how long (in seconds) senders should cache the policy. Common values are 86400 (1 day) for early-deployment caution and 604800 (1 week) once you're confident.

The HTTPS hosting requirement is the rough part. You need a real webserver with a valid certificate at mta-sts.<your-domain> serving a static text file. For most SMBs that don't have a webserver there, this means standing one up just for MTA-STS — which is why deployment is so much rarer than DMARC.

The three modes — and why "testing" exists

none

Effectively "MTA-STS is off." If you're winding down a deployment, set mode to none for the max_age window before removing the records entirely. Most domains never use this.

testing

Receivers are told to attempt TLS with the listed MX hostnames but deliver anyway if the connection can't be secured — and report the failures via TLS-RPT. This is the on-ramp. You see what would have happened under enforcement without actually breaking any mail.

Almost every fresh MTA-STS deployment should start here. Run for a couple of weeks, watch the TLS-RPT reports, fix anything that's misconfigured, then promote.

enforce

Receivers MUST connect over TLS to a listed MX. Connections that can't be encrypted are refused; mail that would have been delivered over a downgraded connection now bounces. This is the actual protection. Get there only after a clean run of testing-mode reports.

TLS-RPT — the reporting channel

TLS-RPT (RFC 8460) is to MTA-STS what aggregate reports are to DMARC. It gives you visibility into how senders are interacting with your encryption policy.

Setup is one TXT record at _smtp._tls.<your-domain>:

v=TLSRPTv1; rua=mailto:tls-reports@example.com

Receivers that detected TLS issues — failed handshakes, certificate problems, downgrade attempts, missing MX — send daily JSON reports to that address. The reports are much simpler than DMARC reports: a small number of well-defined failure types, with counts and the IPs involved.

TLS-RPT works whether or not you've deployed MTA-STS. Publishing just the reporting record gets you visibility into your inbound TLS health without the deployment complexity of MTA-STS itself. It's a good first step on its own.

When you should actually bother

Honest answer: most SMBs don't strictly need MTA-STS. Mail providers (Google, Microsoft, etc.) already negotiate TLS opportunistically with each other, and the population of attackers actively running downgrade campaigns against random small businesses is small.

Where MTA-STS earns its complexity:

• Healthcare — HIPAA covered entities transmit PHI by email; downgrade exposure is a compliance concern, not just a security concern.
• Legal / financial services — privileged communications, regulated data flows.
• Critical infrastructure / energy / defense — known active targets for state-aligned attackers, who absolutely do run downgrade campaigns.
• High-value B2B — anyone whose contracts and pricing flow via email and would be valuable to a competitor or counterparty intercepting them.
• EU-based businesses — GDPR's "appropriate technical measures" framing pushes toward maximum-feasible encryption; MTA-STS is an easy point on a checklist.

For a coffee shop's marketing newsletter or a corner-store invoicing workflow, MTA-STS is overkill — DMARC + DKIM is the right set. For a small clinic, a wealth-management firm, a contracts-heavy B2B SaaS — yes, deploy it.

Why we don't auto-publish MTA-STS for you (yet)

DMARC and SPF live entirely in DNS — we can update them via your DNS provider's API and we're done. MTA-STS needs that HTTPS-served policy file, which means we'd need to host mta-sts.<your-domain> on infrastructure under our control, provision a TLS certificate for it, and serve the policy text. That's a real infrastructure commitment — wildcard certs, custom hostnames, and ongoing ops.

We're planning to ship that as a V3 feature. When it lands, you'll be able to enable MTA-STS for any domain we monitor with one click — we'll publish both halves (the DNS pointer and the policy file) at the same time, and keep the policy in sync as your MX list changes. Until then we monitor externally-published MTA-STS policies and surface anomalies (DNS orphan, policy orphan, stuck in testing mode for too long, max_age too short) on the MTA-STS tab.

Why not just publish the DNS pointer half today? Because it'd create a DNS orphan state — receivers see the pointer, try to fetch the policy file, get a 404, and treat MTA-STS as broken. That's worse than no record at all. Publishing only the DNS half without the matching HTTPS endpoint actively degrades your mail security posture rather than improving it. Same logic explains why our auto-fix flow deliberately doesn't include an MTA-STS DNS-pointer auto-publish — it'd land the customer in the orphan state by default.

The minimal-pain deployment path

For the SMB who decided they do want MTA-STS today and is willing to do the work:

1. Stand up a static-file host at mta-sts.<your-domain>. Cloudflare Pages, Netlify, GitHub Pages with a custom domain, or a tiny S3 + CloudFront bucket all work. The file is small, traffic is essentially zero. Provision a real TLS certificate (the platforms above all do this for free).
2. Publish the policy file at /.well-known/mta-sts.txt with mode: testing and your current MX list. Use a 1-day max_age while you're confirming things work.
3. Publish the DNS TXT pointer at _mta-sts.<your-domain>. The id field is any string; most teams use a timestamp.
4. Publish the TLS-RPT TXT pointer at _smtp._tls.<your-domain> with rua=mailto: set to a monitored inbox.
5. Wait two weeks. Read the TLS-RPT reports. Investigate any failures — usually a forgotten secondary MX without TLS, or a misconfigured cert.
6. Once reports are clean for a week, bump the policy file to mode: enforce and the max_age to a week or longer. Increment the id field. Done.

Related

• What is DMARC? — the authentication side of email security.
• How we update DNS records on your behalf, safely — why we don't currently auto-publish MTA-STS even though we could.
• Why 1024-bit DKIM keys are being phased out — a closer-to-home email-security item with real urgency.