MTA-STS and TLS-RPT: A Practical MSP Guide

The gap DMARC leaves open

SPF, DKIM, and DMARC are authentication mechanisms. They establish that a message genuinely originated from a domain and that its contents were not altered in transit. What they do not establish is that the connection carrying that message was encrypted, or that the receiving server on the other end was the right one.

SMTP handles encryption through STARTTLS, which is opportunistic by design. A sending server connects in the clear, asks whether the receiver supports TLS, and upgrades the connection if it does. The weakness is in that negotiation. An attacker positioned between the two servers can strip the STARTTLS capability from the receiver's response, and a sending server that was willing to encrypt will quietly fall back to plaintext instead. Nothing is logged as an error. The message is delivered. It is simply delivered unencrypted.

The second problem is that MX lookups are unauthenticated on the vast majority of domains. Without DNSSEC, an attacker who can influence a DNS response can point a sender at a mail server of their choosing. The sending server has no baseline to compare against — it asked DNS where to deliver, and it is delivering there.

Why this matters commercially, not just technically:

For most MSP clients the realistic threat is not a nation-state on the wire. It is that "we enforce encryption in transit" appears in their security questionnaires, their cyber insurance renewals, and increasingly in their clients' vendor assessments — and opportunistic STARTTLS does not actually support that claim. MTA-STS is what turns it from an aspiration into something you can evidence.

What MTA-STS actually does

MTA-STS lets a domain publish a policy that says, in effect: mail for this domain must be delivered over TLS, to one of these named hosts, presenting a certificate that validates against those names. A sending server that supports MTA-STS fetches that policy, caches it, and applies it on every subsequent delivery. If the connection cannot meet the policy, a sender in enforcing mode does not fall back to plaintext — it defers or bounces the message.

That cached policy is the important part. Once a sender holds a valid policy for your domain, an attacker stripping STARTTLS no longer wins, because the sender already knows encryption is required. The policy is retrieved over a channel the attacker does not control, and it persists.

There are three moving parts, and all three have to be right:

The three components:

A DNS TXT record at _mta-sts.example.com containing a version tag and a policy ID. The ID is how senders know the policy changed.
A policy file served over HTTPS at https://mta-sts.example.com/.well-known/mta-sts.txt, on a host with a valid certificate.
A cache lifetime — the max_age value in the policy, which determines how long senders hold onto it.

A minimal policy file for a Microsoft 365 tenant looks like this:

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

And the accompanying DNS record:

_mta-sts.example.com.  IN TXT  "v=STSv1; id=20260903120000"

The mx lines must match the hosts in the domain's actual MX records, wildcards included. Google Workspace domains list the Google inbound hosts instead. If a client runs a hybrid setup, or routes through a security gateway before the mailbox provider, every host in that path that receives mail for the domain needs to be represented.

The three modes, and why you start in testing

The mode field takes three values, and they map closely onto the DMARC progression your clients have already been through.

testing — senders evaluate the policy and report failures, but still deliver. This is p=none for transport.
enforce — senders refuse to deliver over a connection that fails the policy. This is where the protection actually happens.
none — an explicit withdrawal. This is how you retire a policy safely rather than deleting the record.

That last one deserves emphasis, because it is the escape hatch. If you need to back out of MTA-STS, publishing a policy withmode: none and a new ID tells senders to stop enforcing. Simply deleting the DNS record does not, because senders that already hold a cached enforcing policy will keep applying it until it expires.

TLS-RPT: the visibility you need before enforcing

Deploying MTA-STS without reporting is the transport equivalent of jumping straight to p=reject. You would be enforcing a policy with no data on what it will break.

TLS-RPT solves that. It is a single DNS TXT record that asks sending servers to send you aggregate reports about their TLS negotiations with your domain:

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

Participating senders — which includes the large providers that account for most inbound mail — send a daily JSON summary of successful and failed TLS sessions, including the specific failure type: certificate name mismatch, expired certificate, STARTTLS negotiation failure, or a policy that could not be fetched. Unlike DMARC aggregate reports, the volume is low, because you get one report per sending organisation per day rather than a stream keyed on every sending source.

Publish TLS-RPT first, on its own:

TLS-RPT is useful with no MTA-STS policy at all. It costs one DNS record, carries no delivery risk whatsoever, and immediately tells you whether a client's mail flow already has TLS problems. For a client estate you have just taken over, it is one of the cheapest pieces of visibility available — and it gives you a baseline before you change anything.

