Setting up MTA-STS for Google Workspace

MTA-STS for Google Workspace: DNS TXT plus a policy file on the mta-sts subdomain — testing first, then enforce.

Last updated: July 2026

In short: After this guide your domain enforces encrypted delivery (TLS) for incoming mail to your Google Workspace mailboxes — via a DNS record and a policy file served over HTTPS.

⚠️ Delivery risk: a faulty MTA-STS policy in enforce mode can make other servers stop delivering mail to your domain — and max_age keeps the mistake cached for days. Always start with mode: testing and review TLS-RPT reports before enforcing.

Prerequisites

A Google Workspace account with your own domain
Access to your domain's DNS management (at the domain host)
A public web server with a valid HTTPS certificate for a subdomain
Sensible beforehand: TLS-RPT, so you get reports

What is MTA-STS?

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) tells other mail servers: "Deliver mail to my domain only over a valid, encrypted TLS connection — otherwise not at all." This prevents downgrade and man-in-the-middle attacks on the transport path.

Unlike SPF, DKIM, and DMARC, MTA-STS consists of two parts:

A DNS TXT record under _mta-sts that signals "this domain has a policy".
A policy file served over HTTPS at mta-sts.your-domain/.well-known/mta-sts.txt that contains the concrete rules (allowed MX, mode, validity).

The starting point at Google Workspace

Google documents MTA-STS well, but emphasizes: the DNS records go to the domain host, not into the Google Admin console ("Add these records to your domain settings at your domain host, not in your Google Admin console"). You get the matching MX values for the policy file via the Admin console's security status page.

Step-by-step guide

1. Create the policy file

Create a text file mta-sts.txt — Google starts in testing mode (recommended for 2 weeks), which only reports but doesn't yet enforce anything:

First check which MX records your domain actually uses — the mx: lines in the policy must match them exactly:

dig MX example.com +short

Since 2023, Google Workspace uses a single MX value (smtp.google.com); older setups often still run on the aspmx legacy values — both remain supported. For a modern setup:

version: STSv1
mode: testing
mx: smtp.google.com
max_age: 604800

For a legacy setup (MX values starting with aspmx):

version: STSv1
mode: testing
mx: aspmx.l.google.com
mx: *.aspmx.l.google.com
max_age: 604800

version: STSv1 must be on the first line, the remaining fields in any order. mx: lists your allowed mail servers (for Google Workspace, the Google MX), max_age the validity in seconds (604800 = one week).

2. Serve the policy file over HTTPS

Create a subdomain whose name starts with mta-sts (mta-sts.example.com), create a directory .well-known in it, and upload the file there. The finished URL looks like Google's example: https://mta-sts.solarmora.com/.well-known/mta-sts.txt.

The web server must provide SSL/HTTPS with a certificate from a trusted CA — a self-signed certificate isn't enough.

3. Create the DNS TXT records

At the domain host you create two records (Google recommends activating TLS-RPT first):

_smtp._tls (TLS-RPT, for reports):

v=TLSRPTv1; rua=mailto:tlsrpt@beispiel.de

_mta-sts (MTA-STS signal):

v=STSv1; id=20250710T120000

The id must have 1–32 alphanumeric characters and signals to external servers that your domain supports MTA-STS. A date-timestamp is common — Google itself uses e.g. v=STSv1; id=20210803T010101 for google.com.

4. Test for two weeks, then switch to enforce

Let the policy run for two weeks in testing mode and analyze the TLS-RPT reports. If no legitimate servers fail, set mode: enforce in the policy file.

Important with every change: as soon as you change the policy file (including from testing to enforce), you must (a) update the file on the web server and (b) change the id in the _mta-sts TXT record to a new value — otherwise external servers won't notice the change.

Verify the result

Check your configuration with the free Kuveris scanner — it checks the _mta-sts record, fetches the policy file, and shows it together with TLS-RPT and your TLS status.

Common mistakes

Only set the DNS record. Without a reachable policy file at mta-sts.your-domain/.well-known/mta-sts.txt, MTA-STS is ineffective. Both parts belong together.

Invalid HTTPS certificate. The policy subdomain needs a certificate signed by a real CA — self-signed fails.

Forgot the id after a policy change. If you change the policy but not the id, external servers ignore the new version.

Straight to enforce. Without a testing phase you risk legitimate senders no longer being able to deliver on a TLS problem. First two weeks of testing, read reports, then enforce.