Free MTA-STS Validator

Why use an offline validator

An MTA-STS syntax validator analyses your DNS TXT record and policy file without publishing them or hitting DNS. This offline approach covers three key use cases that live audits cannot address.

Typical use cases:

• Before deployment → Validate a draft policy before publication to avoid a misconfiguration in production.
• Multi-domain preparation → Verify several policies in batch during a migration or an internal audit.
• Offline debugging → Reproduce and fix an error without public DNS access, for example in an isolated or pre-production environment.
• Configuration review → Inspect a record received from a partner or exported by a third-party tool before applying it.

The validator applies RFC 8461 syntax rules: version, identifier, mode, MX patterns, max_age, and consistency between the DNS record and the policy. It never connects to a server, never resolves DNS, and never fetches any remote file.

How to use this validator in 3 steps

Step 1: paste the record and the policy

You can validate three combinations:

• Only the _mta-sts TXT record (mode record_only)
• Only the mta-sts.txt policy content (mode policy_only)
• Both together to check consistency (combined mode)

No network connection is made. Your data stays in your browser.

Step 2: add a domain (optional)

Adding a domain enables hybrid validation: the validator resolves the domain's MX records and checks that the patterns declared in the policy match the real servers. This mode helps detect an overly restrictive policy or a forgotten MX server.

Without a domain, only pure syntax is analysed.

Step 3: review the verdict

Results are classified by severity:

• ❌ Error → Blocking issue, the policy will be ignored by receiving MTAs
• ⚠️ Warning → Functional but improvement recommended
• ✅ Valid → Syntax compliant with RFC 8461

Fix each alert before publishing your record and your file in production.

Validator or record check: when to use each tool

The two tools are complementary. They do not replace each other: they intervene at different stages of an MTA-STS policy's life cycle.

Recommended workflow:

1. Design the policy → validator to check syntax
2. Publish DNS + file → wait for propagation
3. Record check to confirm the full live audit

The validator catches input errors before they reach your users. The record check catches drifts, expired certificates, and HTTPS fetch issues that only appear in real conditions.

Validation modes

The validator supports four modes depending on the fields you fill in.

Mode record_only

You paste only the TXT record. Validation of:

• v=STSv1 format
• id tag presence and format
• Unknown or duplicated tags

Mode policy_only

You paste only the policy file content. Validation of:

• version directive
• mode directive (enforce, testing, none)
• mx patterns (at least one required)
• max_age directive (bounds 0 to 31557600)

Combined record and policy mode

You paste both. Full validation plus:

• Version consistency between TXT and file
• Intent consistency (a mode: none with an active id is suspicious)

Hybrid mode with a domain

Add a domain to the combined mode to enable:

• Resolution of the domain's MX records
• Verification that each real MX matches at least one mx: pattern
• Detection of forgotten MX servers or patterns that are too strict

This MX validation stays static: it compares the patterns to the declared MX hosts without testing SMTP connections.

Syntax rules checked

DNS record

The validator applies RFC 8461 §3.1 rules on the _mta-sts.domain TXT record:

Valid example:

v=STSv1; id=20240115120000

Policy file

The validator applies RFC 8461 §3.2 on mta-sts.txt:

Valid example:

version: STSv1
mode: enforce
mx: mail.captaindns.com
mx: *.backup.captaindns.com
max_age: 604800

Consistency between record and policy

When both are provided:

• The id in the TXT must correspond to a coherent policy (a policy change implies a new id).
• mode: none with an active TXT is flagged: it often indicates an incomplete decommissioning.

Patterns MX and wildcard rules

RFC 8461 §4.1 defines a strict format for mx: patterns. The validator applies the following exact matching.

Exact hostname

mx: mail.captaindns.com
mx: smtp.captaindns.com

Matches the exact hostname, case-insensitively.

Wildcard pattern

mx: *.mail.captaindns.com

Strict rules:

• The wildcard * must be the leftmost label
• Matches exactly one label (server1.mail.captaindns.com matches, a.b.mail.captaindns.com does not)
• No double wildcard (**.captaindns.com is invalid)
• No wildcard in the middle or at the end (mail.*.captaindns.com is invalid)