A rollout order that will not page you at 2am

The sequence below is deliberately slow, and the slowness is the point. Every step before enforcement is reversible within minutes; enforcement itself is not, because of policy caching.

1.Publish TLS-RPT. One TXT record. Wait a week and read the reports. If the client already has TLS failures, fix those before going further.
2.Stand up the policy host. Get mta-sts.<domain> serving over HTTPS with a valid certificate and automated renewal. Confirm the file is reachable and served as plain text before it matters.
3.Publish in testing mode with a short max_age — 86400 is a sensible start. Nothing can break in this mode.
4.Read the reports for two to four weeks. You are looking for policy failures from legitimate senders — anything that would have been a bounce under enforcement.
5.Switch to enforce, keeping max_age low. Bump the ID. Watch reports daily for the first week.
6.Raise max_age once stable. A longer cache is stronger protection, because it narrows the window in which a sender has no policy. Raise it only when you trust the setup.

Note the tension in that last step. A long max_ageis better security and worse operability. Start short while you are still learning the client's mail flow, and lengthen it once the setup has survived a few weeks and a certificate renewal.

Where it breaks in production

Most MTA-STS incidents are not exotic. They come from the same handful of operational gaps, and every one of them is predictable enough to design against.

The failure modes worth planning for:

The certificate on the policy host expires. This is the big one, and it is nastier than it looks: senders holding a cached enforcing policy keep enforcing, but can no longer refresh it. The mta-sts subdomain must be in the same certificate automation as everything else you manage — not a manual renewal someone set a calendar reminder for.
A mail platform migration changes the MX records. Moving a client from Microsoft 365 to Google Workspace, or introducing a security gateway, changes the hosts mail arrives at. If the MTA-STS policy still lists the old ones, senders in enforcing mode stop delivering. The policy has to be part of the migration runbook, updated before the MX cutover.
The policy file changes but the ID does not. Senders key their cache on the ID in the DNS record. Edit the policy without bumping the ID and your change is invisible until caches expire naturally. Make the ID a timestamp and regenerate it on every edit.
The policy is served via a redirect. A common accident when the mta-sts host is pointed at an existing site that redirects everything to a canonical hostname. Senders fetch the policy directly and do not follow redirects, so the fetch fails and the policy never applies.
Nobody reads the reports. TLS-RPT only helps if the aggregate reports are parsed and surfaced. A mailbox that fills with gzipped JSON attachments nobody opens is not monitoring.

Doing this across an estate, not one domain

Everything above is manageable for a single domain. The MSP problem is that it is not one domain — it is fifty, or three hundred, each with its own DNS zone, its own mail platform, its own certificate, and its own migration schedule. The per-domain work is small; the coordination is what does not scale.

Three things make the difference between a policy you deployed once and a policy that stays correct.

The first is treating the certificate on eachmta-sts host as production infrastructure. It is easy to stand up and easy to forget, because nothing appears broken when it lapses — right up until a policy needs refreshing. Automated issuance and renewal, with expiry monitoring and alerting, is the only version of this that survives a year.

The second is linking MX changes to policy changes. If your DNS management and your MTA-STS policies live in separate systems, the gap between them is where outages come from. When a change to a client's MX records raises a flag against that client's transport policy, migrations stop being a silent risk.

The third is aggregating TLS-RPT across clients rather than per mailbox. One view of transport failures across every domain you manage turns reporting into something you can actually act on — and, not incidentally, into something you can show a client during a quarterly review.

Manage DMARC, DNS, and certificates from one platform

Albaspot combines DMARC monitoring, DNS management, certificate automation, and domain oversight across every client — so transport policies, MX records, and the certificates behind them stay in one place.

Create account

Is it worth it for every client?

Honestly, no — not on day one. If a client is still sitting atp=none with unresolved sending sources, DMARC enforcement is a better use of the same hour. Authentication failures are actively exploited far more often than transport downgrades.

But TLS-RPT is close to free, and it is worth publishing on every domain you manage regardless of where that client sits on the DMARC journey. It costs one record, risks nothing, and tells you about problems you would otherwise never see. MTA-STS enforcement then makes sense for the clients where it matters most — those handling regulated data, those answering security questionnaires, and those already atp=reject who are looking for the next thing to put in the report.

MTA-STS and TLS-RPT: Closing the Transport Gap After DMARC