MTA-STS and TLS-RPT Explained Without the Jargon

DMARC gets most of the attention in email security, because it protects your domain from spoofing. But there is a separate question that matters just as much once the message is legitimate: was the message transported securely between mail servers?

That is where MTA-STS and TLS-RPT come in.

They are often mentioned together, often implemented late, and almost always explained badly. The short version is simple:

• MTA-STS tells other mail servers that your domain expects encrypted delivery over TLS.
• TLS-RPT tells them where to send reports when secure delivery fails.

They do not replace DMARC. They solve a different problem.

The problem they address

SMTP was designed for an older internet. Modern mail servers usually try to negotiate TLS automatically, but “usually” is not the same as “guaranteed”. If a sending server cannot establish TLS to your receiving server, it may fall back to plaintext delivery or route around the problem, depending on configuration.

For many businesses, that fallback is invisible.

You can be running a well-managed domain and still not know:

• whether inbound mail is consistently delivered over TLS
• whether certificate problems are causing delivery failures
• whether misconfigured DNS is undermining secure transport

MTA-STS adds policy. TLS-RPT adds visibility.

What MTA-STS actually does

With MTA-STS, you publish a DNS record that points to a policy file hosted on HTTPS. That policy tells senders:

• this domain supports secure SMTP delivery
• these MX hosts are valid
• the sender should not fall back if TLS requirements are not met

In plain English: if a sender cannot establish a proper encrypted connection to the mail servers you publish, it should treat delivery as a failure instead of silently downgrading.

A basic DNS record looks like this:

_mta-sts.example.co.za. IN TXT "v=STSv1; id=20260211"

The policy itself is served from:

https://mta-sts.example.co.za/.well-known/mta-sts.txt

A typical policy file:

version: STSv1
mode: enforce
mx: mail.example.co.za
max_age: 86400

What TLS-RPT does

TLS-RPT does not enforce anything. It gives you reports about delivery failures related to TLS.

That matters because once you publish MTA-STS, you need to know when real senders cannot connect securely. TLS-RPT reports tell you about:

• certificate mismatches
• hostname validation failures
• TLS negotiation problems
• policy fetch issues
• MX mismatches

A simple TLS-RPT DNS record:

_smtp._tls.example.co.za. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.co.za"

The reports are machine-readable JSON attachments, not friendly dashboard summaries. You need a process or tool to interpret them.

When should a business bother?

If you are a small domain that only sends mail and does not receive much, MTA-STS may not be the first item on your list. DMARC, SPF, DKIM, and sender inventory still come first.

But MTA-STS becomes increasingly valuable when:

• you receive customer or supplier email that contains sensitive information
• you operate finance, support, or HR workflows by email
• you already have DMARC in place and want stronger end-to-end mail hygiene
• you want clearer evidence of transport issues instead of guessing from bounce messages

For many businesses, the trigger is simple: once email is important enough to protect from spoofing, it is important enough to protect in transit too.

The safest rollout order

MTA-STS is best implemented as a controlled change, not a rushed DNS task.

1. Confirm your MX records are correct

Before you publish anything, verify that your mail routing is stable and intentional. If old MX hosts are still published, fix that first.

2. Check certificate coverage

Your receiving mail hosts need valid certificates that match the names senders will validate.

3. Publish a policy in testing mode first

Start with a lower-risk posture if you are unsure. The policy file supports different modes. enforce is the end state, but you should only use it once you know the published MX set and certificates are correct.

4. Publish TLS-RPT before or alongside enforcement

Reports are how you spot breakage early. Turning on policy without reporting leaves you blind.

5. Monitor for a few weeks

Watch for recurring failures, especially from large senders, finance platforms, or partners with older mail infrastructure.

Common mistakes

Treating MTA-STS like a replacement for DMARC

It is not. MTA-STS secures transport. DMARC secures identity. You want both.

Forgetting the HTTPS policy file

The DNS record alone is not enough. If the policy file is missing, stale, or served incorrectly, senders cannot use it.

Publishing the wrong MX names

If the policy does not match your actual inbound mail hosts, legitimate delivery can fail.

No operational owner

Someone needs to own the policy file, the DNS record, and the reports. Otherwise the setup drifts out of sync the next time mail routing changes.

How this fits with DMARC, SPF, and DKIM

Think of the stack this way:

• SPF says which servers may send.
• DKIM signs the message.
• DMARC tells receivers how to treat failures and reports on abuse.
• MTA-STS says valid messages must reach you over proper TLS.
• TLS-RPT tells you when that secure transport fails.

That is why mature email security programs eventually include all of them. Each closes a different gap.

A simple decision rule

If your team is still cleaning up sender sprawl, broken SPF records, or missing DKIM, handle those first.

If your domain already has basic authentication in place and email is operationally important, MTA-STS and TLS-RPT are sensible next steps.

Final takeaway

MTA-STS and TLS-RPT are not flashy. They are quiet infrastructure controls. But they reduce uncertainty in one of the most business-critical channels most companies have.

Start with accuracy: correct MX records, correct certificates, correct policy hosting. Then add reporting, monitor failures, and move toward enforcement once you trust what you published.

If you are already monitoring DMARC but have never reviewed transport-layer protections, that is the next worthwhile layer to assess alongside your broader domain posture.