MTA-STS Checker

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) lets a domain that receives email tell the servers that send to it: connect to my mail servers only over an encrypted connection, and only if the server shows a valid certificate. Without it, sending servers usually encrypt when they can but accept any certificate, and many fall back to an unencrypted connection when encryption fails. Someone who can interfere with the connection can then read or redirect the mail. With an MTA-STS policy in enforce mode, senders that support MTA-STS refuse to deliver instead.

MTA-STS has three parts, and all three have to be right:

This checker does what a sending server does, and a little more:

• looks up the _mta-sts TXT record and reads it by the exact rules of RFC 8461;
• fetches the policy file over HTTPS the way senders do: a trusted certificate for mta-sts.<domain>, no redirects followed, at most 64 KB (the size RFC 8461 suggests). We wait up to 10 seconds, while RFC 8461 suggests senders wait up to a minute, so a slower server gets “could not check” here, not a failure;
• reads every line of the policy and reports each mistake with its line;
• looks up your MX records and checks that each MX host matches one of the policy's mx: lines;
• in testing mode, checks that TLS reporting (TLS-RPT) is set up, because reports are what testing mode is for.

It does not connect to your mail servers to look at their own certificates. Senders that enforce your policy also check those; use the SMTP test for that part.

The panel at the top of the result is the verdict: a colored icon and a short label, Pass, Warning, Fail or Could not check. The findings under it say what we saw; each links to its explanation below.

Pass: the policy is in force

The TXT record and the policy file are valid, the policy is in enforce mode with a max_age of at least a week, and every MX host matches an mx: line. Senders that support MTA-STS will deliver to you only over a verified, encrypted connection.

MTA-STS is not set up, or not needed

Warning: MTA-STS is not set up. There is no _mta-sts TXT record. Mail still arrives, but senders cannot require encryption when they deliver to you. The details say what the policy address answered, which helps if you have started the setup. The fix under the result gives you a ready policy file, with mx: lines taken from your MX records, and the TXT record. See how to set up MTA-STS.

Warning: a policy file without a record. The file at mta-sts.<domain> looks like a policy, but the TXT record is missing. Senders look for the record first, so the file has no effect yet. Problems in the file are shown as warnings, because they do not affect mail until the record exists.

Nothing to check: MTA-STS does not apply. The domain publishes a null MX (a single MX record 0 ., RFC 7505), which says that it accepts no email. MTA-STS protects mail delivered to a domain, so there is nothing to protect, and the result shows a notice instead of a verdict. If the domain should receive mail, replace the null MX with your provider's MX records first.

Warning: the name is too long. _mta-sts. plus a very long domain name would be longer than the 253 characters DNS allows, so no record can exist for it.

The _mta-sts TXT record

There must be exactly one TXT record at _mta-sts.<domain> that starts with v=STSv1; and has an id of 1 to 32 letters and digits. If there is none or more than one, or the record is broken, senders act as if you had no policy at all.

• More than one record (Fail): delete all but one. Two records are often an old and a new one.
• Look-alikes (Fail, or Warning next to a valid record): v=stsv1, V=STSv1 or a space before v=. The version must be written exactly v=STSv1 and come first.
• Missing or invalid id (Fail): id=2026-09-22 is invalid because of the hyphens; use only letters and digits, for example id=20260922120000.
• Other syntax problems (Fail): an empty field (;;), a field without =, a space after the last field, characters outside plain ASCII. A repeated id is a warning: senders use the first one.

Change the id every time you change the policy file: the id is how senders notice that the policy changed. Otherwise they may keep the old policy until its max_age runs out.

Fetching the policy file

Senders fetch https://mta-sts.<domain>/.well-known/mta-sts.txt, and so do we. What can go wrong:

• The name mta-sts.<domain> does not exist (Fail): add an A, AAAA or CNAME record for mta-sts that points to the web server hosting the file.
• Not HTTP 200 (Fail): a 404 usually means the file is not in the .well-known folder or has another name. The file name is mta-sts.txt, all lower case.
• A redirect (Fail): senders must not follow redirects (RFC 8461 §3.3). A hosting panel that sends every request to www or to your main site breaks MTA-STS. Serve the file directly on mta-sts.<domain>.
• Larger than 64 KB (Fail): a real policy is a few lines. A large answer is usually a web page.
• HTTP 429, a timeout, or no connection (Could not check): this may be about our request, not about your server. Try again later.

