Will MTA-STS stop our emails going to spam?

No. MTA-STS protects mail in transit on the way in to your domain. It has no effect on how Gmail or Outlook judge the messages you send, and no effect on spam placement. SPF, DKIM, DMARC, sending reputation and list hygiene are what move that needle.

Can Google Workspace or Microsoft 365 host the MTA-STS policy file for us?

No. Both document that the domain owner publishes the file. Microsoft states that Exchange Online will not host policy files for customers, and Google's instructions are to upload the file to a web server you control, on a host whose name starts with mta-sts, over HTTPS with a certificate from a trusted authority.

What happens if we leave the policy in testing mode forever?

Nothing breaks, and nothing is protected either. In testing mode senders run the validation and send you TLS reports, then deliver the message whether it passed or failed. Only enforce mode makes a sender refuse an insecure connection, so testing is a staging step, not a destination.

MTA-STS on Google Workspace: records, policy, enforce mode

Say a 30-person logistics company wins work with a hospital group. In the onboarding paperwork sits a security questionnaire, and one line asks whether inbound mail to their domain is protected by MTA-STS. Nobody there has heard of it. Their mail runs on Google Workspace, SPF, DKIM and DMARC are all in place, and none of those three has anything to do with the question being asked.

This is how MTA-STS usually arrives at a small business: not as a deliverability complaint, but as a line item in somebody else's review. The work is small and the ways it breaks are specific, so it is worth doing properly once rather than half-publishing a record that reports nothing.

What MTA-STS does, and what it leaves alone

When one mail server hands a message to another, encryption is normally opportunistic. The sender asks whether TLS is available, the receiver says yes, and the conversation is encrypted. If the answer is no, or something in the middle removes the offer, most senders deliver in the clear rather than fail the message. That fallback is what MTA-STS takes away.

MTA-STS, specified in RFC 8461, lets the owner of a domain publish a policy that says three things: mail for this domain must arrive over TLS, these are the mail server hostnames allowed to receive it, and the certificate must be valid for those names. A sending server that supports the standard reads the policy, caches it, and from then on refuses to deliver when the connection cannot be secured. RFC 8461 points at RFC 6125 for the certificate check: the name has to match the MX hostname, and the certificate has to be unexpired.

Two consequences follow, and they get mixed up constantly.

It protects mail coming in to you, not mail going out. Your policy instructs other people's servers. It changes nothing about how your own messages leave.
It is not an authentication control. SPF, DKIM and DMARC decide whether a message is really from your domain. MTA-STS decides whether the connection that carried it was encrypted and whether the server on the other end was the right one. A domain can sit at DMARC p=reject and still accept mail over a plaintext connection.

Gmail reads what other domains publish: Google announced that support with a rollout beginning on 10 April 2019, and said in the same announcement that MTA-STS policies for your own domain are off by default. Microsoft documents the same arrangement for Exchange Online: inbound support is part of the service, and the domain owner publishes the policy.

The three pieces you publish

Two DNS records and one file on a web server. The first record signals that a policy exists:

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

The id is a version stamp of one to 32 alphanumeric characters. Google's guidance is to use the current date and time, so you can tell when the policy last changed, and to change it every time you edit the policy file. Senders cache policies, and the id is how they learn there is a newer one.

The policy itself is a plain text file. The filename must be mta-sts.txt, it sits in a .well-known directory on a host whose name starts with mta-sts, and the version line comes first:

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

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

The third piece is a separate record for the reports, defined by RFC 8460. Without it you enforce in the dark:

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

RFC 8460 allows mailto: and https: endpoints, and Google's documentation shows several mailto addresses separated by commas when more than one person should receive them. Create the mailbox before you publish the record.

The mx lines have to match the MX records you really have

This is where most first attempts go wrong. The policy needs an mx entry for every MX host on the domain, one per line. A wildcard is allowed, but replaces one leftmost label only, so *.example.com covers mail.example.com and not mail.eu.example.com.

For a Google Workspace domain the answer depends on which MX setup you are on. Google's current instruction is a single MX record, smtp.google.com at priority 1. Domains set up before 2023 usually still carry the legacy set Google documents, ASPMX.L.GOOGLE.COM plus ALT1 through ALT4.ASPMX.L.GOOGLE.COM. Those still work and need no change, but a policy written for one setup and published on a domain running the other fails validation, so read the live MX answer first. The one-label wildcard rule matters here: *.aspmx.l.google.com covers the four ALT hosts and not aspmx.l.google.com itself, so a legacy domain needs both lines.

