How to Set Up MTA-STS for Your Domain (Step by Step)

MTA-STS tells other mail servers to use encrypted TLS when they deliver mail to your domain, and to refuse to deliver rather than fall back to plaintext. Setting it up takes three moving parts: one DNS record, one small file served over HTTPS, and a deliberate move from testing to enforce mode.

This guide covers how to set up MTA-STS for a domain step by step, in the order that avoids breaking inbound mail. It also covers the certificate and MX-name details that cause most first attempts to fail validation, since those are where nearly every rollout stalls.

What MTA-STS actually protects#

MTA-STS (SMTP MTA Strict Transport Security) is defined in RFC 8461. It is published by the domain that receives mail, and it instructs sending servers to use STARTTLS with a valid certificate — or to refuse delivery instead of downgrading to an unencrypted connection.

That refusal is the whole point. Standard STARTTLS is opportunistic, so an attacker positioned on the network path can strip the TLS offer and read or alter mail in transit. MTA-STS closes that downgrade path for every sender that supports the standard.

It does not protect mail you send, and it is not a replacement for SPF, DKIM or DMARC. Those authenticate who sent a message; MTA-STS protects the transport of mail arriving at your domain. You want both.

Before you start#

You need three things in place before you publish anything.

• Control of your domain's DNS, so you can add a TXT record and a new subdomain.
• An HTTPS host reachable at mta-sts.yourdomain.com, with a certificate valid for that exact hostname.
• A current list of every MX hostname that receives your mail — check your live MX records, including any secondary or backup MX.

It also helps to set up TLS-RPT first, so TLS failures get reported to you while you are still in testing mode. That reporting is the safety net that lets you reach enforce mode on evidence instead of a guess.

How to set up MTA-STS, step by step#

1. 1

   Confirm every MX host supports STARTTLS

   Look up your live MX records, then test that each MX host offers STARTTLS and presents a valid, non-expired certificate matching its own hostname. If any MX fails this, enforce mode will refuse mail to it — fix the MX first.

2. 2

   Stand up the policy host over HTTPS

   Create the subdomain mta-sts.yourdomain.com and serve it over HTTPS. The certificate must be valid for mta-sts.yourdomain.com specifically. A certificate that only covers your apex domain is the single most common cause of a policy that fails validation.

3. 3

   Publish the policy file in testing mode

   Host a plain-text file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. Set mode to testing, list every MX pattern, and set a max_age in seconds. Serve it as text/plain with an HTTP 200 — senders must not follow a 3xx redirect to reach it.

4. 4

   Publish the _mta-sts TXT record

   Add a TXT record named _mta-sts.yourdomain.com with the value v=STSv1; id=<unique-id>. The id is any string of up to 32 letters or digits; a timestamp such as 20260816120000Z is a common choice. Senders read this record to discover that a policy exists.

5. 5

   Watch the TLS-RPT reports

   In testing mode delivery is never blocked, but senders that support TLS-RPT report any TLS or MX-matching failures to you. Leave it in testing for at least a week and read the reports. Zero failures across your real senders is your signal to proceed.

6. 6

   Switch to enforce and update the id

   Change mode to enforce in the policy file, then change the id in the TXT record so senders refetch the new policy. Until the id changes, a cached policy can stay live for up to its max_age. From here, compliant senders refuse to deliver over an untrusted connection.

The DNS TXT record format#

The TXT record is small and rarely changes. Its only job is to announce that a policy exists and to signal, through the id, when that policy has been updated. Per RFC 8461 only STSv1 is a valid version, and the id is one to 32 letters or digits.

The policy file (an mta-sts.txt example)#

The policy file carries the real rules. version, mode and max_age are always required; mx is required in testing and enforce mode. Each mx line is an allowed MX hostname pattern, and a leading wildcard matches exactly one left-most label — so *.example.com matches mail.example.com but not example.com.

max_age is in seconds, up to a maximum of 31557600 (about a year). A value of 604800 — one week — is reasonable while you test; raise it once enforce is stable so senders cache the policy longer.

Where you host the policy: platform differences#

MTA-STS is a standard, so the record and file look the same everywhere. What differs is where you host the policy file and whether your provider automates any of it. As of August 2026, check your provider's own documentation — these setups change.

How a sending server checks your policy#

It helps to picture what a sending server does with all this. When it has mail for your domain, it reads the _mta-sts TXT record, and if the id has changed it fetches the policy file over HTTPS. It then checks that the MX it is about to use matches an mx pattern and presents a valid certificate.

In testing mode a failure at any of those steps is reported but the mail still goes through. In enforce mode the same failure means the message is not delivered over that connection. That difference is the entire reason you test before you enforce.

What to do when it doesn't work#

Almost every failed first attempt comes down to one of a few causes. Work down this table before you assume the standard is at fault.

After the transport is secured: where an inbox layer fits#

MTA-STS secures the pipe into your domain, but it does not judge what travels through it. A convincing phishing message delivered over a perfectly valid TLS connection is still a phishing message — encryption protects the transport, not the intent. Sorting real mail from that is a different job, done by the client after delivery, not by the policy.

That inbox-side job is what AI Emaily does: it treats every incoming message as untrusted input and runs AI spam protection over what lands, keeping outreach and phishing attempts out of the way while approve-before-send keeps you in control of replies. It is a mail client, not a deliverability or DNS tool — it will not set up MTA-STS for you, and this guide's manual steps are still the way to do that. We build AI Emaily.