MTA-STS and TLS-RPT Setup: A Step-by-Step Guide for Your Domain

SPF, DKIM and DMARC protect your domain's identity. They don't protect mail coming to you while it's in transit. SMTP encryption between mail servers is opportunistic by default, so an attacker positioned on the network can strip the STARTTLS offer and get your mail delivered in plain text, or redirect it to a server with a bogus certificate. MTA-STS lets your domain tell sending servers "always use TLS with a valid certificate when delivering to me," and TLS-RPT sends you daily reports when that fails. This guide walks through both setups, with copy-paste records and web server config.

What each standard does

They're independent, but you want both. Set up TLS-RPT first so you can see what MTA-STS would break before you enforce it.

Before you start: check your MX servers

MTA-STS only works if your inbound mail servers already do TLS properly. Each MX host must:

• Support STARTTLS, with TLS 1.2 or later (Google's guidance).
• Present a certificate that is unexpired, chains to a trusted root CA, and matches the MX hostname.

List your MX hosts:

dig +short MX example.com

If you use Google Workspace or Microsoft 365, the provider handles the servers and certificates. If you run your own mail server, or a filtering gateway sits in front of your mailboxes, check its certificate before going further. A self-signed certificate on the MX host means MTA-STS in enforce mode would block your incoming mail.

Step 1: publish a TLS-RPT record

Add a TXT record at _smtp._tls:

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

• v=TLSRPTv1 must come first.
• rua accepts mailto: or https: addresses, comma-separated.
• Unlike DMARC, reports can go to an address on another domain without any extra authorization record.

Reports arrive as JSON, usually gzip-compressed, covering one UTC day. They list successful and failed TLS sessions with failure types such as:

Step 2: create the policy file

The policy is a plain-text file. Google's guidance says it can be up to 64 KB, and the version line must come first.

version: STSv1
mode: testing
mx: mail.example.com
mx: backup-mx.example.com
max_age: 604800

• version: always STSv1.
• mode: testing (report only), enforce (refuse delivery on failure) or none (policy withdrawn).
• mx: one line per MX host. A wildcard may replace only the leftmost label (*.example.net matches mx1.example.net but not a.b.example.net).
• max_age: how long senders cache the policy, in seconds. The RFC caps it at 31557600 (about a year). Google says it must be at least 86400 and recommends 604800 to 1209600 (one to two weeks) in testing.

Microsoft 365 (MX pointing directly to Exchange Online): Microsoft documents this exact policy, and stresses that the wildcard is specific to Exchange Online:

version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 604800

Google Workspace and other providers: list the MX hostnames exactly as dig MX returns them, or use the configuration your provider suggests. Google's admin console can check MTA-STS status and suggest a configuration.

If you use multiple providers or a gateway, every MX host that can receive your mail must match an mx line.

Step 3: host the policy over HTTPS

The file must be served at exactly:

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

Requirements from RFC 8461:

• A valid certificate for mta-sts.example.com. Not self-signed, not expired. A free Let's Encrypt certificate is fine.
• HTTP 200 response. Senders do not follow redirects, so don't redirect to www or force a path change.
• Content-Type: text/plain.

Create the DNS record for the subdomain first:

mta-sts.example.com.  3600  IN  A  203.0.113.10

Nginx

server {
    listen 443 ssl;
    http2 on;
    server_name mta-sts.example.com;

    ssl_certificate     /etc/letsencrypt/live/mta-sts.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mta-sts.example.com/privkey.pem;

    location = /.well-known/mta-sts.txt {
        default_type text/plain;
        alias /var/www/mta-sts/mta-sts.txt;
    }

    location / {
        return 404;
    }
}

Apache

<VirtualHost *:443>
    ServerName mta-sts.example.com
    DocumentRoot /var/www/mta-sts

    SSLEngine on
    SSLCertificateFile    /etc/letsencrypt/live/mta-sts.example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/mta-sts.example.com/privkey.pem

    <Files "mta-sts.txt">
        ForceType text/plain
    </Files>
</VirtualHost>

Put the file at /var/www/mta-sts/.well-known/mta-sts.txt.

No server? Static hosting works well: Microsoft documents hosting the policy on Azure Static Web Apps, and services like Cloudflare Pages or GitHub Pages with a custom domain can serve it too. Just confirm the URL returns 200 with no redirect. Avoid platforms that add a trailing slash or redirect .txt files.

Test it:

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

You want HTTP/2 200 (or HTTP/1.1 200), a content-type: text/plain header, and the policy text.

Step 4: publish the MTA-STS TXT record

This record tells senders a policy exists and which version it is:

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

The id can be up to 32 letters and digits (RFC 8461), with no punctuation. A UTC timestamp like the one above is easy to keep unique.

Senders compare the id with what they have cached. Change the id every time you change the policy file, or senders keep using the cached version until max_age runs out. Update the file first, then the TXT record.

Only publish one _mta-sts TXT record. If senders find more than one, they treat the domain as having no policy.

To confirm everything lines up, run the domain through our free MTA-STS checker. It validates the TXT record and the policy file, flags redirects and syntax errors, and checks that every MX host is covered by an mx line, which is the mistake that blocks mail once you switch to enforce.

Step 5: run in testing mode, then enforce

1. Leave mode: testing for at least one or two weeks. Senders fetch your policy and report failures through TLS-RPT, but still deliver mail.

2. Read your TLS-RPT reports. You're looking for zero failures from legitimate senders. Any certificate-host-mismatch or sts-policy-fetch-error must be fixed first.

3. Switch to enforce. Edit the file:

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

4. Change the id in the TXT record.

5. Keep reading reports. A renewal that fails on your MX host or on mta-sts.example.com will now affect delivery.

Changing MX providers or removing MTA-STS

This is where people get caught. Senders cache your policy for max_age seconds. If you move to a new mail provider without updating the policy, MTA-STS-aware senders will refuse to deliver to the new MX hosts until the old cached policy expires.

When migrating: add the new provider's hosts to the mx lines (keep the old ones), update the id, wait at least the previous max_age, then switch MX records. Remove the old hosts afterwards.

When removing MTA-STS (per RFC 8461): publish a policy with mode: none and a short max_age, update the id, wait until older cached policies have expired, then delete the TXT record and the policy endpoint.

In an emergency: Microsoft recommends switching the policy to mode: testing and updating the id. Senders that re-fetch will stop enforcing while you fix the problem.

Frequently asked questions

Does MTA-STS protect the email I send?

No. It protects mail delivered to your domain. When you send to other domains, your provider honors their MTA-STS policies. Microsoft says Exchange Online always validates recipients' MTA-STS policies on outbound mail.

Do I need DNSSEC for MTA-STS?

No. MTA-STS was designed to work without DNSSEC by relying on HTTPS and the web certificate system. DANE is the DNSSEC-based alternative. Some domains publish both.

What happens if my mta-sts certificate expires?

Senders can't validate the policy (sts-webpki-invalid). Senders that already cached a valid policy keep using it until max_age runs out. New senders may not get your policy at all. Automate renewal and watch TLS-RPT for this failure type.

Is MTA-STS required by Gmail or Microsoft?

No. Neither lists it as a sender requirement. It's an inbound security measure you choose to adopt, and both providers support it.

What to do next

Publish the TLS-RPT record today. It's one line, has no risk, and the reports will show whether senders can reach your MX hosts over TLS. Then host the policy in testing mode, read a couple of weeks of reports, and enforce. A free audit checks for your MTA-STS record and policy along with SPF, DKIM, DMARC and BIMI, and the email authentication checklist shows where it fits. If your DNS and TLS basics need work first, see DNS records explained and SSL certificate errors.

Sources

• RFC 8461: SMTP MTA Strict Transport Security (MTA-STS)
• RFC 8460: SMTP TLS Reporting
• Microsoft Learn: Enhance mail flow with MTA-STS
• Google Workspace Admin Help: Create an MTA-STS policy