MTA-STS and TLS-RPT Setup Guide: Encrypt Your Email in Transit

Most teams that care about deliverability get SPF, DKIM, and DMARC in place and assume the job is done. Those three standards are essential, but they all answer the same question: is this message really from who it claims to be? None of them answer a second, equally important question: was the message actually encrypted while it traveled between mail servers?

That is the gap MTA-STS fills. It tells sending servers that your domain requires TLS encryption and refuses plaintext delivery. Its companion, TLS-RPT, sends you daily reports whenever a connection fails to negotiate encryption. Together they harden the transport layer that the authentication standards leave untouched. This guide explains what each one does, how they fit with the rest of your setup, and how to publish them safely.

The problem MTA-STS solves

When one mail server hands a message to another, it normally tries to upgrade the connection to TLS using a mechanism called STARTTLS. The trouble is that STARTTLS is opportunistic by default. If the encryption handshake fails, or if an attacker sitting in the middle strips the STARTTLS command out of the conversation, most servers quietly fall back to sending the message in plaintext rather than not delivering it at all.

That fallback is convenient, but it means a determined attacker can force your mail onto an unencrypted path and read or tamper with it in transit. This is known as a downgrade attack, and opportunistic TLS does nothing to stop it.

MTA-STS (Mail Transfer Agent Strict Transport Security) removes the ambiguity. It lets your domain publish a policy that says, in effect, “any server sending mail to me must use TLS with a valid certificate, and if it cannot, it should not deliver at all.” A sending server that supports MTA-STS reads that policy, caches it, and enforces encryption on every future delivery to your domain.

How MTA-STS is published

MTA-STS relies on three pieces working together: a DNS record, a policy file served over HTTPS, and a valid TLS certificate on your mail servers.

1. Publish the DNS TXT record. At the hostname _mta-sts.yourdomain.com, add a TXT record that flags the policy and gives it a version id:

_mta-sts.yourdomain.com  TXT  "v=STSv1; id=20260714000000"

The id is just a version string. You change it every time you update the policy so sending servers know to fetch the new one.

2. Serve the policy file over HTTPS. Sending servers fetch the actual rules from a fixed URL on a dedicated subdomain:

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

The file itself is plain text and looks like this:

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

The mx lines must match the mail servers listed in your MX records. The max_age is how long, in seconds, a sending server may cache the policy (604800 is one week). The mode field is the one that matters most, and it deserves its own section.

3. Make sure your MX hosts have valid TLS certificates. Enforcement only works if your receiving servers actually present trusted, non-expired certificates whose names match your MX hostnames. If a certificate is self-signed or mismatched, enforcing servers will refuse to deliver, so this step is not optional.

Roll out with testing mode first

MTA-STS has three modes, and the safe path is to walk through them in order.

• none disables the policy. Useful when you want to remove MTA-STS without leaving a broken record behind.
• testing tells sending servers to check TLS and report failures through TLS-RPT, but to still deliver the message even if encryption fails. Nothing breaks, and you get visibility.
• enforce is the real thing. Sending servers that support MTA-STS will refuse to deliver over an unencrypted or untrusted connection.

Start in testing mode and leave it there for a couple of weeks. Watch the TLS-RPT reports (covered next) to confirm that legitimate senders are negotiating TLS cleanly and that no valid mail is failing. Only when the reports are clean should you flip the policy file to mode: enforce and bump the id in the DNS record so caches refresh.

Rushing straight to enforce is the most common way to hurt yourself here. A mismatched certificate or a stale MX entry that would have shown up harmlessly in a testing report can instead start blocking real mail.

What TLS-RPT adds

MTA-STS enforces the rule. TLS-RPT (TLS Reporting) is how you find out whether the rule is holding. It is a separate DNS record that asks supporting senders to email you a daily summary of their TLS results with your domain, including any handshake failures, certificate problems, or policy fetch errors.

You publish it as a TXT record at _smtp._tls.yourdomain.com:

_smtp._tls.yourdomain.com  TXT  "v=TLSRPTv1; rua=mailto:[email protected]"

The rua address is where the JSON reports are delivered. Large senders like Google and Microsoft honor TLS-RPT and will send you aggregate data showing how many sessions succeeded, how many failed, and why. That feedback loop is what turns MTA-STS from a fire-and-forget record into something you can actually operate and trust.

One practical note: the mailbox you point rua at will start receiving machine-generated reports from many senders. Route it somewhere monitored, and keep that address clean. The same discipline you apply to your marketing lists applies here, because a reporting mailbox that bounces is a reporting mailbox you stop hearing from. Running your contact addresses through a validation tool like Scrubby before you rely on them keeps those feedback channels healthy.

Where this fits in your wider email setup

Think of your email posture as two layers. The authentication layer (SPF, DKIM, and DMARC) proves identity and stops spoofing. The transport layer (MTA-STS and TLS-RPT) makes sure the pipe carrying your mail is actually encrypted and lets you monitor it. You want both. Publishing MTA-STS without DMARC leaves you open to spoofing, and running DMARC without MTA-STS leaves your mail exposed to downgrade attacks in transit.

Authentication and encryption protect the mail you send and receive, but they do nothing about the quality of the addresses you are sending to. A perfectly encrypted, perfectly authenticated message to a dead or risky mailbox still bounces, and a pile of bounces still drags down the sender reputation all of this work is meant to protect. That is why the teams with the cleanest setups pair strong transport security with disciplined list hygiene, verifying risky and catch-all addresses with Scrubby before a campaign goes out. If your outreach also leans on booked meetings, keeping those invite lists clean before you send through a tool like Kali saves you from burning domain reputation on invalid contacts.

A quick rollout checklist

If you want to move on this today, here is the order that keeps you out of trouble:

1. Confirm every MX host has a valid, trusted TLS certificate.
2. Publish the TLS-RPT record and point rua at a monitored mailbox.
3. Publish the MTA-STS DNS record and serve the policy file in mode: testing.
4. Watch the TLS-RPT reports for one to two weeks and fix anything that surfaces.
5. Switch the policy file to mode: enforce and update the id in DNS.

Do it in that sequence and you get the full protection of enforced encryption without ever risking a delivery outage. Skip the testing phase and you are gambling that nothing in your certificate chain or MX configuration is out of place, which is rarely a safe bet.

Encrypting your mail in transit is one of the last meaningful gaps most senders have left after SPF, DKIM, and DMARC. MTA-STS closes it, TLS-RPT keeps it honest, and clean list hygiene makes sure all that protected mail is actually reaching real people.