MTA-STS Record Check: How to Audit Email Transport Security

An MTA-STS record check reviews whether a domain has published the DNS marker and HTTPS policy file needed for SMTP MTA Strict Transport Security. For agencies, the practical audit is: does _mta-sts.example.com exist, does https://mta-sts.example.com/.well-known/mta-sts.txt return a valid policy, does the policy match the domain's MX hostnames, and is the mode appropriate for the client?

MTA-STS helps receiving domains publish transport-security expectations for inbound email. It does not guarantee deliverability. It tells supporting senders how to treat TLS when delivering mail to the domain, but it still depends on sender support, MX configuration, certificates, and a reachable policy file.

Use Inbox Pulse for bulk email-authentication and transport-security checks across client domains. Use the broader 10-domain agency audit when you also need SSL, DNS, and domain expiry context. For how CertPilot checks public DNS and related records, see how CertPilot checks domains.

What MTA-STS is

MTA-STS is a policy mechanism for inbound email transport security. It lets a receiving domain publish a policy saying, in effect:

When other mail servers deliver mail to us, they should use TLS and validate the certificate for our MX hosts according to this policy.

It is designed to reduce downgrade and interception risks in SMTP transport for supporting senders. It is separate from SPF, DKIM, and DMARC. Those authenticate senders and domain alignment. MTA-STS focuses on transport security for inbound delivery to the domain's mail servers.

For broader email-authentication context, read DMARC, SPF, and DKIM explained for agencies.

What an MTA-STS Checker Should Look For

An MTA-STS checker should review both DNS and the HTTPS policy file. The DNS record announces that a policy exists. The policy file explains the expected mode, MX patterns, and cache duration.

| MTA-STS signal | What it means | Common issue | Agency action | |---|---|---|---| | _mta-sts TXT record | Public marker that points senders toward an MTA-STS policy | Missing, typoed, or stale id | Confirm the DNS host and update the marker when policy changes | | HTTPS policy file | The policy at https://mta-sts.domain/.well-known/mta-sts.txt | File missing, redirects to HTML, or HTTPS fails | Fix hosting, certificate, or routing before enforcement | | mode: none/testing/enforce | Current policy posture | enforce used before validation | Use testing during rollout and enforce only after review | | mx entries | Which MX hostnames the policy covers | Old mail provider or incomplete patterns | Compare against current MX records | | max_age | How long senders may cache the policy | Too long during testing or too short for mature setup | Match cache duration to rollout confidence | | TLS-RPT record, if present | Reporting destination for transport-security failures | Reports go to an unmonitored mailbox | Assign an owner for report review |

A static public check can confirm whether these signals appear reachable and consistent. It cannot prove every sender will behave the same way, review private mail-provider settings, or replace a real rollout plan.

The two parts of MTA-STS

An MTA-STS setup has two main public pieces:

| Piece | Location | Purpose | |---|---|---| | DNS TXT marker | _mta-sts.example.com | Tells senders an MTA-STS policy exists and provides an ID | | HTTPS policy file | https://mta-sts.example.com/.well-known/mta-sts.txt | Publishes mode, MX patterns, and max age |

Both matter. A DNS marker without a reachable policy file is incomplete. A policy file without the right DNS marker may not be discovered as intended.

The DNS record at _mta-sts

The DNS record is a TXT record under _mta-sts.

Example:

_mta-sts.example.com TXT "v=STSv1; id=2026050701"

The id value is used to signal policy updates. When the policy changes, the ID should change. Agencies should not treat the exact ID format as universal; the important point is that it exists and changes when policy meaningfully changes.

Common mistakes include:

• Missing _mta-sts TXT record.
• Typo in the hostname.
• Old ID after policy changes.
• Record published at the wrong DNS provider.
• Multiple confusing TXT records.

The HTTPS policy file

The policy file lives at:

https://mta-sts.example.com/.well-known/mta-sts.txt

Example:

version: STSv1
mode: testing
mx: mail.example.com
max_age: 86400

The file must be served over HTTPS from the mta-sts hostname. That means the domain needs working HTTPS for that host. Agencies should check that the file is reachable, has the expected content type behavior in practice, and contains policy lines that match the client's mail setup.

What mode testing, enforce, and none mean

MTA-STS policy mode matters.

| Mode | Meaning | Practical agency use | |---|---|---| | testing | Senders can report policy failures but should not enforce hard failure based on the policy | Initial rollout and validation | | enforce | Supporting senders should require the policy when delivering | Mature setup after MX and TLS are verified | | none | Disables the policy | Rollback or intentional disablement |

Agencies should be cautious about recommending enforce without checking MX hostnames and TLS behavior. A bad enforce policy can create delivery problems from senders that honor MTA-STS.

Why MX hostnames matter

The policy file lists mx: patterns. Those patterns need to match the domain's actual MX hosts.

