MTA-STS & TLS-RPT Lookup

What is MTA-STS?

Mail Transfer Agent Strict Transport Security (RFC 8461) forces sending mail servers to use TLS — and to verify the recipient's certificate — when delivering to your domain. Without it, SMTP starts in plaintext and opportunistically upgrades to TLS via the STARTTLS command, which means a man-in-the-middle can strip the upgrade by intercepting the EHLO response. MTA-STS removes the optionality: if the policy says enforce, the sender either uses TLS with a valid certificate or refuses to deliver.

How MTA-STS works

There are two pieces. First, a TXT record at _mta-sts.yourdomain.com announces that you have a policy and gives it an ID. When the ID changes, senders know to re-fetch. Second, the policy itself lives at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt — a plain-text file with three fields:

• mode — enforce (reject on TLS failure), testing (collect reports but still deliver), or none (tombstone a previous policy).
• mx — one line per MX hostname or wildcard pattern the policy applies to. Senders must check this matches the MX record they actually resolved.
• max_age — how long senders should cache the policy. The recommended range is one week to one month.

The HTTPS-hosted policy file is the genius bit: it removes the need for DNSSEC by using the existing web PKI to validate authenticity. Anyone who can MitM your DNS still can't forge a policy without a valid TLS certificate for mta-sts.yourdomain.com.

What is TLS-RPT?

SMTP TLS Reporting (RFC 8460) is the feedback loop. Receivers send aggregate reports to a destination you publish in _smtp._tls.yourdomain.com, telling you how many TLS connections succeeded, how many failed, and why. Without TLS-RPT, you don't find out about TLS problems until your users complain — with it, you get a daily JSON report and a quick path to debugging certificate expiry, downgrade attacks, or misconfigured intermediaries.

The record is short: v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com. Reports can also go to an https:// endpoint if you'd rather receive them via webhook.

MTA-STS vs DANE

Both standards enforce TLS for email — they take different paths to get there. DANE uses DNSSEC-signed TLSA records to pin certificates, which is cryptographically stronger but requires DNSSEC, which still isn't universal. MTA-STS sidesteps DNSSEC by hosting the policy over HTTPS, relying on the web PKI. Most operators deploy MTA-STS because it's easier; the largest email providers (Google, Microsoft, Yahoo) all publish MTA-STS policies. If you have DNSSEC working anyway, you can — and arguably should — publish both.

The email security stack

Each layer answers a different question. SPF says "this IP is allowed to send for this domain." DKIM says "this message was signed by this domain and not modified." DMARC says "if SPF or DKIM aligns, deliver — otherwise apply this policy." BIMI says "and when all of that passes, show the brand." MTA-STS says "and the delivery itself must use TLS — no downgrades." TLS-RPT says "and tell me when it doesn't." Together they close the gap that opportunistic STARTTLS leaves wide open.