Setting Up MTA-STS and TLS-RPT

MTA-STS (SMTP MTA Strict Transport Security) is an open standard defined in RFC 8461. It lets a domain owner declare that mail servers accepting email for the domain support TLS, and that senders must refuse to deliver over an unencrypted or untrusted connection.

MTA-STS protects inbound mail to your domain. The domain administrator sets it up at the mail hosting provider, the DNS provider, and the web server — there is no MTA-STS screen in a marketing platform, so do not look for one in the interface. Only mail servers that support MTA-STS enforce the policy; other servers keep delivering mail without the extra MTA-STS check.

MTA-STS and DMARC

MTA-STS and DMARC solve different problems and are configured independently. DMARC helps receiving servers detect email that uses your domain as a forged sender domain; MTA-STS protects the delivery of email to your domain against attacks on the TLS connection.

MTA-STS requires neither DMARC nor a specific DMARC policy. For what SPF, DKIM, and DMARC do, see FAQ: Email Authentication and Domain Reputation.

What You Need

• Access to the DNS settings of the domain.
• A web server, or a hosted MTA-STS service, that can serve an HTTPS page on the mta-sts.<yourdomain> subdomain with a valid TLS certificate.
• The list of MX hostnames that receive email for the domain.
• A monitored mailbox for TLS reports, or a service that parses them.

Before you start, check that every MX host of your domain supports STARTTLS and uses a valid TLS certificate. If inbound mail passes through a third-party gateway, filtering service, or forwarder, ask its provider which MX hosts belong in the MTA-STS policy.

Setup Order

Publish the policy file before the DNS record that announces it. Once _mta-sts is published, sending servers start looking for the policy, so the file has to be in place and correct by then. The order below follows the recommendations of Google Workspace and Microsoft.

1. Add TLS-RPT reporting.
2. Create the mta-sts subdomain and its hosting.
3. Publish the policy file in testing mode and check it.
4. Publish the _mta-sts DNS record.
5. Review the reports and switch to enforce.

Step 1: Add TLS-RPT Reporting

TLS-RPT (RFC 8460) makes sending servers report TLS connection results for your domain, which is what makes the testing stage useful. Add it first, so the reports cover the whole testing period.

Add a TXT record:

Reports arrive as daily JSON summaries.

Typical failure reasons in the reports:

• the MX host is not in the policy;
• the certificate has expired;
• the certificate was not issued for that MX host;
• the certificate chain is not trusted;
• STARTTLS is unavailable;
• the TLS negotiation failed.

Step 2: Create the mta-sts Subdomain

The policy file is served over HTTPS from a subdomain named mta-sts, so that subdomain has to exist as a working web host:

1. Create an A, AAAA, or CNAME record for mta-sts.<yourdomain> pointing at the web server or hosted service that will serve the file.
2. Configure that server to serve the /.well-known/ path.
3. Issue a TLS certificate valid for mta-sts.<yourdomain>.

Without these three steps the policy URL does not exist, and everything that follows fails.

Step 3: Publish the Policy File

Serve a plain-text file over HTTPS at:

https://mta-sts.<yourdomain>/.well-known/mta-sts.txt

Example content:

version: STSv1
mode: testing
mx: mail.yourdomain.com
mx: *.mailprovider.example
max_age: 86400

• version — always STSv1.
• mode — none, testing, or enforce. Start with testing.
• mx — one line per MX hostname that is allowed to receive mail for the domain. Wildcards are allowed for one label. Every hostname in your MX records must be listed.
• max_age — how long, in seconds, a sending server may cache the policy. Use a short value such as 86400 (one day) while testing, and a longer one such as 604800 (one week) once the policy is stable.

The file must be served with the Content-Type: text/plain header and no redirects, over HTTPS with a certificate valid for mta-sts.<yourdomain>.

Check the file as described in Checking the Setup before moving on.

Step 4: Publish the DNS Record

Once the policy file is reachable and correct, announce it with a TXT record on the _mta-sts subdomain:

Sending servers use id to detect that the policy changed, so update it every time you edit the policy file.

According to RFC 8461, id is 1 to 32 characters long and contains only Latin letters and digits. It does not have to be a date — a timestamp is simply a convenient way to produce unique values.

Step 5: Choose the Policy Mode

Roll out MTA-STS in stages:

1. testing — sending servers report failures but still deliver mail as usual. Start here. Keep the policy in testing for at least several days, and for domains with low or irregular mail volume, several weeks. Switch to enforce only once the reports cover every significant source of inbound mail and show no systematic failures.
2. enforce — sending servers refuse to deliver when the TLS connection or the MX hostname doesn't match the policy. Switch only after testing reports are clean.
3. none — tells senders that no policy applies. Use this to retire an MTA-STS policy gracefully instead of deleting the records outright.

Whenever you change the file, update the id value in the _mta-sts TXT record so senders pick up the new version.

Checking the Setup

Check the policy file:

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

The response must be 200, with Content-Type: text/plain and no redirect. Then read the file itself and confirm the syntax is valid and the mx lines match your real MX records:

curl https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
dig +short MX yourdomain.com

Check both TXT records, and repeat the query against a second resolver to confirm the records have propagated:

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

Finally, confirm that every host listed in mx accepts STARTTLS with a valid certificate. An online MTA-STS validator is a useful extra check, but treat it as a second opinion rather than as proof that the setup is correct.

Common Mistakes

• The mta-sts subdomain has no DNS record, no web server, or no valid certificate. The policy URL then does not resolve, and senders cannot retrieve new versions of the policy.
• The policy file is missing an MX hostname that actually receives mail. In enforce mode, errors in the mx list or in the TLS certificates of those hosts can delay or prevent delivery of incoming email. The exact caching and retrieval logic is defined by RFC 8461.
• The file is served over HTTP, through a redirect, or as text/html.
• The id value in DNS was not changed after the policy file was edited, so senders keep using the cached policy.
• enforce was enabled before any TLS-RPT reports were reviewed.

If Something Breaks After You Switch to enforce

1. Change mode: enforce to mode: testing in the policy file.
2. Publish the updated file.
3. Change the id in the _mta-sts DNS record so senders fetch the new version.
4. Read the TLS reports and fix the MX hosts or certificates.

Because of caching, the change does not take effect immediately. Don't delete the DNS record instead: senders can keep using the cached policy until max_age expires.

Changing Your MX Servers

Change the MX records and the policy together:

1. Put the policy back into testing mode and change its id.
2. Add the new MX hosts to the policy file before you change DNS.
3. Check their TLS certificates and STARTTLS.
4. Change the domain's MX records.
5. Read the TLS reports.
6. Return to enforce and update the id again.

Account for the previous max_age: some senders may keep applying the cached policy until that period ends.

Related Settings

• Setting Up Email Domain Authentication — SPF and DKIM for your sending domain.
• FAQ: Email Authentication and Domain Reputation — what SPF, DKIM, and DMARC do and how DMARC policies work.
• Domain Verification Troubleshooting — DNS issues during domain verification.