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

Jordan discovers the MTA-STS problem the usual way: not during a planned email-security project, but during a mail migration handoff. MX records were changed, the client’s website still worked, staff mail still seemed fine, and the old agency note said “email security configured.” Then someone asks whether the domain has an MTA-STS policy, who owns it, and whether the policy still matches the new mail provider.

That is when the spreadsheet falls apart. The DNS marker exists, but nobody knows when the policy file changed. The policy file lists old MX hosts. TLS-RPT points to a mailbox from the previous provider. The domain looks “secure enough” in a simple check, but the evidence is not good enough for a confident recommendation.

An MTA-STS record check is the practical review that fixes that gap. It reviews whether _mta-sts.example.com exists, whether https://mta-sts.example.com/.well-known/mta-sts.txt returns a usable policy, whether the policy matches current MX records, whether the mode is appropriate, and who owns the follow-up.

MTA-STS helps receiving domains publish transport-security expectations for inbound email. It does not guarantee deliverability. It does not replace SPF, DKIM, DMARC, mailbox-provider review, or real ownership of the mail stack.

Use Inbox Pulse for bulk public 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.

Use this structured view:

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

Use this structured view:

• Piece: DNS TXT marker; Location: _mta-sts.example.com; Purpose: Tells senders an MTA-STS policy exists and provides an ID.
• Piece: HTTPS policy file; Location: https://mta-sts.example.com/.well-known/mta-sts.txt; Purpose: 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.

Use this structured view:

• Mode: testing; Meaning: Senders can report policy failures but should not enforce hard failure based on the policy; Practical agency use: Initial rollout and validation.
• Mode: enforce; Meaning: Supporting senders should require the policy when delivering; Practical agency use: Mature setup after MX and TLS are verified.
• Mode: none; Meaning: Disables the policy; Practical agency use: 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

Use this structured view:

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

Use this structured view:

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

Use this structured view:

• Scenario: Agency migrates website hosting; Risk: mta-sts hostname or certificate may be lost.
• Scenario: Client changes DNS provider; Risk: _mta-sts TXT record may not be copied.
• Scenario: Mail provider changes; Risk: Policy mx: entries may become stale.
• Scenario: CDN rules change; Risk: Policy file may redirect or return HTML.
• Scenario: Certificate expires; Risk: 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.

Use this structured view:

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

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

Build the MTA-STS evidence packet

A useful MTA-STS review should produce more than a pass/fail label. Jordan needs a packet another person can reopen later without repeating discovery from scratch.

Capture these fields for each domain:

• Domain: the domain being reviewed, not only the client name.
• Current MX records: the mail hosts currently published in DNS.
• DNS marker: whether _mta-sts exists, plus the current id value.
• Policy URL: whether the HTTPS policy file is reachable at the expected path.
• Policy mode: none, testing, or enforce, with a note on why that mode is acceptable.
• Policy MX patterns: the mx: lines in the policy file.
• Match result: whether the policy appears to match the current MX records.
• TLS-RPT owner: who receives and reviews transport-security reports.
• Last reviewed: the date the evidence was checked.
• Recommended action: monitor, fix policy, revert to testing, assign owner, or escalate.

This turns a technical DNS check into an operating record. It also makes the difference between “MTA-STS exists” and “we know whether the MTA-STS setup still matches this client’s mail infrastructure.”

Review MTA-STS after mail and DNS changes

Most MTA-STS problems are created by otherwise normal operations. A client moves from Google Workspace to Microsoft 365. A DNS zone is rebuilt at a new provider. A website migration changes how the mta-sts hostname is served. A CDN rule starts returning HTML instead of the plain policy file. None of those changes have to be malicious to create transport-security drift.

Add MTA-STS to the same review routine you use for MX, SPF, DKIM, DMARC, and verification TXT records:

• Before a mail-provider migration, snapshot the current _mta-sts TXT value and policy file.
• After the migration, compare the policy mx: entries against the new MX records.
• If the policy is in enforce, treat mismatched MX hosts as a high-priority review item.
• Confirm the TLS-RPT destination is still monitored by the responsible team.
• Update the policy id when the policy meaningfully changes.
• Store the final decision in the client’s evidence record.

The important habit is not daily hand-editing. It is making MTA-STS part of the change checklist whenever the mail path or DNS authority changes.

Evidence is not mail-flow control

An MTA-STS record check can show public configuration. It cannot prove every sender behaved correctly, read private mailbox-provider settings, review message queues, or guarantee inbox placement. Treat the result as evidence for review, not as a claim that email transport is permanently solved.

Client-safe wording is straightforward:

• “MTA-STS is present and the policy appears to match current MX records.”
• “MTA-STS is in enforce mode, but the policy should be reviewed because MX records recently changed.”
• “The policy file is not reachable at the expected HTTPS path; technical review is recommended before enforcement.”
• “TLS-RPT is present, but the reporting owner is not documented.”

This language is specific enough to be useful and careful enough not to imply guarantees.

How CertPilot helps

CertPilot’s public email and domain checks help teams see whether MTA-STS, TLS-RPT, MX, SPF, DKIM, DMARC, SSL, DNS, and domain-expiry signals are present across monitored domains. In the app, those public signals can sit beside customer-maintained domain governance, SSL readiness, and sending-source notes so the review has context.

CertPilot does not read mailboxes, aggregate TLS-RPT report files, send test email, change DNS, configure MTA-STS, or guarantee deliverability. It gives operators a clearer evidence layer they can use during audits, client reviews, migrations, and management reporting.

For broader reporting, connect this review to a monthly client domain health report or a management-ready evidence report.

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.