MTA-STS glossary
What does v=STSv1 mean in an MTA-STS record?
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 15, 2026
v=STSv1 is the version tag of an MTA-STS DNS record — a TXT record published at _mta-sts.<domain> in the form v=STSv1; id=<token>. It announces that your domain has an MTA-STS policy; the actual rules live in an HTTPS policy file. The id is an opaque token senders cache — it must change whenever the policy file does.
v=STSv1 at a glance | |
|---|---|
| Tag | v (version) |
| Valid values | STSv1 — the only version defined by RFC 8461 |
| Default | Required — a TXT record that doesn't start with v=STSv1 is not a valid MTA-STS record. |
| Where it goes | First tag of the TXT record at _mta-sts.<domain>, e.g. v=STSv1; id=20260715120000 |
How v=STSv1 works
MTA-STS splits its configuration across DNS and HTTPS, and the TXT record at _mta-sts.<domain> is the DNS half. It's deliberately tiny — just v=STSv1 and an id — because its only job is to tell sending servers that a policy exists and to go fetch it over HTTPS. The rules themselves (mode, mx, max_age) live in the mta-sts.txt policy file.
The id is an opaque token — up to 32 letters and digits with no meaning of its own. Senders don't parse it; they compare it. A sender holding a cached copy of your policy checks this cheap DNS record on later deliveries: if the id matches the one it cached, it keeps using the cached policy without refetching the file.
That's why the one iron rule of this record is: change the id every time the policy file changes. Edit mta-sts.txt and leave the id alone, and senders will keep enforcing the old cached policy until their cache expires — which, with a well-chosen max_age, can be weeks away.
Correct record vs common mistake
Correct
v=STSv1; id=20260715T120000A version tag and a fresh id — timestamps make good ids because every policy change gets an unambiguous new value.
Common mistake
v=STSv1; id=20250101T000000The policy file changed but the id didn't. Senders compare the id against their cache, see no change, and keep enforcing the **old** policy until it expires.
Troubleshooting v=STSv1
| Issue | Likely cause | Fix |
|---|---|---|
| Senders still applying an old policy | mta-sts.txt was updated but the id in the DNS record wasn't changed | Bump the id to any new value (a timestamp works) every time the policy file changes |
| Policy not discovered at all | TXT record published at the apex or under a mistyped name | Publish it at exactly _mta-sts.<domain>, e.g. _mta-sts.yourdomain.com, and re-test |
| Record present but treated as invalid | Multiple STSv1 TXT records left behind after a change | Keep exactly one — senders that find more than one treat the domain as having no valid record |
See this on your own domain
Enter your domain — the check runs instantly on the next page. Free, no signup.
Why it matters for MSPs
The DNS-plus-HTTPS split doubles the surface for drift, and the stale-id mistake is invisible: the DNS record looks right, the policy file looks right, but half the internet is still enforcing last quarter's policy. Across 50–200 client domains, you lose the ability to say with confidence which policy any given tenant is actually running.
Trusted by MSPs
“We increased our meetings booked by 21% and slept better at night knowing our emails are now secured”
Marc-André Campagna — CEO, gaiia (YC 2021)Read the case study →
Enforce it — don't just monitor it
Palisade doesn't just check this record — it **hosts and automates** the whole MTA-STS setup: it publishes the DNS record, serves the policy file, and bumps the `id` automatically on every change, for every client domain. Most vendors only tell you when it's broken.
Free 15-day trial · No credit card · Your own domain free forever (NFR)