How to Set Up MTA-STS and TLS-RPT

Quick answer

MTA-STS needs a small text file on a web server and one DNS record. TLS-RPT is one more DNS record that gets you reports. For a domain whose MX points at Microsoft 365, the whole setup looks like this:

https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 604800

_mta-sts.example.com    TXT  v=STSv1; id=20261017000000Z
_smtp._tls.example.com  TXT  v=TLSRPTv1; rua=mailto:tlsrpt@example.com

On Google Workspace, the mx line is smtp.google.com (or the older aspmx names). Start in testing mode, read the TLS reports for about two weeks, then change the file to mode: enforce and give the TXT record a new id. Build the file with the MTA-STS Policy Generator and the report record with the TLS-RPT Record Generator.

What MTA-STS and TLS-RPT do

Mail servers encrypt SMTP with STARTTLS, but only when both sides offer it, and they usually don't check the certificate. If someone in the path strips the STARTTLS offer or points the sender at the wrong server, most senders still deliver the mail, unencrypted or to the wrong host.

• MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) lets your domain publish a policy that says: my mail servers support TLS, these are their names, and their certificates are publicly trusted. Senders that support MTA-STS cache the policy. In enforce mode they refuse to deliver to an MX that doesn't match the policy, doesn't offer STARTTLS or doesn't present a valid certificate.
• TLS-RPT (SMTP TLS Reporting, RFC 8460) tells sending servers where to send daily reports about TLS connections to your MX: how many sessions worked, how many failed, and why. It covers MTA-STS and DANE.

MTA-STS protects mail sent to your domain. Senders that don't support it keep delivering as they do today, so publishing a policy never stops mail from those servers. Exchange Online and Gmail already check other domains' MTA-STS policies when they send, so those senders will apply yours once it is published.

Before you start

• Know every MX. List all MX records for the domain, including backup MX hosts and any filtering gateway, with the MX Record Lookup. Every one has to be in the policy.
• Every MX must support STARTTLS with TLS 1.2 or later.
• Every MX certificate must be valid: not expired, chained to a publicly trusted root CA, and with a subject alternative name (SAN) that matches the MX hostname. Senders match DNS names in the SAN only. Microsoft 365 and Google Workspace MX servers already meet this. For your own servers or a gateway, look up the certificates issued for each MX name with the SSL Certificate Checker.
• You need HTTPS on mta-sts.<your domain>, with a certificate valid for that exact name. Exchange Online can't host the policy file, and Google's instructions have you upload it to your own web server.
• Create a mailbox or group for TLS reports, for example tlsrpt@example.com.

Step 1: Turn on TLS reporting

Google recommends adding the TLS-RPT record first, then turning on MTA-STS, so reports are already flowing when the policy goes live. Add a TXT record at _smtp._tls:

Host:  _smtp._tls
Type:  TXT
Value: v=TLSRPTv1; rua=mailto:tlsrpt@example.com

• The record must start with v=TLSRPTv1. The rua tag is required.
• rua takes mailto: or https: addresses. For several destinations, separate them with commas: rua=mailto:tlsrpt@example.com,mailto:security@example.com.
• Publish exactly one TLS-RPT record. If senders find more than one record starting with v=TLSRPTv1, they treat the domain as having no TLS reporting.
• Reports are JSON, normally gzip-compressed, and each should cover one full UTC day. Reports sent by email must carry a valid DKIM signature from the reporting domain. An https: endpoint receives the report as an HTTP POST (application/tlsrpt+json, or application/tlsrpt+gzip when compressed). Google Workspace doesn't provide an API for HTTPS reports, so email is the simple choice.
• Don't expect many reports at first. Google notes that you might not receive many until TLS reporting is more widely used by mail providers.

Generate and check the value with the TLS-RPT Record Generator.

Step 2: Write the policy file

The policy is a plain text file named mta-sts.txt with one key: value pair per line:

version: STSv1
mode: testing
mx: mail.example.com
mx: *.example.net
max_age: 604800

