MTA-STS Configuration Issues: DNS Record and Policy File Errors

What This Error Means

The mxio MTA-STS Checker groups several configuration errors that indicate your MTA-STS DNS record or policy file is syntactically incorrect or operationally ineffective. Unlike a missing policy (where MTA-STS is simply absent), these errors mean MTA-STS is partially deployed but misconfigured.

The error codes:

Each issue has a different impact and a different fix. This article covers all five.

Why This Matters

MTA-STS configuration errors degrade your domain's email transport security in ways that are difficult to detect without explicit checking. A missing id field breaks the caching mechanism that makes MTA-STS efficient. A bad version string causes compliant sending servers to discard the entire policy. A mode: none setting actively disables enforcement. Short max_age values create windows where your policy is not in effect.

None of these errors generate bounce messages. Senders silently fall back to opportunistic TLS or ignore the policy entirely. Your mail server still receives email — but without the man-in-the-middle protection that MTA-STS is designed to provide.

How to Diagnose

Check the DNS Record

The MTA-STS DNS record is a TXT record at _mta-sts.yourdomain.com. Query it:

dig TXT _mta-sts.yourdomain.com

A correctly formatted record:

v=STSv1; id=20260408;

The record must contain both v=STSv1 and an id= field with a non-empty value.

Check the Policy File

The policy file is served at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. Fetch it:

curl https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

A correctly formatted policy:

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

The file uses a simple key-value format with one field per line. Required fields: version, mode, max_age, and at least one mx entry.

Use the MTA-STS Checker

The mxio MTA-STS Checker validates both the DNS record and the policy file, reporting each configuration error with its specific code and the value that caused it.

How to Fix

Missing ID Field (MTASTS_NO_ID)

The problem: Your DNS TXT record at _mta-sts.yourdomain.com does not contain an id field. The record might look like:

v=STSv1;

Why it matters: The id field is how sending servers know when your policy has changed. Senders cache the MTA-STS policy for the duration specified by max_age. They periodically check the DNS record, and if the id value has changed, they re-fetch the policy file. Without an id, the caching mechanism is broken — senders may not re-fetch the policy when you update it, or they may re-fetch it on every connection (wasting resources and adding latency).

The fix: Add an id field to the DNS TXT record. The value can be any string — a date stamp, a version number, a random identifier. The only requirement is that you change it whenever you update the policy file.

v=STSv1; id=20260408;

Update the TXT record in your DNS provider's control panel. The change takes effect once DNS propagation completes (typically minutes, up to a few hours depending on TTL).

Bad Version (MTASTS_BAD_VERSION)

The problem: The version line in your policy file is not STSv1. The file might contain:

version: STS1

or

version: 1.0

or the version line might be missing entirely.

Why it matters: RFC 8461 requires the first line of the policy file to declare version: STSv1. Any other value — or a missing version line — makes the policy unrecognized. Compliant sending servers discard the entire policy and fall back to opportunistic TLS. Your MTA-STS deployment is effectively non-functional.

The fix: Ensure the first line of the policy file is exactly:

version: STSv1

The value is case-sensitive. STSv1 is the only valid version as of RFC 8461. Update the policy file on your web server and update the id in your DNS TXT record to signal the change.

Mode None (MTASTS_MODE_NONE)

The problem: Your policy file specifies mode: none:

version: STSv1
mode: none
max_age: 604800
mx: mail.yourdomain.com

Why it matters: Mode none is a valid MTA-STS mode, but it explicitly tells sending servers not to enforce TLS requirements. It is the MTA-STS equivalent of "ignore this policy." The intended use case is decommissioning: when you want to remove MTA-STS, you first set mode to none (so senders with cached policies stop enforcing), wait for the max_age to expire, then remove the DNS record and policy file.

If you are not in the process of decommissioning MTA-STS, mode none means your deployment is doing nothing. You have the infrastructure (DNS record, HTTPS-hosted policy file) but no enforcement.