The HTTPS certificate of mta-sts.<domain>

The policy host must present a certificate that a public certificate authority issued, that has not expired, and that is valid for the exact name mta-sts.<domain>. A certificate for example.com and www.example.com only is the most common mistake; a wildcard certificate for *.example.com covers mta-sts.example.com. The result shows the certificate's issuer, its expiry date, whether it matches mta-sts.<domain> and the names it covers. We check the chain against the Mozilla root store, the list of trusted authorities that Node.js ships with. The check covers the path we build from the server's certificate up to a root in that store: if a certificate on that path has expired, the result says so, even while the server's own certificate is still valid. With a self-signed or wrong certificate, senders ignore the policy.

The policy file content

A valid policy file looks like this, one field per line:

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

• Field names and values are case-sensitive: Mode: Enforce is not a mode. We name the line that looks close.
• version, mode and max_age appear once each; mx once per mail server pattern (not needed with mode: none).
• Lines end with a line feed or CR LF. A lone carriage return, a byte order mark at the start, blank lines between fields or lines that are not name: value are reported.
• The web server should send the file as text/plain. RFC 8461 tells senders to check that the type is text/plain, so we report another type or a missing Content-Type as a failure.
• An mx: line must be a host name without a trailing dot, port or URL, for example mx: mail.example.com. A wrong line next to valid ones is a warning; with no valid line left it is a failure.

When the file is valid, the result says so and shows the mode, the max_age and the mx: lines.

MX hosts and mx: lines

Every MX host of your domain has to match one mx: line. A line is either a full name (mail.example.com) or a wildcard for exactly one label: *.example.com matches mail.example.com but not example.com or a.b.example.com (RFC 8461 §4.1).

• An MX host is not covered: in enforce mode this is a failure, because senders that honor your policy will not deliver to that host. In testing mode it is a warning. The fix lists the lines to add.
• Null MX or no MX records while a policy is published (Warning): with a null MX the domain accepts no mail, so the policy protects nothing (with a null MX and no policy there is nothing to check, see above); without MX records senders deliver to the domain's own address, and RFC 8461 does not say how MTA-STS applies then.
• The MX lookup failed (Could not check): we could not compare, so we do not guess.

Modes: testing, enforce and none

• testing (Warning): senders deliver as before and send you TLS reports about failures. Use it first, for a week or two. Without a working TLS-RPT record at _smtp._tls.<domain> nobody tells you about failures, so testing mode achieves nothing; the result then says so and gives the record.
• enforce (Pass): senders that support MTA-STS do not deliver to a server that fails the checks. Switch to it when the reports are clean.
• none (Warning): the domain has no active policy. It exists to switch MTA-STS off safely (see the FAQ below).

max_age: how long senders keep the policy

max_age is in seconds: senders may keep the policy for up to that long after they last fetched it. The maximum is 31557600 (about a year); a larger value is invalid. RFC 8461 expects values of weeks or more. In enforce mode we warn below one week (604800): a short value gives little protection, because the policy expires between fetches. For testing mode Google recommends 604800 to 1209600 seconds (one to two weeks).

Could not check

A DNS server failed or timed out, the policy host did not answer in time, refused us with HTTP 429, or one of our safety limits stopped the check (the result then lists the limit). This says nothing about whether your MTA-STS setup works. We never turn a missing answer into a pass or a fail. Try again in a minute.

Could not check: a fault on our side

Rarely, the result says the check could not be completed because of an internal error. That is a fault in our software, not a finding about your domain and not a network problem, so trying again will most likely give the same result. Please write to [email protected] with the address of the result page, and we will fix it.

1. List your MX hosts. The result of this check shows them (or use dig MX example.com +short).
2. Write the policy file with one mx: line per MX host, in testing mode first:

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