Example:

mx: aspmx.l.google.com
mx: *.google.com

If the policy lists an old mail provider but DNS now points to Microsoft 365, the policy can be wrong. If the policy is too narrow, legitimate MX hosts may not match. If it is too broad, it may not reflect the intended security posture.

During an audit, compare:

• Current MX records.
• MTA-STS policy mx: entries.
• Mail provider documentation.
• Recent migration history.
• Whether subdomains have separate mail flows.

This is closely related to operational DNS hygiene. See monitor DNS changes across client websites when the issue is broader than email authentication.

Relationship between MTA-STS and TLS-RPT

TLS-RPT is reporting. MTA-STS is policy. They work well together because TLS-RPT can send reports about TLS delivery failures, including failures related to MTA-STS policy.

MTA-STS without TLS-RPT can enforce expectations but give less visibility. TLS-RPT without MTA-STS can still provide useful reporting signals in some contexts, but it is commonly discussed alongside MTA-STS because reports help teams see transport-security problems.

For a deeper guide, read TLS-RPT record explained.

Common MTA-STS configuration mistakes

| Mistake | Why it matters | |---|---| | DNS marker missing | Senders may not discover the policy | | Policy file not reachable | Discovery leads to a broken endpoint | | HTTP works but HTTPS fails | Policy must be available over HTTPS | | MX entries do not match | Legitimate delivery can be affected | | Old provider remains in policy | Common after migrations | | Enforce used too early | Can increase delivery risk | | No TLS-RPT owner | Reports may go nowhere useful |

These mistakes are often process issues. Nobody owns the policy after the initial setup.

Agency MTA-STS record check workflow

Use this checklist:

1. Query _mta-sts.clientdomain.com for TXT.
2. Confirm v=STSv1.
3. Note the id value.
4. Fetch the HTTPS policy file.
5. Confirm version: STSv1.
6. Confirm mode.
7. Compare mx: entries to current MX records.
8. Confirm max_age is intentional.
9. Check TLS-RPT record and reporting address.
10. Document owner, mail provider, DNS host, and next action.

Use Inbox Pulse to make this repeatable across multiple client domains. It is an audit layer, not a replacement for mail-provider admin review.

When agencies should recommend MTA-STS

MTA-STS is most relevant when a client has meaningful email reliance, manages sensitive business communication, or wants stronger transport-security posture. It is also relevant for clients with mature DNS and email operations where someone can own monitoring and policy updates.

Not every small business needs an immediate MTA-STS rollout. If the client does not have SPF, DKIM, DMARC, and sender inventory under control, those may be higher-priority operational fixes. MTA-STS is valuable, but it should not be a checkbox nobody maintains.

Rollout notes for agency teams

When implementing MTA-STS, separate audit, rollout, and ownership:

| Stage | Agency action | Risk to watch | |---|---|---| | Audit | Check MX records, DNS marker, policy file, and TLS-RPT | Existing stale policy from old provider | | Testing | Use mode: testing while validating reports | Reports sent to an unmonitored mailbox | | Review | Compare reported failures with MX and certificate setup | False confidence because nobody reads reports | | Enforce | Move to mode: enforce only when stable | Delivery issues from mismatched MX policy | | Maintain | Update policy after mail-provider changes | Old policy left after migration |

This matters after migrations. A client may move from one mail provider to another, update MX records, and forget that the MTA-STS policy still lists old hosts. The policy is not self-healing.

What to include in an audit finding

An MTA-STS finding should be specific:

• DNS marker status.
• Policy file status.
• Current mode.
• Current MX records.
• Policy mx: values.
• TLS-RPT status and reporting owner.
• Recommended action.

Avoid vague findings like "MTA-STS missing" without priority. For many clients, missing MTA-STS is a maturity gap, not an emergency. A broken enforce policy, however, deserves faster review.

Example finding language

Use wording like:

MTA-STS is partially configured. The DNS marker exists, but the HTTPS policy file lists MX hosts from a previous mail provider. We recommend switching the policy back to testing, updating the MX patterns, confirming TLS-RPT reports are monitored, and only returning to enforce after validation.

That gives the client a path. It does not overclaim that MTA-STS improves inbox placement or replaces authentication work.

Testing a policy file manually

For a manual review, open or fetch:

https://mta-sts.example.com/.well-known/mta-sts.txt

Then check:

• The host responds over HTTPS.
• The certificate is valid for mta-sts.example.com.
• The file is not behind authentication.
• The content includes version: STSv1.
• The content includes mode.
• At least one mx: line is present when expected.
• max_age is present.

The policy file should be treated as operational infrastructure. If a web migration breaks the mta-sts hostname, the mail-security policy can break even though MX records did not change. Agencies that manage websites but not email should still be aware of this dependency.

Web hosting and certificate considerations

