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 declare that mail servers sending to it must use TLS and must present a valid certificate for one of the host names the domain lists. Sending servers that support MTA-STS refuse to deliver over an unencrypted or untrusted connection instead of silently falling back to plain text.

MTA-STS protects mail delivered 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 the authentication side of the setup, see How Email Authentication Works.

What You Need

• A domain with working mail hosting and MX records. If the domain has no mail hosting yet, set it up first — see Setting Up Email Domain Authentication.
• Access to your domain's DNS settings.
• A web server, or a hosted MTA-STS service, able to serve HTTPS on the mta-sts subdomain with a valid TLS certificate.
• 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. Enable TLS 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.

1. Enable TLS Reporting (TLS-RPT)

TLS-RPT (RFC 8460) makes sending servers send you daily aggregate reports about TLS connection results. Enable it first, so the reports cover the whole testing period.

Create a TXT record:

Use a monitored mailbox, or a reporting service that parses the JSON reports for you. 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.

📘

Reports to an address in another domain

If the report address belongs to a different domain than the one being reported on, that domain has to confirm it agrees to receive the reports with an additional DNS record. The requirement is described in RFC 8460; a reporting service will tell you the exact record to add.

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.com 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.com.

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

3. Publish the Policy File

Place the file at:

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

Serve it with the Content-Type: text/plain header and no redirects.

Example policy:

version: STSv1
mode: testing
mx: mx1.yourprovider.com
mx: mx2.yourprovider.com
max_age: 604800

Fill it in as follows:

• mx — one line per mail server that receives mail for your domain. The values must match your actual MX records; you can use a wildcard such as *.yourprovider.com. Ask your mailbox provider for the correct host names.
• max_age — how long, in seconds, sending servers may cache the policy. A week (604800) is a common starting value; increase it once the policy is stable.
• mode — start with testing. The modes are described below.

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

4. Publish the DNS Record

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

The id value identifies the current version of the policy. Change it every time you edit the policy file, so sending servers know to fetch the new version.

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.

5. Choose the Policy Mode

The mode field controls what a sending server does when the TLS requirements are not met:

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. Update the id in the DNS record whenever you change the mode.

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 mx lines don't match the real MX records. Every host that receives mail for the domain must be listed. 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 id isn't changed after editing the policy. Sending servers keep using the cached old policy until max_age expires.
• The file is served as text/html or through a redirect. Sending servers may reject it.
• Going straight to enforce. Without a testing period you have no visibility into which senders would start failing.

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.