If the domain sits on Microsoft 365 instead, Microsoft tells customers whose MX points directly at Exchange Online to use *.mail.protection.outlook.com, with the same version, mode and max_age values Microsoft publishes for its own domain. Microsoft also states plainly that Exchange Online will not host the policy file for a customer. Google says the same in different words: upload the file to a web server you control. Publishing the policy is a hosting job, not a mail setting, which is why it tends to be the part nobody owns.

Testing mode first, and what the reports tell you

The mode field takes three values. testing asks senders to run the validation and report the result, then deliver either way. enforce asks them to refuse delivery when validation fails. none retires a policy you no longer want honoured, which matters because senders may still hold a cached copy.

max_age is how long, in seconds, a sender may keep that cache. RFC 8461 caps it at 31557600, roughly a year, and notes the value is expected to be weeks or more, because a short lifetime hands an attacker more chances at refresh time. Google recommends between 86400 and 31557600 in general, and between 604800 and 1209600, one to two weeks, while the policy is in testing, so that a correction propagates in days rather than months.

Leave the policy in testing for a full reporting cycle. RFC 8460 says a report should cover a full day, 00:00 to 24:00 UTC, and arrives as a JSON file, so a week gives you roughly seven files from each reporting sender. What you want is not zero reports. It is reports whose failure counts are zero. A silent mailbox usually means the _smtp._tls record is wrong, not that everything is healthy.

Four ways the policy fetch fails

All of this is DNS and a static file, which sounds hard to get wrong. In practice four problems account for most broken policies we find.

A redirect. RFC 8461 accepts only an HTTP 200 for the policy fetch: 3xx redirects must not be followed, and HTTP caching must not be used. An apex-to-www rule applied across every subdomain, or hosting that quietly sends mta-sts.example.com to www.example.com, breaks the policy while the file itself is valid.
The wrong content type. Senders should check that the media type is text/plain. A host that serves unknown extensions as a generic binary type, or answers with an HTML error page, fails that check.
A certificate problem on the policy host. The mta-sts subdomain needs HTTPS with a certificate from a trusted public authority, and it needs to stay valid. That is a second certificate to keep alive, separate from the ones on your mail servers, and the one people forget because no human ever visits the page.
A stale id. Edit the policy, forget the id, and every sender holding a cached copy keeps using the old file until max_age expires. The symptom is a change that works for new correspondents and not for your biggest one.

What we check on a client domain before switching to enforce

The order matters, because the expensive mistake is enforcing a policy that does not describe the domain's real mail path.

Read the live MX answer and write the mx lines from that, not from a setup guide.
Confirm the certificate on each MX host matches the hostname in the policy and is not close to expiry. Google's stated requirement is TLS 1.2 or later, with a certificate matching the inbound mail server name and signed by a trusted root authority.
Fetch the policy URL from outside the network and look at the status code, the final URL and the content type, not only the body.
Check for an inbound gateway, filtering appliance or third-party archiver in front of the mailboxes. Anything that terminates SMTP for the domain has to appear in the policy with a matching certificate.
Publish the TLS reporting record and verify that a report actually arrives.
Run a week in testing, read every report, then change mode and bump the id in the same edit.

On a Workspace domain, the Admin console has a validator for exactly this, under Apps, Google Workspace, Gmail, Compliance. It shows the current state of the _mta-sts record, the policy file and the _smtp._tls record for each domain, and the security health page reports the status too. Treat it as a second opinion, after you have read the records yourself.

What changes the day you enforce, and what to watch after

After the flip, a sender that supports MTA-STS and cannot establish a valid TLS connection to one of your listed hosts will not deliver. That is the point, and also the new risk: your inbound mail now depends on certificates staying valid and on the policy still describing reality.

Three events should trigger a policy edit, each with a new id: changing MX records, adding or removing a mail gateway, and moving the domain between platforms. The migration case is the one that hurts. If you move from Microsoft 365 to Google Workspace while an enforcing policy still lists *.mail.protection.outlook.com, every MTA-STS-aware sender refuses mail that your new MX records are pointing at quite happily. Set mode: testing before the cutover, or retire the policy with mode: none and wait out max_age, then rebuild it on the new platform. The sequencing in our guide to changing MX records without downtime applies here too.

Then keep reading the TLS reports. They are the only routine signal that a certificate renewal or a DNS edit has quietly broken something.

How Guanacos Tech helps

We publish MTA-STS and TLS reporting for clients as part of the same engagement that fixes SPF, DKIM and DMARC, because both questions tend to arrive on the same security review. If you want it set up correctly the first time, or you have a policy published that reports nothing, our email deliverability consulting for small business covers it. A 30-minute call is enough to read your current records, say what state the domain is in, and agree the rollout order.

MTA-STS and TLS reporting on Google Workspace: the records, the policy file, and a rollout that drops no mail