How to set up MTA-STS

MTA-STS, defined in RFC 8461, tells the world that your domain expects inbound mail to arrive over an encrypted, authenticated connection, and to refuse delivery if that connection cannot be made safely. Without it, the TLS used between mail servers is opportunistic: a sending server tries to encrypt, but if it cannot verify your server, or if an attacker quietly strips the encryption offer in transit, the mail is often delivered in the clear anyway. MTA-STS closes that gap by publishing a policy that sending servers must honour. The catch, and the reason it trips people up, is that MTA-STS is not a single DNS record. It is two moving parts that must agree: a small TXT record at _mta-sts, and a policy file served over HTTPS from a dedicated subdomain. This guide walks through both, then shows you exactly where to add them at the major DNS providers.

The two parts, and why both are required

A sending mail server discovers your MTA-STS policy in two steps. First it looks up the TXT record at _mta-sts.yourdomain.com. That record does not contain the policy itself; it contains only a version tag and an id, which acts as a version stamp so senders know when your policy has changed and needs re-fetching. Second, having seen the TXT record, the sender fetches the actual policy from a fixed HTTPS URL: https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. That file is where the real instructions live, listing your valid MX hosts, the enforcement mode, and how long the policy may be cached.

Both parts must be present and consistent. If the TXT record is missing, senders never look for the policy file. If the policy file is missing or unreachable over a valid HTTPS certificate, senders treat MTA-STS as not configured and fall back to opportunistic TLS. This is by design: a broken policy must never block your inbound mail, so the failure mode is simply "no MTA-STS", never "mail rejected". That safety net is also why you can roll this out without fear of an outage, provided you start in testing mode, which we come to below.

The records you publish

There are two things to publish: the DNS TXT record, and the policy file on a web server. Here is the TXT record value to copy:

v=STSv1; id=20260620000000Z

And here is the policy file, served at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt:

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

The DNS fields for the TXT record are as follows. Note that you may also want a second TXT record for TLS-RPT, covered later.

• Type: TXT
• Host / Name: _mta-sts (this becomes _mta-sts.yourdomain.com)
• Value: v=STSv1; id=20260620000000Z
• TTL: 3600 (one hour) is fine; the default Auto is also acceptable

You will also need a DNS record so that mta-sts.yourdomain.com resolves to wherever you host the policy file. That is usually a CNAME or A/AAAA record pointing at your web host or a static-hosting service, and the host you host on must present a valid TLS certificate for mta-sts.yourdomain.com.

A few words on each field of the policy file:

• version is always STSv1.
• mode is testing, enforce, or none. Always begin with testing.
• mx lists the MX hostnames that are allowed to receive your mail. List one mx: line per host. A wildcard such as *.yourdomain.com covers a set of hosts under one label. These must match the hostnames in your actual MX records exactly, because that is what senders verify the TLS certificate against.
• max_age is how long, in seconds, a sender may cache the policy. 604800 is one week, a common and sensible starting value. Longer caching is stronger against downgrade attacks but slower to react if you change MX hosts.

Start in testing mode, always

The single most important rule with MTA-STS is to begin with mode: testing. In testing mode, senders that support MTA-STS still attempt the verified-TLS connection your policy describes, but if it fails, they deliver the mail anyway and, crucially, send you a report saying it failed. Nothing is blocked. You get to watch, through the TLS-RPT reports described below, whether real sending servers can actually reach your MX hosts over valid TLS, with your real MX hostnames and your real certificate, before you ever instruct anyone to refuse delivery.

Only once those reports are clean across a representative window do you change the single word testing to enforce in the policy file. At that point any sender that cannot make a verified TLS connection to a listed MX host will refuse to deliver, which is the protection you want, but only after you have proven that legitimate senders are unaffected. This staged approach mirrors how you should bring up DMARC enforcement: monitor, confirm, then tighten, with no outage in between. When you move to enforce, increment the id in the TXT record (for example to a fresh timestamp) so caching senders re-fetch the updated policy.

Where to add the records

The TXT record goes wherever you manage DNS for the domain. The policy file goes on a web host that answers for the mta-sts subdomain over HTTPS. The instructions below cover the DNS side, where the common mistakes happen. A frequent one is the host field: many control panels automatically append your domain to whatever you type, so entering _mta-sts.yourdomain.com produces the doubled, broken name _mta-sts.yourdomain.com.yourdomain.com. Where a provider does this, enter only _mta-sts, without the domain suffix. Each section notes which behaviour applies.

Cloudflare

Open the Cloudflare dashboard, select your domain, and go to DNS > Records. Click Add record, set Type to TXT, set Name to _mta-sts, and paste v=STSv1; id=20260620000000Z into Content. Cloudflare appends the domain automatically, so enter only _mta-sts in the Name field, not the full name. Leave TTL on Auto and save. To host the policy file, add a separate CNAME (or proxied record) for mta-sts pointing at your host; if you proxy it through Cloudflare, Cloudflare's certificate will cover the subdomain. Cloudflare Workers or Pages can serve the static /.well-known/mta-sts.txt file with a valid certificate, which is a clean option on this platform.

GoDaddy