The fix: Set the mode to either testing or enforce:

• testing — Senders fetch and evaluate the policy but do not enforce it. Failed TLS connections still result in delivery. Senders generate TLS-RPT reports that you can use to identify issues before turning on enforcement. Use this when first deploying MTA-STS or after significant infrastructure changes.
• enforce — Senders require TLS and valid certificates for delivery to your MX hosts. Failed TLS means no delivery. Use this once you have confirmed your mail servers have valid certificates and MTA-STS is working correctly.

version: STSv1
mode: enforce
max_age: 604800
mx: mail.yourdomain.com

After changing the mode, update the id in your DNS TXT record.

Unknown Mode (MTASTS_UNKNOWN_MODE)

The problem: The mode field contains a value that is not enforce, testing, or none. Common typos:

mode: enforced
mode: test
mode: strict
mode: enabled

Why it matters: Sending servers that do not recognize the mode value may discard the policy entirely, treating your domain as if MTA-STS is not deployed. The behavior depends on the sending server's implementation, but the safest assumption is that an unknown mode is treated as an error.

The fix: Set the mode to one of the three valid values: enforce, testing, or none. The values are case-sensitive and must be lowercase.

mode: enforce

Update the policy file and bump the DNS id.

Short Max Age (MTASTS_SHORT_MAXAGE)

The problem: The max_age value in your policy file is less than 86400 seconds (1 day):

version: STSv1
mode: enforce
max_age: 3600
mx: mail.yourdomain.com

In this example, max_age: 3600 means the policy expires after 1 hour.

Why it matters: max_age controls how long sending servers cache your MTA-STS policy. Between cache refreshes, there is a window where a sender does not have your policy loaded. During that window, the sender falls back to opportunistic TLS — no certificate validation, no enforcement. An attacker who can perform a man-in-the-middle attack during a cache gap can downgrade the connection.

A 1-hour max_age means the policy is unloaded and re-fetched 24 times per day. Each re-fetch is a window where the old policy has expired and the new one has not been loaded yet. A longer max_age minimizes these gaps.

RFC 8461 does not mandate a minimum max_age, but recommends values in the range of weeks to months. Common values:

The fix: Set max_age to at least 86400 (1 day). For production deployments with stable infrastructure, use 604800 (1 week) or higher:

max_age: 604800

A shorter max_age is acceptable temporarily during migrations or when you expect to make frequent policy changes. Increase it once your configuration stabilizes.

After changing max_age, update the id in your DNS TXT record so senders re-fetch the policy with the new expiration time.

Prevention and Ongoing Monitoring

MTA-STS configuration errors are typically set-once-and-forget problems. The DNS record and policy file are created during initial deployment, and if they contain errors at that point, the errors persist indefinitely because MTA-STS failures are silent.

The prevention strategy:

• Validate before deploying. After creating the DNS record and policy file, run the mxio MTA-STS Checker before considering the deployment complete. Catch errors on day one.
• Update the id on every policy change. This is the most commonly forgotten step. The policy file changed but the DNS id did not, so senders keep using the cached old version.
• Monitor continuously. Set up domain health monitoring to check your MTA-STS configuration alongside your other email authentication records. Monitoring catches configuration drift — a policy file that disappears after a server migration, a DNS record that gets accidentally deleted, or a certificate that expires and breaks the HTTPS policy endpoint.
• Set up TLS-RPT. Publish a _smtp._tls.yourdomain.com TXT record with a reporting address. Sending servers that support TLS-RPT (RFC 8460) send you reports when MTA-STS policy evaluation fails, giving you visibility into problems from the sender's perspective.

Related Issues

• MTA-STS Policy Not Found — DNS record or policy file is entirely missing
• MTA-STS MX Mismatch — Policy does not cover all MX hosts
• STARTTLS Required Error — TLS negotiation failures in SMTP
• SMTP Server Test Explained — Testing SMTP connectivity and TLS support