3. Publish it at https://mta-sts.example.com/.well-known/mta-sts.txt: any web host that serves HTTPS with a trusted certificate for mta-sts.example.com, answers 200 and does not redirect. Add the DNS record for mta-sts that your web host asks for (A, AAAA or CNAME).
4. Add the TXT record _mta-sts with the value v=STSv1; id=20260922120000. Any id of letters and digits works; the date and time is easy to keep unique.
5. Add TLS reporting: a TXT record at _smtp._tls with v=TLSRPTv1; rua=mailto:[email protected], so senders tell you when delivery over TLS fails. Keep a single TLS-RPT record (RFC 8460 §3).
6. Check here, then read the reports for a week or two. When they are clean, change mode: testing to mode: enforce, and then change the id in the TXT record. Always in this order: update the file first, the TXT record second (RFC 8461 §8.1).

Google Workspace

Google gives new domains one MX record, smtp.google.com with priority 1, and still supports the older records that start with aspmx. The policy needs one mx: line for each MX record you actually have:

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

With the older records, list every MX host that our result shows. Google does not host the file for you: its instructions ask you to create the mta-sts subdomain on a web server that supports HTTPS with a certificate from a trusted certificate authority, and to put the file in the .well-known folder.

Microsoft 365 (Exchange Online)

If your MX record points to Exchange Online, Microsoft documents this policy:

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

Microsoft notes that this wildcard is specific to Exchange Online and must not be used as general advice. Exchange Online does not host the policy file; Microsoft suggests Azure Static Web Apps, which also issues the certificate for mta-sts.<domain>. If you move your domain to the DNSSEC-enabled MX record that ends in mx.microsoft, Microsoft's steps for MTA-STS are: before you enable DNSSEC, set the policy to testing, change the id, and wait until the old max_age has passed. When you add the new MX record, replace the old mx: line with the new host name and change the id again. When mail flows through the new MX as expected, set the policy back to enforce and change the id.

Zoho, SendGrid, Mailgun, Amazon SES and other providers

MTA-STS protects mail coming in to your MX hosts, so what matters is who receives your mail. For a hosted mailbox such as Zoho Mail, write one mx: line for each MX host your provider tells you to publish (our result lists the ones in DNS). Services that only send mail for you, such as SendGrid, Mailgun or Amazon SES sending, do not appear in the policy.

Cloudflare

1. In the DNS Records page, select Add record, Type TXT, Name _mta-sts, Content v=STSv1; id=20260922120000, then Save.
2. Add the record for the policy host: Type A, AAAA or CNAME with Name mta-sts and the target your web host gives you.
3. If you set that record to Proxied, Cloudflare presents its own certificate for mta-sts.example.com; Cloudflare serves a certificate only for proxied records. Its free Universal SSL certificate covers the domain and first-level subdomains only, so it does not cover mta-sts.mail.example.com.
4. Make sure no redirect rule sends requests for mta-sts to another address.

GoDaddy

1. In your Domain Portfolio, select the domain, then DNS and Add New Record.
2. Type TXT, Name _mta-sts, Value v=STSv1; id=20260922120000, then Save.
3. For the policy host, add a CNAME with Name mta-sts and the Value your web host gives you (or an A record with its IP address).

Namecheap

1. Open Domain List, select Manage, then the Advanced DNS tab and Add New Record.
2. TXT Record: Host _mta-sts, Value v=STSv1; id=20260922120000.
3. CNAME Record: Host mta-sts, Value the name your web host gives you. Namecheap adds your domain to the Host itself, and a CNAME blocks every other record with the same Host.
4. Select Save all changes. Namecheap says new records take about 30 minutes.

The TXT record and the policy file can be read with dig and curl:

dig +short TXT _mta-sts.gmail.com
curl -sS -D - https://mta-sts.gmail.com/.well-known/mta-sts.txt

On 22 September 2026 they returned this (headers shortened):

"v=STSv1; id=20190429T010101;"

HTTP/2 200
content-type: text/plain

version: STSv1
mode: enforce
mx: smtp.google.com
mx: gmail-smtp-in.l.google.com
mx: *.gmail-smtp-in.l.google.com
max_age: 86400

curl follows no redirects unless you add -L, so a 301 or 302 here means senders will not get your policy either. Compare the mx: lines with dig +short MX gmail.com.