MTA-STS and TLS-RPT explained: the DMARC of the transport layer

DMARC answers one question: is this message actually from the domain it claims to be from? It has nothing to say about the wire the message traveled over to get to you. A perfectly authenticated, perfectly aligned email can still cross the internet in plain text, readable to anyone sitting on the path between the two mail servers.

MTA-STS and TLS-RPT are the pair of standards that close that gap. Think of MTA-STS as DMARC for the connection instead of the identity: a domain publishes a policy saying “only deliver to me over verified TLS,” and sending servers that respect it stop silently falling back to unencrypted delivery. TLS-RPT is the reporting half — the rua to MTA-STS’s policy record — telling you when and where that enforcement is actually failing.

The problem: STARTTLS was never a hard requirement

Modern SMTP normally negotiates encryption with STARTTLS: a plaintext handshake where the receiving server offers TLS and the sender may upgrade to it. That word “may” is the whole vulnerability. STARTTLS was designed to be optional and backward-compatible with servers that don’t support encryption at all — which means an attacker positioned on the network path can simply strip the STARTTLS offer out of the conversation. The sending server sees no encryption available, delivers the message unencrypted as if that were normal, and neither side raises an alarm. This is a documented downgrade attack, not a theoretical one, and it’s silent by construction — nothing in a standard STARTTLS failure looks different from a server that genuinely doesn’t support TLS.

DMARC, SPF and DKIM don’t help here. They authenticate the message’s identity once it arrives; they say nothing about whether the trip there was private — see Gmail & Outlook sender requirements for what those three do cover.

MTA-STS: making TLS mandatory instead of optional

MTA-STS lets a domain publish a policy that a compliant sending server checks before it ever attempts delivery. The policy states which mail servers are authorized to receive your mail and requires that the connection to them use TLS with a certificate that actually validates — and, critically, instructs senders to refuse delivery rather than fall back to plaintext if that can’t be satisfied.

Setting it up requires two pieces:

1. A DNS TXT record announcing the policy exists, published at _mta-sts.yourdomain.com:

_mta-sts.yourdomain.com IN TXT "v=STSv1; id=20260724000000Z"

The id value is a version string — bump it any time the policy file changes so caching senders know to re-fetch.

2. An HTTPS-hosted policy file at a fixed, non-negotiable location:

https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

with contents like:

version: STSv1
mode: enforce
mx: mail.yourdomain.com
mx: mail2.yourdomain.com
max_age: 604800

mode is the field that matters most, and MTA-STS gives you exactly the staged rollout DMARC does:

• testing — mail is delivered normally even when TLS fails, but any failure that would have been blocked gets reported via TLS-RPT. This is where every domain should start.
• enforce — a sending server that can’t establish a validated TLS connection to one of your listed MX hosts refuses to deliver, rather than falling back to plaintext.
• none — explicitly turns enforcement off, distinct from simply having no policy at all. A sender that previously cached an enforcing policy sees none and stops enforcing cleanly, instead of holding onto a stale policy with no way to safely relax it.

TLS-RPT: finding out when it’s failing

A policy you can’t observe is a policy you’re trusting blindly. TLS-RPT is the second DNS record, published at _smtp._tls.yourdomain.com:

_smtp._tls.yourdomain.com IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com"

Participating senders that support TLS-RPT then deliver a daily JSON report describing TLS negotiation outcomes toward your domain: how many connections succeeded, how many failed, broken down by failure type (certificate mismatch, expired certificate, MX record mismatch, STARTTLS not offered, and similar), which sending source reported it, and over what period.

That’s the direct MTA-STS/DMARC parallel worth internalizing: _mta-sts is your policy record, the way a DMARC record states a policy; the JSON reports triggered by _smtp._tls are your rua, the way DMARC aggregate reports tell you what’s actually happening against the policy you published. Skip TLS-RPT and you can enforce MTA-STS with no visibility into whether it’s silently blocking legitimate mail from a sender with a misconfigured certificate.

Rolling it out without breaking delivery

The safe order mirrors the DMARC ladder almost exactly:

1. Publish TLS-RPT first, before touching MTA-STS mode. You want reporting live before you change any behavior, so you have a baseline.
2. Publish the MTA-STS policy in testing mode. Nothing blocks yet; you’re only asking cooperating senders to tell you what would have failed.
3. Read the reports for a few weeks. Look for failure types tied to a real MX or certificate problem versus one-off transient issues.
4. Move to enforce once the reports are clean, and keep watching — a certificate that quietly expires or an MX record that changes without updating the policy file will now cause real delivery failures instead of a graceful fallback.

Confirm both DNS records resolve correctly with DNS lookup, and use the MTA-STS checker to validate that your policy file is reachable, well-formed, and actually matches your current MX records before flipping to enforce. If you’re doing this alongside a fresh domain setup, it slots naturally into the same sequencing as SPF, DKIM and DMARC on a new domain — authentication and transport security are separate layers, but there’s no reason not to plan both at once.

Where this fits next to DMARC

MTA-STS and DMARC solve adjacent but different problems, and neither substitutes for the other:

	DMARC	MTA-STS
Protects	Sender identity (the From: header)	The connection in transit
Failure mode it stops	Spoofing — mail claiming to be your domain	Downgrade/interception — mail to your domain sent unencrypted
Reporting companion	rua aggregate reports	TLS-RPT JSON reports
Where it acts	Recipient’s filtering decision	Sender’s connection to your mail server

A domain with a fully enforced DMARC policy and no MTA-STS is still exposed to interception on inbound mail. A domain with MTA-STS enforced and no DMARC is still spoofable. They’re complementary controls, not alternatives — and unlike DMARC’s climb, MTA-STS has no equivalent multi-month enforcement runway once your reports are clean, because it doesn’t have to account for every third-party tool sending mail as you. It only has to account for your own mail servers being correctly configured, which is a much smaller surface to verify. See p=none vs p=quarantine vs p=reject for the DMARC side of that comparison.

Frequently asked questions

Do I need MTA-STS if I already have DMARC?+

Yes, if you want protection against interception in transit rather than just spoofing. DMARC verifies who a delivered message claims to be from; it does not verify that the connection carrying that message to your servers was encrypted. MTA-STS and DMARC address different threats and are meant to run together, not as alternatives.

What happens without MTA-STS?+

Without it, incoming mail to your domain relies on STARTTLS, which is opportunistic rather than mandatory. A sending server that cannot negotiate TLS with your mail servers will typically fall back to delivering the message unencrypted rather than refusing to send it, and an attacker positioned on the network path can force that fallback by stripping the STARTTLS offer, without either party necessarily noticing.

Is MTA-STS the same as DANE?+

No, though they solve a related problem. DANE (DNS-based Authentication of Named Entities) uses DNSSEC and TLSA records to pin certificates. MTA-STS uses a plain DNS TXT record plus an HTTPS-hosted policy file and does not require DNSSEC, which is generally why it has seen easier adoption than DANE despite covering similar ground.

How do I check whether MTA-STS is set up correctly for my domain?+

Check that the _mta-sts DNS TXT record resolves, that the policy file is reachable at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt over valid TLS, that its listed MX hosts match your actual mail servers, and that the mode field reflects what you intend. A dedicated MTA-STS checker tool will validate all of this in one pass rather than requiring you to inspect each piece by hand.

Does Norbelys support MTA-STS?+

MTA-STS and TLS-RPT are properties of your own domain's DNS and mail servers, not of a sending platform, so the relevant question for any sender is whether their own domain has a correct policy published, not whether a particular tool supports the standard. Check your own domain's MTA-STS setup directly with an MTA-STS checker rather than assuming it from your sending platform.