Security Protocol Diagnostic

MTA-STS Check

Audit your Mail Transfer Agent Strict Transport Security. We verify DNS records and policy availability to ensure encrypted SMTP communication.

Live check —

Mode —

Max age —

Auditing major mail providers in real-time…

Example MTA-STS records

MTA-STS is published in two places: a TXT record at _mta-sts that signals support, and a policy file served over HTTPS at mta-sts.{domain}/.well-known/mta-sts.txt. The checker validates both.

TXT signal record at _mta-sts

_mta-sts.example.com  TXT  v=STSv1; id=20260607T093000

The id= rotates whenever the policy file changes. Receivers cache the policy keyed on id; bumping it forces a re-fetch.

Policy file at mta-sts.example.com/.well-known/mta-sts.txt

https://mta-sts.example.com/.well-known/mta-sts.txt  TXT  version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

Plain-text policy. mode is one of enforce / testing / none. max_age is in seconds (one week = 604800). Every MX host must be listed explicitly.

Wildcard MX in policy file

https://mta-sts.example.com/.well-known/mta-sts.txt  TXT  version: STSv1
mode: enforce
mx: *.example-mail.com
max_age: 604800

Wildcard MX entries work for SaaS mail hosts that rotate hostnames within a known suffix. Use sparingly; wildcards weaken the authentication signal.

MTA-STS DNS and policy-file fields, explained

v Version (DNS TXT) Required: Always STSv1. First tag in the _mta-sts TXT record. v=STSv1
id Policy ID (DNS TXT) Required: Opaque string. Change it whenever the HTTPS policy file changes — receivers cache the policy keyed on the id. id=20260607T093000
version Version (policy file) Required: Always STSv1. First line of the HTTPS policy file. version: STSv1
mode Mode (policy file) Required: enforce / testing / none. enforce = senders must use TLS; testing = log failures but deliver anyway; none = effectively disables MTA-STS. mode: enforce
mx MX host (policy file) Required: Authorized MX host for receiving mail. Repeat for each MX. Wildcards work but reduce signal strength. mx: mx1.example.com
max_age TTL (policy file) Required: How long receivers cache the policy, in seconds. RFC 8461 minimum is 86400 (one day); production typically 604800 (one week). max_age: 604800

Common MTA-STS mistakes and how to fix them

Five structural failure modes the checker catches. MTA-STS is unforgiving — get the policy file wrong and senders silently deliver in plaintext.

Issue	What it means	How to fix it
Missing TXT signal record	The HTTPS policy file may be perfect, but receivers never look at it without the _mta-sts TXT record signaling its existence.	Publish a TXT record at _mta-sts.{domain} with v=STSv1 and an id= value.
Policy file unreachable	The TXT record points at the policy, but the HTTPS URL returns non-200 or times out.	Confirm the policy is served at mta-sts.{domain}/.well-known/mta-sts.txt with a 200 response, valid TLS, and the correct Content-Type.
Invalid HTTPS certificate on mta-sts subdomain	The certificate at mta-sts.{domain} does not match the domain or is expired.	Issue a valid certificate covering mta-sts.{domain}. Let's Encrypt works; self-signed does not.
MX hosts in policy do not match real MX records	The policy lists MX hosts that are not in the actual {domain} MX record, or vice versa.	Bring the policy file MX list in line with the real MX records. Forgotten MX hosts cause silent delivery failures.
mode left at testing in production	mode: testing tells senders to log TLS failures but deliver in plaintext anyway. It is a staging-only setting.	Change to mode: enforce once you have confirmed receivers can fetch the policy and accept TLS.

Missing TXT signal record

What it means: The HTTPS policy file may be perfect, but receivers never look at it without the _mta-sts TXT record signaling its existence.
How to fix it: Publish a TXT record at _mta-sts.{domain} with v=STSv1 and an id= value.

Policy file unreachable

What it means: The TXT record points at the policy, but the HTTPS URL returns non-200 or times out.
How to fix it: Confirm the policy is served at mta-sts.{domain}/.well-known/mta-sts.txt with a 200 response, valid TLS, and the correct Content-Type.

Invalid HTTPS certificate on mta-sts subdomain

What it means: The certificate at mta-sts.{domain} does not match the domain or is expired.
How to fix it: Issue a valid certificate covering mta-sts.{domain}. Let's Encrypt works; self-signed does not.

MX hosts in policy do not match real MX records

What it means: The policy lists MX hosts that are not in the actual {domain} MX record, or vice versa.
How to fix it: Bring the policy file MX list in line with the real MX records. Forgotten MX hosts cause silent delivery failures.

mode left at testing in production

What it means: mode: testing tells senders to log TLS failures but deliver in plaintext anyway. It is a staging-only setting.
How to fix it: Change to mode: enforce once you have confirmed receivers can fetch the policy and accept TLS.

For MSPs

How MSPs use this checker for client email-transport security