• Put each mx on its own line. A comma-separated list on one line is invalid.
• Lines can end with LF or CRLF. Google says the file can be up to 64 KB; a real policy is a few lines.
• Each domain needs its own policy file on its own mta-sts host, even if the contents are identical.

The MTA-STS Policy Generator builds the file and a matching TXT record from your mode, MX list and max_age.

Step 3: Host the policy on mta-sts.<your domain>

Senders fetch the policy from one fixed URL:

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

• Certificate: the HTTPS certificate must be valid for mta-sts.example.com, chain to a publicly trusted root and not be expired. A certificate for the apex or www alone doesn't count.
• No redirects: the URL must answer 200 OK with the file itself. Senders must not follow 3xx redirects, so a redirect to another path or host breaks the policy.
• Plain text: serve it as text/plain. Senders should check the media type, so an HTML page that happens to contain the right text can be rejected.
• Fast: RFC 8461 suggests senders give up after about a minute, and Microsoft asks you to check the response time.

Hosting options

Any static host that serves HTTPS on a custom subdomain with an automatic certificate works. Common choices are Cloudflare Pages or Workers, GitHub Pages, Azure Static Web Apps (Microsoft's recommended option for Exchange Online customers) or a web server you already run. The steps are the same everywhere:

1. Create a site or project and add mta-sts.example.com as its custom domain. The host tells you which CNAME or A record to create, then issues the certificate.
2. Upload the file as .well-known/mta-sts.txt. Some static site builders skip folders whose names start with a dot, so confirm the folder was actually deployed.
3. Open the URL in a browser. You should see only the policy text, with no redirect and no certificate warning. Some hosts answer unknown paths with their home page and HTTP 200, so check that the content is your policy, not just that the page loads.

Using a hosted MTA-STS service instead? RFC 8461 allows delegation: point _mta-sts at the provider's record with a CNAME, and point mta-sts at the provider. The certificate must still be valid for mta-sts.<your domain>.

Step 4: Publish the _mta-sts TXT record

Once the policy URL works, add a TXT record at _mta-sts. This record is what tells senders a policy exists:

Host:  _mta-sts
Type:  TXT
TTL:   3600
Value: v=STSv1; id=20261017000000Z

• The record must start with v=STSv1.
• id is 1 to 32 letters and digits only. No dashes, dots, colons or spaces, so 2026-10-17 is invalid. Microsoft and Google both suggest the current UTC date and time, such as 20261017000000Z, so you can see when the policy last changed.
• Publish exactly one record starting with v=STSv1. With two, senders ignore MTA-STS for the domain.
• Microsoft recommends a TTL of 3600 seconds. Google says DNS changes can take up to 24 hours to take effect, depending on the TTL.

Confirm both TXT records with DNS Lookup, then run the domain through the Email Deliverability Checker, which reports MTA-STS and TLS-RPT along with SPF, DKIM and DMARC.

Microsoft 365 (Exchange Online)

If your MX points straight at Exchange Online (a host like contoso-com.mail.protection.outlook.com), Microsoft says you can use the same policy values as microsoft.com's own policy. This is the file we fetched from mta-sts.microsoft.com on 17 October 2026:

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

• Start your own copy with mode: testing, as Microsoft recommends, and switch to enforce after validating.
• The wildcard is safe here because Exchange Online only lets one organization receive mail for a given domain. Microsoft warns that this may not be true for other mail services, and says its wildcard example must not be used as general MTA-STS guidance. For other providers, list the exact MX hostnames unless the provider tells you otherwise.
• Exchange Online can't host the policy file. Microsoft's walkthrough uses Azure Static Web Apps, which issues the mta-sts certificate for you, or Azure Functions, where you bring your own certificate.
• Inbound SMTP DANE with DNSSEC: enabling it with Enable-DnssecForVerifiedDomain gives the domain a new MX hostname under mx.microsoft, returned as DnssecMxValue (Microsoft's example is contosotest-com.o-v1.mx.microsoft). Microsoft's order is: set the policy to testing, change the id and wait for the old max_age to pass; then replace the legacy mx line with the exact new hostname and change the id again; once mail flows, set enforce and change the id once more. Add the exact hostname, because *.mx.microsoft covers only one label and doesn't match it. If the line is missing, Microsoft reports ES001: Expected MX record missing in policy while mode is enforced.
• If your MX points at a third-party filtering service in front of Microsoft 365, the policy lists that service's MX hosts. Microsoft says to check with the provider that it meets the MTA-STS requirements.
• For mail you send, Exchange Online always checks recipients' MTA-STS policies; there's nothing to turn on. Failures to an enforcing domain can bounce with 5.4.8 (MX not in the policy) or 5.7.5 (certificate failed validation). Exchange Online also sends TLS-RPT reports, in JSON.

Setting up the rest of Microsoft 365 mail authentication? See the SPF, DKIM and DMARC guides.

Google Workspace

Google says the policy needs an mx line for each MX record on the domain:

mx: smtp.google.com          (current single MX)
mx: aspmx.l.google.com       (older MX set, common on domains set up before 2023)
mx: *.aspmx.l.google.com     (covers alt1 to alt4.aspmx.l.google.com)

Google's own google.com policy, fetched on 17 October 2026, lists exactly these three lines in enforce mode. Listing all three is a simple choice if you aren't sure which set your domain uses, and it keeps working if you later move from the aspmx names to smtp.google.com.

• Get a suggested configuration: in the Google Admin console go to Menu > Apps > Google Workspace > Gmail > Compliance, scroll to MTA-STS and click Validate your MTA-STS configuration here (needs the Gmail Settings administrator privilege). Click a domain to see its current TXT records and policy, with a suggested configuration for anything missing or invalid. Editions with security health also show status under Security > Security health > MTA-STS.
• Add the DNS records at your domain host, not in the Admin console.
• Google's instructions have you upload the policy to your own public web server on the mta-sts subdomain. Each domain in the account needs its own hosted file.
• Google recommends testing mode for two weeks, which it says is enough report data to find and fix problems.
• For mail you send, Gmail already follows other domains' enforced MTA-STS policies.

Still setting up the basics? See SPF, DKIM and DMARC for Google Workspace.

Step 5: Test, then switch to enforce

1. Check that the policy URL returns the file and that both TXT records resolve. On Google Workspace, also run the Admin console validation.
2. Leave the policy in testing for about two weeks and read the TLS reports. Each report lists the policy that was applied ("policy-type": "sts"), total-successful-session-count and total-failure-session-count, plus a result-type for each failure.
3. Fix what the reports show. Common result types are starttls-not-supported, certificate-host-mismatch, certificate-expired and certificate-not-trusted (an MX problem), sts-policy-fetch-error (the policy URL can't be reached), sts-policy-invalid (the file has an error) and sts-webpki-invalid (the mta-sts certificate failed).
4. Change the file to mode: enforce. You can raise max_age at the same time, for example to 1209600 (two weeks) or longer.
5. Update the TXT record with a new id. Google says you must change the id when going from testing to enforce, just like any other policy change.

Changing the policy later

• Every change needs a new id. Senders only fetch the file again when the id changes; otherwise they keep the cached copy until max_age runs out.
• Update the file first, then the TXT record. RFC 8461 asks for this order so a sender that sees the new id doesn't cache the old file.
• Changing MX hosts or mail providers: senders can keep using the old policy until the TXT record's TTL has passed, so the old policy should still allow delivery during that window. The safe pattern, which is Microsoft's for its DANE change, is to go back to testing, change the id, wait for the old max_age to pass, change the MX records and the mx lines, then return to enforce with another new id.
• Turning MTA-STS off: publish mode: none with a short max_age (for example one day) and a new id. Remove the TXT record and the file only after every older policy's max_age has expired. Deleting the TXT record alone doesn't clear senders' caches.
• Subdomains: policies aren't inherited. Mail to user@mail.example.com uses only mail.example.com's own policy, so each domain that receives mail needs its own records and mta-sts host.

Common mistakes

• Leaving an MX out of the policy, often a backup MX or a filtering gateway. In enforce mode, MTA-STS senders won't deliver to it.
• Expecting a wildcard to cover more than one label: *.example.com doesn't match example.com or mx1.mail.example.com, and *.mx.microsoft doesn't match a DNSSEC MX like contoso-com.o-v1.mx.microsoft.
• Putting several MX hosts on one mx line, separated by commas.
• Using a policy id with dashes or dots, such as 2026-10-17, or longer than 32 characters.
• Editing the file but not changing the id, so senders keep the cached policy.
• Serving the policy behind a redirect, as an HTML page, or with a certificate that doesn't cover mta-sts.<your domain>.
• A host that returns its home page for missing paths, so the policy URL looks fine but doesn't serve the policy.
• Publishing two v=STSv1 or two v=TLSRPTv1 records, so senders ignore both.
• Going straight to enforce with a long max_age before reading any reports.
• Expecting MTA-STS to protect mail you send. It protects mail sent to your domain; for outbound mail, it's the recipient's policy that counts.

Audit hundreds of domains at once

Need SPF, DMARC and MX checks across a whole client list? Run the Bulk SPF / DMARC / MX Auditor on Apify ($2 per 1,000 domains).

Related tools and guides

Build the policy with the MTA-STS Policy Generator and the report record with the TLS-RPT Record Generator. List every MX first with MX Record Lookup, check the certificates for your MX and mta-sts hostnames with the SSL Certificate Checker, confirm the TXT records with DNS Lookup and the DNS Propagation Checker, and audit the whole domain with the Email Deliverability Checker. Related guides: SPF, DKIM and DMARC for Microsoft 365, SPF, DKIM and DMARC for Google Workspace, and the bulk sender requirements (which list TLS for sending to Gmail).

FAQ

What is the difference between MTA-STS and TLS-RPT?

MTA-STS (RFC 8461) publishes a policy that tells sending servers your MX hosts support TLS with valid certificates and, in enforce mode, not to deliver if that check fails. TLS-RPT (RFC 8460) is a separate DNS record at _smtp._tls that tells senders where to send daily reports about successful and failed TLS connections. Deploy them together so you can see problems before you enforce.

Where do I host the MTA-STS policy file?

At https://mta-sts.yourdomain/.well-known/mta-sts.txt on any web host that serves HTTPS with a publicly trusted certificate valid for the mta-sts subdomain. A static host such as Cloudflare Pages, GitHub Pages or Azure Static Web Apps works. The URL must return the file directly with HTTP 200, not a redirect, as plain text.

What mx value do I use for Microsoft 365 in an MTA-STS policy?

If your MX points directly at Exchange Online, use mx: *.mail.protection.outlook.com, the same value Microsoft uses for microsoft.com. If you have enabled inbound SMTP DANE with DNSSEC, add the exact mx.microsoft hostname returned as DnssecMxValue, because a wildcard does not cover it. If a filtering gateway receives your mail, list the gateway MX hosts instead.

What mx values do I use for Google Workspace in an MTA-STS policy?

Add an mx line for each MX record on the domain: smtp.google.com for the current single MX, or aspmx.l.google.com plus *.aspmx.l.google.com for the older set. Google lists all three lines in its own google.com policy, and the Admin console under Apps, Google Workspace, Gmail, Compliance can suggest a policy for your domain.

How do I switch MTA-STS from testing to enforce?

Run in testing mode for about two weeks and fix any failures the TLS reports show. Then edit the policy file to say mode: enforce, optionally raise max_age, and change the id value in the _mta-sts TXT record to a new string of letters and digits, such as the current UTC date and time. Update the file before the TXT record.

Want the full kit?

Runbooks, checklists and helpdesk templates: IT Admin Packs on Gumroad.