Multiple patterns in a policy

A policy can contain several mx: lines:

mx: mail.captaindns.com
mx: smtp.captaindns.com
mx: *.backup.captaindns.com

A real MX must match at least one pattern. The validator flags orphan real MX hosts when a domain is provided.

Typical invalid patterns

Common syntax errors and fixes

Incorrect version

Cause: v=sts1, v=STSV1 or version: stsv1 instead of STSv1 exactly.

Fix:

- v=sts1; id=20240115
+ v=STSv1; id=20240115

Missing identifier

Cause: the TXT record does not contain the id tag.

Fix: add a unique identifier (timestamp recommended):

v=STSv1; id=20240115120000

Malformed id

Cause: spaces, special characters, or excessive length in id.

Fix: use only alphanumeric characters, 1 to 32 chars.

- id=my policy id
+ id=mypolicyid20240115

Invalid mode

Cause: mode: strict, mode: ENFORCE or a typo.

Fix: one of the three allowed values only:

- mode: strict
+ mode: enforce

max_age out of bounds

Cause: negative, non-numeric, or above 31557600.

Fix: integer in [0, 31557600]. Production-recommended value: 604800 (1 week).

- max_age: 99999999
+ max_age: 604800

Malformed pattern

Cause: misplaced wildcard or forbidden characters in an mx: line.

Fix: see the patterns MX section above.

- mx: mail.*.captaindns.com
+ mx: *.mail.captaindns.com

No mail server pattern

Cause: no mx: line in a policy in enforce or testing mode.

Fix: add at least one mx: line matching your infrastructure. In none mode, the absence of mx: is tolerated.

Complementary tools and resources

Related guides

• MTA-STS: the complete guide to securing your email transport - Configuration, deployment, and best practices.
• MTA-STS troubleshooting: common errors and fixes - Diagnose policy issues in production.
• Moving MTA-STS from testing to enforce mode - Progressive migration without breaking deliverability.

Specifications

• RFC 8461 - SMTP MTA Strict Transport Security (official specification)
• MTA-STS DNS record format (§3.1)
• MTA-STS policy file format (§3.2)
• Google MTA-STS documentation (Workspace guide)

FAQ - Frequently asked questions

Q: What is the difference between the validator and the MTA-STS record check?

A: The validator analyses syntax you paste, before publication, without touching DNS. The record check queries DNS and HTTPS to verify the published configuration. Use the validator upstream, the record check downstream.

Q: Why validate MTA-STS syntax offline?

A: To catch errors before they reach your users. An invalid policy is ignored by receiving MTAs: your domain stays exposed. Better to fix a typo in a draft than to diagnose a failure in production.

Q: What are common syntax errors?

A: The classics: STSV1 instead of STSv1, mode: strict instead of enforce, non-numeric max_age, misplaced wildcard (mail.*.captaindns.com), missing id tag in the TXT, or several version lines in the file.

Q: What MX pattern formats are valid?

A: Exact name (mail.captaindns.com) or single-label wildcard in leftmost position (*.mail.captaindns.com). No bare wildcard, no double wildcard, no wildcard in the middle of a name.

Q: What max_age values are recommended?

A: RFC 8461 requires 0 ≤ max_age ≤ 31557600 (1 year). Common values: 86400 (1 day) for testing phase, 604800 (1 week) for stable production, 31557600 (1 year) for a mature, fixed policy.

Q: How do I fix an 'invalid version' error?

A: The version must be exactly STSv1 (case-sensitive) in the TXT (v=STSv1) and in the policy (version: STSv1). Check the case, the spaces, and the absence of stray characters.

Q: How do I validate MTA-STS syntax for Microsoft 365?

A: Paste your TXT and your policy. Make sure your MX patterns cover *.mail.protection.outlook.com. The validator checks RFC 8461 compliance before DNS publication, then use the record check after deployment.

Q: How do I check MTA-STS syntax for Google Workspace?

A: Paste your TXT and your policy. Google MX hosts are at *.google.com (or aspmx.l.google.com). Make sure your patterns match those hostnames before publication.