DNSVerdictAll toolsGuidesHow it works

How to set up MTA-STS: DNS record and policy file

Published · Updated

MTA-STS tells other mail servers to deliver your mail only over validated TLS. It has two parts: a TXT record at _mta-sts.yourdomain that announces a policy exists, and a text file served over HTTPS at https://mta-sts.yourdomain/.well-known/mta-sts.txt that holds the policy itself. Start in testing mode, read the TLS reports, then switch to enforce.

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

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

Without MTA-STS, server-to-server SMTP encryption is opportunistic: an attacker who can alter traffic can strip the STARTTLS offer and force plaintext. The policy file lets a sending server know that TLS is required and which MX hosts are legitimate. Run the email score to see whether your domain publishes the TXT record.

What goes in the MTA-STS TXT record?

RFC 8461 §3.1 defines the record. It is published at _mta-sts under the policy domain, must be US-ASCII, and begins with v=STSv1. The id value is 1 to 32 letters or digits. Senders compare it with the one they cached to detect a changed policy, so change id every time you edit the policy file. A timestamp works well.

The policy file

Section 3.2 defines four keys, one per line. Unknown keys are ignored.

KeyMeaningValues
versionPolicy formatSTSv1
modeWhat senders do on failuretesting, enforce, none
mxAllowed MX host names; one line per hostexact name or *.example.net
max_ageCache lifetime in secondsinteger, maximum 31557600

A wildcard in an mx pattern matches only the whole left-most label, so *.example.com covers mail.example.com but not example.com or a.b.example.com (§4.1). The mx lines must match the names in your MX records, and the MX server’s certificate must name that host, so list the hostnames, not IP addresses. Check them with the DNS lookup.

For max_age, the RFC expects values of weeks or more once you are confident. During testing, a day (86400) limits how long a mistake stays cached.

Where do I host the policy file?

The file must be reachable at https://mta-sts.<domain>/.well-known/mta-sts.txt (§3.3). Requirements from that section:

Any static host that can serve a TLS certificate for mta-sts.yourdomain works: your web server, an object-storage bucket behind a CDN, a static-site host, or, on Cloudflare, a Worker or a Pages site bound to that hostname. Point the mta-sts DNS name at it and confirm the URL opens in a browser with no certificate warning. The mail servers also need valid certificates: per §4.2 the certificate on each MX host must be unexpired, chain to a trusted root, and include the MX hostname.

How do I move from testing to enforce safely?

  1. Publish the policy with mode: testing and the TXT record. In testing mode, failures are reported but mail is still delivered (§5).
  2. Add a TLS-RPT record so senders send you failure reports. Without it, testing mode tells you nothing.
  3. Read reports for two to four weeks. Look for MX names not covered by the policy, expired certificates, and servers without STARTTLS.
  4. Change mode to enforce, update id in the TXT record, and raise max_age in steps (a week, then a month).

Risk of enforce: a sender that supports MTA-STS will not deliver to an MX host that fails certificate validation or the mx match. An expired certificate on your mail server then means delayed or bounced mail from those senders, until it is fixed. Monitor certificate expiry on the MX hosts and on the mta-sts host.

To back out, publish mode: none and update the id, then keep the file up long enough for senders to fetch it before you remove the records (§8.3).

What DNSVerdict can and cannot check

DNSVerdict checks the _mta-sts TXT record. It does not read the policy file. A browser can read a cross-origin response only when the server sends CORS headers, and policy hosts have no reason to send them, so a browser-only tool cannot fetch the file. Open the URL yourself or use curl -i https://mta-sts.example.com/.well-known/mta-sts.txt, and confirm status 200, text/plain, and no redirect.

FAQ

Do I need MTA-STS if I use DMARC? Yes, if you want encrypted delivery, because the two solve different problems. DMARC (RFC 9989) lets receivers judge whether mail claiming to be from your domain is genuine. MTA-STS (RFC 8461) protects the SMTP connection that carries mail to your servers, so an attacker cannot strip STARTTLS. It affects inbound mail to your domain only.

Does MTA-STS need DNSSEC, or replace DANE? MTA-STS does not need DNSSEC, and it does not replace DANE. RFC 8461 §2 says DANE requires DNSSEC, while MTA-STS relies on certification authorities and does not require DNSSEC, at the cost of risking malicious downgrades. A domain without DNSSEC can therefore still deploy it, but DANE gives stronger protection where DNSSEC is available.

I changed the policy but senders still use the old one. Why? Senders cache a policy for max_age seconds and compare the id in your TXT record with the cached one to decide whether to refetch it (RFC 8461 §3.1 and §5). If you edit the file without changing id, senders keep the old policy until the cache expires. Change id on every edit, and keep max_age short while testing.

Sources

Tools used

Email Deliverability ScoreDMARC Record CheckerDNS Lookup