Sign in and go to My Products, find your domain, and choose DNS (or Manage DNS). Under Records, click Add, select Type TXT, and in the Name (host) field enter _mta-sts. GoDaddy appends your domain for you, so do not type the full _mta-sts.yourdomain.com or you will end up with a doubled name. Put v=STSv1; id=20260620000000Z in the Value field, set TTL to 1 Hour, and save. Add the policy-file host as a separate record so mta-sts.yourdomain.com resolves to your web host.

Namecheap

From the dashboard, go to Domain List, click Manage next to your domain, then open the Advanced DNS tab. Under Host Records, click Add New Record and choose TXT Record. In the Host field enter _mta-sts only; Namecheap appends the domain automatically, so the full name would double up. Paste v=STSv1; id=20260620000000Z into Value, set TTL to Automatic or one hour, and save with the green tick. Note that Namecheap's basic email forwarding does not host arbitrary web content, so you will serve the policy file elsewhere and point the mta-sts subdomain there.

Amazon Route 53

In the AWS console open Route 53 > Hosted zones and select your domain's zone. Click Create record, set Record type to TXT, and in Record name enter _mta-sts. Route 53 shows the parent domain beside the field and appends it for you, so type only the _mta-sts label. In Value, enter the quoted string "v=STSv1; id=20260620000000Z" (Route 53 expects TXT values wrapped in double quotes). Set TTL to 3600 and create the record. For the policy file, an A/ALIAS record for mta-sts can point at CloudFront or an S3 static site fronted by a certificate from AWS Certificate Manager that covers mta-sts.yourdomain.com.

Google Domains / Squarespace

Google Domains registrations now live in Squarespace Domains. From your Squarespace account, open the domain and go to DNS (or DNS Settings). Under custom records, add a record of type TXT, set the Host (or Name) to _mta-sts, and put v=STSv1; id=20260620000000Z in the Data/Value field. The domain is appended for you, so enter only _mta-sts. Save the record. Squarespace site hosting does not let you place a file at an arbitrary /.well-known/ path on a subdomain, so host the policy file on a separate service and point mta-sts there.

Microsoft 365 / Outlook DNS

If your DNS is managed through Microsoft, the records live with whoever hosts the zone rather than in the Microsoft 365 admin centre itself, which mainly guides you to add records at your registrar. Where Microsoft hosts the zone, go to the relevant DNS management page, add a TXT record with Host name (or Alias) _mta-sts and value v=STSv1; id=20260620000000Z, and save. Enter only the _mta-sts label; the domain is appended. The important Microsoft-specific point is the mx line in your policy file: a Microsoft 365 mailbox uses an MX host of the form yourdomain-com.mail.protection.outlook.com, so your policy file's mx: entry must list that exact hostname (Microsoft's certificate covers it), not a host under your own domain. Check your live MX record and copy the hostname precisely.

TLS-RPT: the reporting that makes testing mode useful

Testing mode only helps if you receive the failure reports it generates, and those come from TLS-RPT, a companion standard. You enable it with a second small TXT record, at _smtp._tls:

v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com

• Type: TXT
• Host / Name: _smtp._tls (enter only this label; the domain is appended)
• Value: v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com
• TTL: 3600

With this in place, supporting senders post you a daily summary of how many connections to your MX hosts succeeded or failed under your policy, and why. During testing mode this is exactly how you confirm that real-world TLS to your servers is healthy before you switch to enforce. Keep TLS-RPT on permanently; even after enforcement it is your early warning if a certificate expires or an MX change breaks verification.

Common mistakes and gotchas

A handful of issues account for almost every broken MTA-STS deployment, and all of them are avoidable.

• The doubled host name. As noted throughout, most control panels append your domain. Entering _mta-sts.yourdomain.com creates _mta-sts.yourdomain.com.yourdomain.com, which no sender will ever find. Enter only _mta-sts.
• An invalid or missing certificate on the policy host. The policy file must be served over HTTPS with a certificate that is valid for mta-sts.yourdomain.com and trusted by public roots. A self-signed certificate, an expired one, or one issued only for the apex domain will cause senders to ignore the policy entirely.
• The mx list not matching live MX records. The hostnames in your policy file's mx: lines must match your actual MX records, because that is what the sender's TLS certificate is checked against. List Microsoft 365's *.mail.protection.outlook.com host, or Google's, exactly as it appears in your MX, not an invented alias.
• Forgetting to bump the id when the policy changes. Senders cache by id. If you edit the policy file but leave the old id in the TXT record, caching senders will keep using the stale policy until max_age expires. Change the id (a timestamp is convenient) every time you change the file.
• The policy file in the wrong place. The path is fixed: /.well-known/mta-sts.txt on the mta-sts subdomain, served as text/plain. It must not redirect to another host, and the lines use Unix newlines.
• Staying in testing mode forever. Testing mode reports problems but blocks nothing, so it provides no protection on its own. Once your reports are clean, move to enforce. Leaving the policy at testing indefinitely is the MTA-STS equivalent of leaving DMARC at p=none.

MTA-STS sits alongside SPF, DKIM and DMARC as part of a complete email posture: those three authenticate the mail you send, while MTA-STS protects the encryption of the mail you receive. If you would rather not host and maintain the policy file, certificate and reporting yourself, our done-for-you MTA-STS hosts the policy on our infrastructure, keeps the certificate valid, monitors the TLS-RPT reports, and moves you from testing to enforce when the data says it is safe. You can review the full set of requirements on our requirements page, generate and inspect your policy with the MTA-STS checker, and browse the rest of our free tools while you build out the records.