Reading a policy file

After this lesson you can

Read any published policy and say exactly which hosts it permits and for how long.

Assumes you have read Three pieces, three failure points.

A policy file is four kinds of line. Reading one tells you which hosts a sender will accept for your domain and how long it will hold you to that.

The fields

Field	Values	Meaning
`version`	`STSv1`	The only version.
`mode`	`enforce`, `testing`, `none`	What a sender does when the policy is not satisfied.
`mx`	A hostname, or a wildcard on the leftmost label	Repeatable. The complete list of permitted MX hosts.
`max_age`	Seconds, up to 31557600	How long a sender caches this policy.

Two live policies

$ curl -s https://mta-sts.gmail.com/.well-known/mta-sts.txt

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

Checked 2026-09-15.

$ curl -s https://mta-sts.outlook.com/.well-known/mta-sts.txt

version: STSv1
mode: enforce
mx: *.olc.protection.outlook.com
max_age: 604800

Checked 2026-09-15.

The difference in max_age is the interesting part. Gmail commits for a day; Outlook for a week. A shorter value means senders refetch more often and you can change your MX hosts sooner — at the cost of more traffic to your policy host and a shorter window of protection if that host goes down.

The three modes

Mode	A sender that cannot satisfy the policy…
`enforce`	Does not deliver. This is the point of the mechanism.
`testing`	Delivers anyway, and reports the failure via TLS-RPT.
`none`	Ignores the policy. Used to withdraw one that senders have cached.

testing is not a lesser deployment — it is the deployment, for as long as it takes to confirm from reports that no legitimate sender is failing. Going straight to enforce means finding out from a sender who could not reach you.

Wildcards

A wildcard matches exactly one label, at the left. *.olc.protection.outlook.com matches eur01.olc.protection.outlook.com and does not match a.b.olc.protection.outlook.com. Every MX host must match some entry; one that does not is not deliverable to under enforce.

Knowledge check

A policy lists mx: mail1.example.com with max_age 604800. You add mail2.example.com to your MX set today. When can it receive from an MTA-STS-enforcing sender?

Not until that sender refetches the policy — up to seven days away, because max_age is what it cached.
Immediately, once the MX record propagates.
After the DNS TTL on the MX record expires.
As soon as you change the id in the TXT record.

Correct — Not until that sender refetches the policy — up to seven days away, because max_age is what it cached. The cached policy is authoritative for its full max_age, and a sender holding it will refuse a host the policy does not list. The new host has to be in the policy before it is in the MX set, not after.

Not this — Immediately, once the MX record propagates. The MX record tells a sender where to connect. The cached policy tells it which hosts are acceptable, and it is the policy that will reject this one.

Not this — After the DNS TTL on the MX record expires. MTA-STS caching is governed by max_age in the policy file, not by any DNS TTL.

Not this — As soon as you change the id in the TXT record. A changed id prompts a refetch when the sender next checks — which, for a sender holding a valid cached policy, may not be until it expires.

Last reviewed 2026-09-15

Reading a policy file

The fields

Two live policies

The three modes

Wildcards

Try it on a real domain