MTA-STS and TLS-RPT Guide: Enforce TLS for Inbound Email

Email servers usually try to encrypt connections with STARTTLS, but by default that encryption is opportunistic: if an attacker strips the STARTTLS offer or presents a bogus certificate, the sending server quietly falls back to plaintext. MTA-STS (RFC 8461) fixes this by letting you publish a policy saying "mail to my domain must use validated TLS". TLS-RPT (RFC 8460) adds reports so you can see failures. Together they protect inbound mail against downgrade and interception, at the cost of a small web server and some care.

What each piece does

MTA-STS applies to mail sent to you. A sending server that supports it fetches your policy over HTTPS, remembers it for max_age seconds, and then refuses to deliver to any MX host that does not present a valid certificate for a name allowed by the policy. Large providers such as Google validate MTA-STS when sending, though support across the whole mail ecosystem is not universal. Check your recipients' provider documentation if you need to rely on it for outbound mail you send, because your server must implement the check separately.

Prerequisites

Before publishing anything:

1. Your MX hosts must present valid, trusted certificates that match their hostnames. Self-signed or expired certificates will cause mail to be refused once you enforce. Test each MX host with the SSL Checker (you can also test port 25 with openssl s_client -starttls smtp -connect mail1.example.com:25 -servername mail1.example.com).
2. They should support TLS 1.2 or higher. The TLS Version Checker helps for web endpoints; for SMTP use the openssl command above.
3. You need a place to host an HTTPS file on mta-sts.example.com with a valid certificate. Static hosting, a tiny web server, or a CDN will do.
4. Know your exact MX hostnames: look them up with the MX Lookup. Hosted providers (Google, Microsoft) publish the hostnames you should list; see the Google Workspace and Microsoft 365 guides.

Step 1: Create the policy file

The file must be served at exactly this path:

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

Content, using CRLF or LF line endings:

version: STSv1
mode: testing
mx: mail1.example.com
mx: mail2.example.com
max_age: 86400

Fields:

• version: STSv1 is required.
• mode is none, testing or enforce.
• mx: lines list every allowed MX hostname. Wildcards are allowed in the form *.example.com and match one label.
• max_age is how long senders may cache the policy, in seconds (the maximum allowed is roughly a year).

The three modes

Start in testing.

Step 2: Serve it correctly

The HTTPS requirements are strict:

• Host name must be exactly mta-sts.<domain>, with a certificate valid for that name from a public CA.
• The response must be HTTP 200. Redirects are not followed by a compliant client; a 301 will break the policy.
• Content type should be text/plain.
• The file must be reachable without authentication.

Verify the HTTP side with the HTTP Status Checker, and the certificate with the SSL Checker. A quick manual check:

curl -i https://mta-sts.example.com/.well-known/mta-sts.txt

Create the DNS record for the host, for example a CNAME or A record for mta-sts.example.com pointing to your static host.

Step 3: Publish the MTA-STS TXT record

_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=20261005T120000"

The id is any string of letters and digits up to 32 characters. Change it whenever you change the policy file. Senders cache the policy and only re-fetch when the id differs. A timestamp is a common choice. Forgetting to bump the id after editing the file is the classic mistake; the change will simply not be noticed until max_age expires.

Step 4: Publish TLS-RPT

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

rua can be a mailto: address or an https: endpoint that accepts POSTed reports. Reports arrive as compressed JSON, typically once a day per reporting provider. They list the policy applied, the counts of successful and failed sessions, and a failure type for each problem, for example certificate-expired, certificate-host-mismatch, starttls-not-supported or sts-policy-fetch-error.

Use a dedicated mailbox or a report-processing service, since manually reading JSON gets old quickly. TLS-RPT also works without MTA-STS, and is useful on its own to detect TLS trouble.

Step 5: Watch, then enforce

1. Run in testing mode for at least a couple of weeks, with a modest max_age such as one day.
2. Review TLS-RPT reports. Fix every failure pattern: expired or mismatched certificates, MX hosts missing from the list, servers that do not offer STARTTLS.
3. When reports are clean, change the policy file to mode: enforce, set a longer max_age (a week, then weeks or months), and bump the id.
4. Keep watching reports. Certificate renewal becomes a mail-critical task from now on. Automate it, as covered in renewing SSL certificates automatically.

Changing mail providers

When you migrate email, update the mx: list before you change MX records, and bump the id. Because senders cache the policy for max_age, a long cache plus an outdated MX list can block mail to your new provider. Before a migration, consider lowering max_age well in advance or switching to testing or none temporarily, and keep the old hosts in the list during the transition.

MTA-STS versus DANE

DANE (TLSA records published in DNSSEC-signed zones) achieves a similar goal using DNS rather than HTTPS and public CAs. It requires DNSSEC, see DNSSEC explained, and is better supported by some European providers. MTA-STS is more widely supported by the largest mailbox providers. You can run both.

Troubleshooting

Validate everything with the Email DNS Checker and a DNS Checker lookup of the TXT records.

Next steps

• Look up your current MX hosts with the MX Lookup.
• Verify the policy-host certificate with the SSL Checker.
• Confirm the records with the Email DNS Checker.
• Make sure basic authentication is complete via the SPF, DKIM and DMARC guide.

FAQ

Does MTA-STS encrypt my outgoing mail?

No. It protects mail that others send to your domain. Your own outbound server needs its own MTA-STS validation support to protect mail you send.

What happens in enforce mode if my certificate expires?

Senders that honor MTA-STS will not deliver the message and will queue it, retrying for a while before bouncing it. Mail does not fall back to plaintext.

Do I need TLS-RPT?

It is optional, but without it you are enforcing blind. Reports are the only way to see which senders are failing validation.

How often should I change the id?

Every time the policy file changes, and only then. A new id tells senders to fetch the file again.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.