MTA-STS is the unglamorous transport-encryption story most clients have never heard of. For mid-market clients with regulatory exposure (PCI, HIPAA, EU NIS2), it is increasingly the difference between a clean audit and a finding.

The checker above is the right tool for client onboarding and quarterly audits. Run it on the apex domain and any mail-receiving subdomains; the output tells you whether the TXT signal is present, whether the policy file is reachable, whether the certificate is valid, and whether the MX list in the policy actually matches DNS.

The most common failure we see at audit time is mode: testing left in production. The client deployed MTA-STS in staging, set mode: testing to monitor TLS failures, and never bumped to enforce. Senders log failures but deliver in plaintext anyway — which is exactly what the auditor flags.

For MSPs running a portfolio, the MTA-STS posture across all client domains is the kind of cross-tenant view that justifies the platform spend. One tool, all clients, daily.

See how DMARC AI works for MSPs

From manual to managed

From one-off check to continuous MTA-STS monitoring

MTA-STS records expire, certificates expire, MX lists drift, and policies revert to testing mode after a panic during a delivery incident. A one-off check tells you whether the posture is right today; continuous monitoring tells you the moment it breaks.

DMARC AI watches every client MTA-STS record across the portfolio — TXT signal, policy reachability, certificate validity, MX consistency, mode — and surfaces drifts within minutes. The same tool you run during onboarding becomes the daily watchtower.

Start a free trial

Continuous validation of the _mta-sts TXT signal
Policy-file reachability + TLS-certificate expiry tracking
MX-list consistency check vs the live DNS MX record
Alerts when mode drops below enforce
Multi-tenant view across the full client portfolio

Related tools

MTA-STS sits alongside the rest of your email-authentication stack.

verified_user

DMARC Checker

Verify your DMARC record, policy, alignment, and aggregate-report destinations.

Open tool verified

SPF Analyzer

Parse your SPF record, count DNS lookups against the 10-lookup limit, find void lookups.

Open tool key

DKIM Validator

Fetch a DKIM public key by selector and domain, verify record structure and key length.

Open tool palette

BIMI Generator

Build a valid BIMI DNS record (requires DMARC enforcement + DKIM alignment).

Open tool

Continue learning

Deeper Academy reading on MTA-STS and the adjacent transport-security protocols.

DMARC explained — Complete guide

MTA-STS protects transport encryption; DMARC protects identity. The two together cover most modern phishing patterns.

8 min read

SPF (Sender Policy Framework) — Complete guide

Every mechanism and qualifier, the 10-lookup limit, void lookups.

7 min read

DKIM — Complete guide

Selectors, key rotation, signature anatomy. The third leg of the authentication tripod.

6 min read

BIMI — Display your verified brand logo

The branded-inbox reward for completing the DMARC enforcement work.

5 min read

Free check is good — running a portfolio is better

Two ways to go from a one-off check to a managed practice.

Self-serve No credit card

Start a free 30-day Premium trial

Sign up, add a domain, see real DMARC reports inside 48 hours. No credit card. Premium AI features included for the trial; drop back to free Basic monitoring afterwards or convert per-active-domain.

Start a free 30-day Premium trial arrow_forward

Guided 30 minutes with an engineer

Book demo

Walk through the multi-tenant dashboard with a real engineer. Bring a client domain — we will load it live and show what the reports look like for your portfolio.

Book demo north_east

MTA-STS FAQ for Professionals

What is MTA-STS? expand_more

Mail Transfer Agent Strict Transport Security — a DNS + HTTPS mechanism that lets a receiving domain tell senders "you must use TLS to deliver mail to me." Without MTA-STS, opportunistic TLS will silently fall back to plaintext under various failure modes.

What is the difference between MTA-STS and TLS-RPT? expand_more

MTA-STS is the enforcement mechanism: it tells senders to use TLS. TLS-RPT is the reporting mechanism: it asks senders to send reports about TLS connection failures. The two complement each other — you can deploy either or both, but most production deployments use both.

Why is my MTA-STS policy not being honoured? expand_more

Three common reasons: (1) the _mta-sts TXT signal is missing or has a stale id= value, (2) the HTTPS policy file is unreachable or has an invalid certificate, (3) the policy file is still in mode: testing. The checker above catches all three.

What max_age should I use? expand_more

RFC 8461 minimum is 86400 (one day). Production deployments typically use 604800 (one week) or 2592000 (30 days). Longer max_age means receivers cache the policy longer — useful for stability but slower to react to policy changes.

Can I deploy MTA-STS without a TXT record? expand_more

No. The HTTPS policy file alone is invisible without the _mta-sts TXT signal. Receivers look up the TXT first; if it is missing they do not fetch the policy.

Do I need a separate certificate for mta-sts.example.com? expand_more

You need a valid TLS certificate that covers mta-sts.{domain}. The cheapest path is a Let's Encrypt cert covering both the apex and the mta-sts subdomain. Self-signed certificates do not work — receivers reject the policy fetch.