MTA-STS and TLS-RPT: How to Enforce Secure Email Delivery with DNS Records

Why Email Encryption Still Fails (and How MTA-STS Fixes It)

Email was never designed with security in mind. The SMTP protocol can negotiate TLS encryption between servers, but it's opportunistic—if the receiving server doesn't offer TLS, the message is sent in plain text. Attackers can easily downgrade the connection or intercept emails via man-in-the-middle attacks. That’s where MTA-STS (Mail Transfer Agent Strict Transport Security) and TLS-RPT (TLS Reporting) come in. They shift from “opportunistic TLS” to “mandatory TLS” by using DNS records and a policy file.

What Is MTA-STS?

MTA-STS is a standard that tells external mail servers: “You must use TLS when sending email to my domain, or don’t send at all.” It works by publishing a policy (a JSON-like text file) on your web server at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. That policy specifies which servers are authorized and what happens if TLS fails.

But how do other email servers find that policy? Through a DNS TXT record on _mta-sts.yourdomain.com. This record points to the policy ID (a version number), ensuring the policy can be fetched over HTTPS. The pairing of a DNS record and an HTTPS-hosted policy makes MTA-STS resilient to DNS spoofing: the policy itself must be served securely.

What Is TLS-RPT?

TLS-RPT is the reporting companion to MTA-STS. Even with a perfect policy, you need to know when delivery fails. TLS-RPT defines another DNS TXT record (_smtp._tls.yourdomain.com) that tells other mail servers where to send aggregate reports about TLS connection attempts. These reports contain details like failure rates, certificate errors, and successful deliveries. Without TLS-RPT, you’re flying blind.

Together, MTA-STS and TLS-RPT give you both enforcement and visibility—two pillars of modern email security. Think of them as the DMARC equivalent for SMTP transport.

How to Set Up MTA-STS and TLS-RPT (Step by Step)

Follow these steps to implement both standards for your domain (example.com).

Step 1: Create the MTA-STS Policy File

On a web server that hosts your domain, create a file at the following path: /.well-known/mta-sts.txt (note: it must be served over HTTPS and accessible from the subdomain mta-sts.yourdomain.com).

Here’s a sample policy:

version: STSv1
mode: enforce
mx: mail.example.com
mx: mx.backup.example.com
max_age: 86400

• mode: Use testing first to see reports without blocking email; switch to enforce later.
• mx: List all mail exchange servers for your domain.
• max_age: How long (in seconds) recipients should cache the policy. 86400 (1 day) is a safe starting point.

Upload this file to the web root of your mta-sts subdomain. Ensure the HTTPS certificate is valid—use a tool like SSL Checker to verify.

Step 2: Add the MTA-STS DNS TXT Record

In your DNS zone, create a TXT record for _mta-sts.example.com with a value that matches the policy ID. For the policy above, use:

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

The id can be any version string (e.g., a date). Increase it every time you change the policy file. Mail servers fetch mta-sts.txt only when they see a new id, so bump the id on every deploy.

Step 3: Add the TLS-RPT DNS TXT Record

Now create a TXT record for _smtp._tls.example.com to define where reports are sent. Example:

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

The rua URI points to an email address that will receive aggregate reports in JSON format. You can also use https:// URIs if your reporting service supports it. Make sure the mailbox is monitored—these reports are essential for troubleshooting.

Real-World Example: Deploying for a Small Business

Let’s say you run shop.example. Your mail is handled by mail.shop.example and backup.shop.example. You start in testing mode for two weeks. During that time, TLS-RPT returns aggregate reports showing that 2% of incoming connections fall back to plain text because an old partner’s server lacks TLS. Armed with that data, you contact the partner to upgrade. After confirming no critical failures, you change the policy mode to enforce and bump the policy id.

Remember: DNS propagation takes time. Check your records using a DNS Analyzer to confirm they resolve correctly before relying on them.

Practical Tips for a Smooth Deployment

• Start in testing mode for at least 1–2 weeks. Monitor reports before switching to enforce.
• Keep TLS-RPT reports separate from your main inbox. Use a dedicated mailbox or an external reporting service that aggregates JSON for you.
• Update your policy id every time you modify the mta-sts.txt file. Otherwise, cached policies won’t be refreshed.
• Validate your HTTPS setup. The MTA-STS policy must be served over a valid TLS connection. Use an SSL checker to confirm.
• Align with DMARC. Though separate, MTA-STS and DMARC both benefit from a monitoring feedback loop. Consider reviewing your domain’s overall health with a Domain Analyzer.

Common Mistakes to Avoid

• Forgetting the subdomain. The policy must be on mta-sts.yourdomain.com, not the bare domain. Similarly, DNS records must use the underscore prefixes.
• Setting max_age too high during testing. Start with a low value (e.g., 300) to allow quicker rollback if something breaks.
• Using an invalid HTTPS certificate. A broken policy fetch makes MTA-STS pointless; mail servers will see it as a TLS failure.
• Ignoring TLS-RPT reports. If you don’t act on reports, you’re missing the main benefit of visibility.

Why Bother? The Real Impact

MTA-STS and TLS-RPT are still underutilized, but major email providers like Google and Microsoft already enforce them for their own domains. As a domain owner, implementing these standards tells the world you take security seriously. It also protects your recipients from email spoofing and eavesdropping.

More importantly, as email servers increasingly check counterparties for MTA-STS policies, having one in place can improve deliverability. Sending servers that honor MTA-STS will refuse to deliver to domains that lack encryption—which could actually hurt your inbox placement if you don’t have a policy. So adopt early.

Conclusion

MTA-STS and TLS-RST—sorry, TLS-RPT—are powerful, underrated tools in your email security toolkit. They’re relatively easy to implement: a policy file on your web server and two DNS TXT records. With a cautious rollout, testing mode, and report monitoring, you can lock down email delivery without breaking existing flows.

Ready to check your current DNS setup? Use the DNS Analyzer on Whose.Domains to verify that your new records propagate correctly. And once you’ve deployed, don’t forget to review the reports—they’re your window into how the internet sees your email infrastructure.