MTA-STS creates a small but real web-hosting requirement. The mta-sts hostname must serve the policy over HTTPS. That can be handled through the client's main web stack, a static host, a CDN, or a mail/security provider, but someone needs to own it.

Common agency scenarios:

| Scenario | Risk | |---|---| | Agency migrates website hosting | mta-sts hostname or certificate may be lost | | Client changes DNS provider | _mta-sts TXT record may not be copied | | Mail provider changes | Policy mx: entries may become stale | | CDN rules change | Policy file may redirect or return HTML | | Certificate expires | Policy fetch can fail |

This is why MTA-STS belongs in client asset and DNS-change checklists. It crosses the boundary between email, DNS, and web hosting.

Prioritizing MTA-STS findings

Not every MTA-STS issue has the same priority.

| Finding | Priority guidance | |---|---| | Enforce policy with wrong MX hosts | High; review quickly | | Policy file unreachable with enforce mode | High; potential delivery risk | | Missing MTA-STS on low-maturity domain | Low to medium; roadmap item | | Testing mode with reports monitored | Normal; continue validation | | TLS-RPT missing during rollout | Medium; visibility gap |

This prioritization helps agencies avoid alarm fatigue. Missing MTA-STS is not the same as broken enforce mode.

Related resources

• TLS-RPT record explained
• Bulk DMARC check for client domains
• DMARC, SPF, and DKIM explained for agencies
• DMARC policy none, quarantine, and reject guide

Frequently Asked Questions

What is an MTA-STS record check?

An MTA-STS record check reviews the DNS TXT marker at _mta-sts.domain, the HTTPS policy file at https://mta-sts.domain/.well-known/mta-sts.txt, the policy mode, MX host patterns, and related TLS-RPT visibility. For agencies, the goal is to find missing, stale, or risky transport-security configuration before recommending enforcement.

What is an MTA-STS checker?

An MTA-STS checker is a workflow or tool that looks for the public _mta-sts DNS record, fetches the HTTPS policy file, reads the mode, checks MX entries, reviews max_age, and notes whether TLS-RPT exists. It is a public configuration check, not continuous mail-flow monitoring or a guarantee that every sender will handle policy the same way.

What is an MTA-STS record?

The MTA-STS DNS record is a TXT record at _mta-sts.example.com, usually with a value such as v=STSv1; id=2026051001. It tells supporting senders that the domain publishes an MTA-STS policy and gives them an ID to notice policy changes. The DNS record works together with the HTTPS policy file.

Does MTA-STS guarantee email deliverability?

No. MTA-STS does not guarantee deliverability or inbox placement. It publishes transport-security expectations for supporting senders delivering mail to the domain. Deliverability still depends on many other factors, including sender reputation, authentication, content, recipient behavior, and mailbox-provider decisions. Treat MTA-STS as a transport-security control, not a deliverability promise.

Does MTA-STS encrypt all email?

No. MTA-STS publishes a policy for SMTP delivery to the receiving domain, and supporting senders can use that policy when delivering mail. It does not control every message path on the internet, replace SPF/DKIM/DMARC, or guarantee delivery outcomes. Agencies should describe it as a transport-policy signal that needs correct MX, TLS, and policy setup.

What is the difference between testing and enforce?

testing lets a domain publish an MTA-STS policy without asking supporting senders to hard-enforce delivery failure based on that policy. enforce tells supporting senders to require the policy. Agencies should usually validate MX matching, TLS behavior, and reporting before recommending enforce. Testing is useful during rollout and after migrations.

Why does the MTA-STS policy file need HTTPS?

The policy file is fetched from an HTTPS URL so senders can retrieve the policy securely. The expected location is https://mta-sts.domain/.well-known/mta-sts.txt. If the host has no valid HTTPS setup, redirects incorrectly, or serves the wrong content, the policy can be incomplete or unreliable. Agencies should check both DNS and HTTPS reachability.

How does MTA-STS relate to TLS-RPT?

MTA-STS publishes policy. TLS-RPT reports transport-security failures. Together, they help a domain express expectations and receive visibility into problems. TLS-RPT does not enforce anything, and MTA-STS does not provide report aggregation by itself. Agencies should identify who receives and reviews TLS-RPT reports before considering the setup complete.

Can Inbox Pulse monitor MTA-STS continuously?

No. Inbox Pulse is a public DNS and email-authentication configuration auditor. It can help agencies check whether MTA-STS-related public signals appear present, but it does not continuously monitor MTA-STS reports, read mailboxes, send test messages, or replace a mail-provider rollout review.

Should every small business use MTA-STS?

Not always as the first priority. Many small businesses should first fix SPF, DKIM, DMARC, sender inventory, and basic DNS ownership. MTA-STS is useful when email is business-critical and someone can maintain the policy. Agencies should recommend it when the client has enough operational maturity to keep MX records, policy files, and reporting aligned.