MTA-STS & TLS-RPT Setup Guide: Stop Silent Mail Downgrades

You've got SPF, DKIM and DMARC sorted, and DMARC is sitting happily at p=reject. Good — that stops people from spoofing your domain. But there's a gap none of those three touch: what happens to the connection your mail travels over once it leaves the sender's server. If an attacker on the network path can force that connection down to plaintext, your DMARC setup does nothing to help. That's the job MTA-STS and TLS-RPT do, and it's the one most admins skip because nobody explains it in plain terms.

What Problem Are We Actually Fixing

SMTP was never designed with mandatory encryption. When one mail server hands a message to another, they negotiate STARTTLS — but if that negotiation fails, is blocked, or is stripped by something sitting between the two servers, most mail transfer agents will happily fall back to sending the message in plaintext. No error, no bounce, no alert. The message just goes out unencrypted and nobody notices.

This is called a STARTTLS downgrade attack, and it's been demonstrated against real mail providers. MTA-STS (Mail Transfer Agent Strict Transport Security) closes that hole by telling sending servers: "only deliver to me over a verified, encrypted connection — if you can't, hold the message, don't fall back." TLS-RPT (TLS Reporting) is the companion piece that gives you visibility — daily reports from senders like Google and Microsoft telling you where TLS negotiation succeeded or failed.

MTA-STS vs TLS-RPT: What Each One Actually Does

You can run TLS-RPT on its own to get visibility before you commit to MTA-STS enforcement. That's actually the order I'd recommend if you're doing this for the first time.

Before You Start

Check two things first:

• Your mail server (Postfix, Exim, or whatever's handling inbound mail) already supports STARTTLS with a valid certificate — not self-signed, not expired. If you're on Getwebup VPS mail hosting with Postfix + Let's Encrypt, you're covered.
• Your MX hostname matches the certificate's CN or SAN. If your MX is mail.yourdomain.com but the cert is issued for yourdomain.com only, MTA-STS validation will fail and mail will start bouncing once you enforce it. Fix the cert before you touch DNS.

Step 1 — Publish the TLS-RPT Record (Do This First)

Add this TXT record in your DNS zone (WHM/cPanel Zone Editor, or wherever your nameservers live):

Host: _smtp._tls.yourdomain.com
Type: TXT
Value: v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com

Use a mailbox that can handle a moderate volume of automated JSON reports — don't point it at your main inbox. Some admins pipe it into a dedicated address or a third-party parser like Postmark's or Uriports' free tier, which turns the raw JSON into a readable dashboard.

Step 2 — Publish the MTA-STS DNS Record

Host: _mta-sts.yourdomain.com
Type: TXT
Value: v=STSv1; id=2026072601

The id value is arbitrary — bump it (a timestamp works well) every time you change the policy file in Step 3, so caching resolvers know to re-fetch it.

Step 3 — Host the Policy File

MTA-STS requires an HTTPS-reachable file at a fixed, non-negotiable path:

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

That subdomain needs its own valid SSL certificate — if you're on cPanel, add it as a subdomain and run AutoSSL, or issue it via Let's Encrypt/certbot if you're managing it from a VPS. The file itself is plain text, not HTML:

version: STSv1
mode: testing
mx: mail.yourdomain.com
max_age: 604800

Set mode: testing to start. In testing mode, senders report failures via TLS-RPT but still deliver mail even if the TLS check fails — nothing bounces. That's your safety net while you confirm everything's configured correctly. List every MX hostname you actually use; if you have a backup MX, add a second mx: line for it.

Step 4 — Verify Before You Enforce

Check the policy file is reachable and correctly served:

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

It must return with a valid TLS handshake and Content-Type: text/plain (some web servers serve .txt as application/octet-stream, which some validators reject — check your .htaccess or Nginx config if needed). Then confirm the TXT records propagated:

dig +short TXT _mta-sts.yourdomain.com
dig +short TXT _smtp._tls.yourdomain.com

Give it a week in testing mode. Watch the TLS-RPT reports landing in your mailbox — they'll show up as JSON (often gzipped) from Google, Microsoft, and other major providers within a few days. Look for a result-type of success across the board before moving on.

Step 5 — Switch to Enforce Mode

Once the reports look clean, edit the policy file:

mode: enforce

Bump the id in your DNS TXT record so the change gets picked up, and you're done. From here, any sender that respects MTA-STS (Gmail and Outlook both do) will refuse to deliver to you over an unencrypted or improperly-certified connection.

Common Errors and How to Fix Them

Prevention: Keep It From Silently Breaking Later

• Set a calendar reminder before your mta-sts subdomain's certificate expires — a lapsed cert on that one subdomain will start silently bouncing all your inbound mail from MTA-STS-respecting senders.
• Any time you add or change an MX record, update the policy file's mx: list and bump the DNS record's id in the same change window.
• Keep receiving and glancing at TLS-RPT reports even after enforce mode is stable — a sudden spike in failures is often the first sign of a cert renewal that didn't go through.