MTA-STS MX Mismatch: Policy Doesn't Cover All Mail Servers

What This Error Means

The mxio MTA-STS Checker reports this error when the mx: entries in your MTA-STS policy file do not match the MX records published in your domain's DNS.

MTASTS_MX_MISMATCH — One or more MX hosts in your DNS are not covered by any mx: line in the policy file. The policy exists and is reachable, but it does not authorize all the mail servers your domain actually uses.

MTASTS_NO_MX — The policy file contains no mx: lines at all. Without mx entries, the policy does not authorize any mail server to receive email for your domain.

In both cases, the MTA-STS policy is incomplete. Sending servers that enforce MTA-STS may refuse to deliver email to mail servers not listed in the policy, because the entire purpose of MTA-STS is to tell senders which servers are legitimate and require TLS verification.

Why This Matters

MTA-STS works by giving sending servers a whitelist of authorized mail servers for your domain. When a sending server looks up your MX records, it checks each MX host against the mx: entries in your MTA-STS policy. If an MX host is not in the policy, the sending server faces a decision:

• In enforce mode: The sender should not deliver to that MX host. If all MX hosts are unlisted, the email is not delivered at all. If only some are unlisted, the sender skips the unlisted ones and tries only the policy-approved servers. This reduces your delivery redundancy.
• In testing mode: The sender delivers anyway but generates a TLS-RPT report flagging the mismatch. No email is lost, but the report signals a configuration problem.

The most dangerous scenario is a partial mismatch — your primary MX is in the policy but your backup MX is not. Email flows normally until your primary server goes down. When senders try the backup, MTA-STS enforcement blocks delivery to the unlisted backup server. Your failover stops working exactly when you need it most.

Example

Your DNS MX records:

yourdomain.com.  MX  10  mx1.mailprovider.com.
yourdomain.com.  MX  20  mx2.mailprovider.com.

Your MTA-STS policy file:

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

The policy says mail.yourdomain.com, but your MX records point to mx1.mailprovider.com and mx2.mailprovider.com. Neither MX host matches. A sending server enforcing MTA-STS will not deliver to either server.

How to Diagnose

Step 1: Check Your MX Records

Query your domain's MX records to see which mail servers are currently listed:

dig MX yourdomain.com

Note every hostname in the response. These are the servers that need to appear in your MTA-STS policy.

Step 2: Check Your MTA-STS Policy

Fetch the policy file and examine the mx: lines:

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

Compare the mx: entries against your MX records from step 1. Every MX host must be covered by at least one mx: line.

Step 3: Understand Pattern Matching

MTA-STS mx: entries support wildcard matching with a leading dot-asterisk pattern. The rules:

The wildcard * matches exactly one label. It does not match nested subdomains. If your MX hosts are mx1.us.mailprovider.com and mx2.us.mailprovider.com, the pattern *.mailprovider.com does not cover them — you need *.us.mailprovider.com.

Step 4: Use the MTA-STS Checker

The mxio MTA-STS Checker performs this comparison automatically. It fetches your MX records and your MTA-STS policy, matches each MX host against the policy's mx entries, and reports exactly which hosts are covered and which are not.

How to Fix

Update the Policy File

Edit the policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt to include all current MX hosts.

If all MX hosts share a common domain suffix, use a wildcard:

version: STSv1
mode: enforce
max_age: 604800
mx: *.mailprovider.com

If MX hosts span multiple domains, list each pattern:

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

If you use exact hostnames, list every MX host individually:

version: STSv1
mode: enforce
max_age: 604800
mx: mx1.mailprovider.com
mx: mx2.mailprovider.com
mx: backup.yourdomain.com

Each mx: line specifies one hostname or pattern. Include as many lines as needed to cover all MX hosts.

Update the DNS Record ID

After changing the policy file, update the id value in your _mta-sts DNS TXT record:

v=STSv1; id=20260408b;

The id change signals to sending servers that the policy has been updated. Senders cache MTA-STS policies and only re-fetch when the id changes. If you update the policy file but not the id, senders continue using the cached version with the old mx entries — potentially for weeks, depending on the max_age value.

After a Mail Provider Migration

Mail provider migrations are the most common cause of MX mismatches. When you change email providers:

1. Update your MX records in DNS (you already did this or email would not work)
2. Update the MTA-STS policy file with the new provider's MX hostnames
3. Update the DNS TXT record id to bust the cache
4. Verify with the mxio MTA-STS Checker

If you are mid-migration (running both old and new providers temporarily), the policy should list MX hosts from both providers until the migration is complete.

Verify the Fix

After updating the policy:

1. Confirm the policy file: curl https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
2. Confirm the DNS id was updated: dig TXT _mta-sts.yourdomain.com
3. Run the mxio MTA-STS Checker to confirm all MX hosts are now covered
4. Use the mxio MX Lookup to verify your MX records are correct

Prevention and Ongoing Monitoring

MX mismatch is almost always a change management problem. The MTA-STS policy was correct when it was first deployed, then MX records changed and nobody updated the policy. This happens during:

• Mail provider migrations — switching from one email host to another
• Adding a new sending service — a marketing platform or transactional email service with its own MX entries
• DNS changes — reorganizing DNS records, changing hostnames, updating priorities
• Provider-side changes — your email provider changes their MX hostnames (rare, but it happens)

The fix is monitoring. Set up domain health monitoring to continuously check that your MTA-STS policy matches your MX records. When your MX records change — whether intentionally or accidentally — monitoring catches the mismatch before it causes delivery failures.

Consider using wildcard patterns in your mx: entries when possible. A wildcard like *.mailprovider.com absorbs hostname changes within the same provider without requiring a policy update.

Related Issues

• MTA-STS Policy Not Found — DNS record or policy file is missing entirely
• MTA-STS Configuration Issues — Syntax errors in the DNS record or policy file
• Missing MX Records — No MX records published for the domain
• STARTTLS Required Error — TLS negotiation failures in SMTP
• SMTP Server Test Explained — Testing SMTP connectivity and TLS