An MTA STS record checker answers a simple but high-stakes question: when another company sends sensitive email to your domain, are their mail servers required to use an encrypted, trusted connection? For a law office, medical practice, real estate team, or service business, that can affect invoices, client records, appointment details, and everyday trust.
MTA-STS is not a marketing badge or a vague security setting. It is a published policy that tells compatible sending mail servers how to securely deliver email to your domain. A checker gives you the straight answer: Is the policy published, readable, correctly matched to your mail servers, and ready to enforce?
What an MTA-STS record actually does
Mail transfer agents, or MTAs, are the servers that move email between organizations. Many can use TLS encryption during delivery, but opportunistic TLS has a weakness: if a sender cannot negotiate encryption, it may fall back to an unencrypted connection rather than stop delivery.
MTA-STS changes that behavior for senders that support the standard. Your domain publishes a policy stating which mail servers are authorized to receive its email and whether TLS must be used. When the policy is in enforcement mode, a participating sender should not deliver mail if it cannot establish a valid encrypted connection to one of those approved servers.
That matters when messages contain information you would not want exposed in transit. It also helps protect against certain downgrade and man-in-the-middle attacks that can redirect or weaken email delivery.
There is an important limit: MTA-STS does not encrypt messages stored in a mailbox, prevent phishing, fix spam placement, or force every sender on the internet to comply. It improves transport security between mail systems that support it. That is still a meaningful layer of protection, but it works best alongside SPF, DKIM, DMARC, secure mailbox access, and sensible staff training.
What an MTA STS record checker should test
A useful checker does more than confirm that a DNS record exists. A record can be present and still fail when a sending server tries to use it. The check should look at the full chain.
First, it verifies the DNS TXT record at `_mta-sts.yourdomain.com`. That record identifies the policy version and includes an ID value. The ID tells sending servers when they should retrieve a newer policy after you make a change.
Next, it checks whether the policy file is available at the required HTTPS location on your domain. The file must be publicly reachable over HTTPS and served with a valid certificate. A correct DNS record cannot compensate for a missing policy file, a certificate warning, or a web server that blocks the request.
Then the checker reads the policy syntax. A valid policy identifies the allowed MX hostnames, sets a mode, and provides a cache duration. Small formatting mistakes can cause the policy to be ignored. Common trouble spots include a missing `version` line, a malformed MX pattern, an invalid mode, or an incomplete `max_age` value.
Finally, the best checks compare the policy to your actual MX records and email server TLS configuration. If your domain receives email through Microsoft 365, Google Workspace, a hosted email provider, or a hybrid setup, the names in the MTA-STS policy must match the mail servers published in DNS. Those servers must also present valid TLS certificates during SMTP connections.
How to check your MTA-STS setup
Start with your primary email domain, not just the domain on your website. If employees send and receive email as `name@company.com`, check `company.com`. If different divisions use separate sending domains, assess each one individually.
Run an MTA STS record checker and review the result in this order:
1. Confirm the DNS record is found
The checker should find a TXT record under the `_mta-sts` subdomain. If it cannot, MTA-STS is not published for that domain. The fix is to create the required TXT record in the DNS provider that hosts your domain's records.
Do not confuse this with your SPF or DMARC record. Those are also TXT records, but each belongs at a different hostname and serves a different purpose.
2. Confirm the HTTPS policy can be retrieved
Your policy must be available at a specific address beneath your primary domain. If this test fails, check whether the required path exists, whether your website platform allows the needed `.well-known` directory, and whether HTTPS has a current public certificate.
This step catches a frequent real-world problem: the DNS record was added by IT, but the web-hosting side was never configured. Both parts are required.
3. Compare the policy to your MX records
Look closely at the MX names your domain currently uses. The policy's `mx` entries must authorize those names. If you changed email providers, added a backup mail route, or moved from an on-premises server to cloud email, an old policy can block legitimate delivery attempts from compliant senders.
Wildcard matching can be useful when your provider uses several hosts under one approved domain. It should be used carefully. A broad wildcard may simplify administration, but an overly loose policy reduces the control MTA-STS is designed to provide.
4. Check the mode before enforcing it
MTA-STS policies can use `testing` or `enforce` mode. Testing lets supporting senders evaluate the policy without treating failures as a hard delivery block. Enforce mode tells them not to deliver when the TLS connection or MX match fails.
Testing is the sensible starting point when you are deploying MTA-STS for the first time or changing mail providers. Move to enforcement only after the policy, MX records, and server certificates have been verified. Security settings should be strict, but not guessed at.
Common MTA-STS failures and the exact fix
The policy ID was never updated. The `id` value in the DNS record should change whenever you change the policy file. Without a new ID, sending servers may continue using a cached older policy. Update the ID with each policy revision, then allow for DNS propagation and caching.
The policy names the wrong mail host. This often follows an email migration. Review your live MX records, replace outdated hostnames in the policy, and test again before setting enforcement mode.
The HTTPS certificate is invalid or expired. The policy endpoint needs a publicly trusted certificate that matches the domain used to host the policy. Renew or correctly install the certificate, then make sure the endpoint can be reached without redirects or access restrictions that interfere with retrieval.
The policy file has a syntax error. MTA-STS is intentionally strict. Check required fields, spelling, line formatting, and allowed values. A checker should point to the field that failed so you can correct the exact issue instead of rebuilding the entire setup.
Your mail server does not support suitable TLS. Even a perfect policy will not help if your receiving SMTP service cannot negotiate modern TLS with a valid certificate. This typically requires action from your email provider or IT team, especially in hybrid and self-hosted environments.
Pair MTA-STS with TLS reporting
MTA-STS tells participating senders what should happen. TLS-RPT tells you when secure delivery attempts encounter a problem. A TLS reporting record allows external mail systems to send reports about TLS failures involving your domain.
The two controls work well together. MTA-STS establishes the rule; TLS-RPT gives you visibility when that rule cannot be followed. For a business that depends on incoming email, reporting can reveal certificate failures, configuration drift, or mail-routing changes before they become a larger delivery problem.
A domain health check from MailArrive can help place this result alongside SPF, DKIM, DMARC, MX, SMTP, and reputation checks. That context matters because email failures rarely stay in one neat category. An outdated MX record, an expired certificate, and an incomplete MTA-STS policy can all point to the same underlying issue: a mail system that changed without a full review.
When enforcement makes business sense
MTA-STS enforcement is especially worth considering when your organization routinely receives confidential client information, payment discussions, contracts, patient communications, account notices, or operational instructions. It is also a practical choice when you use a major hosted email platform with stable MX infrastructure and have confirmed the policy is accurate.
If your environment changes often, has multiple mail gateways, or includes older systems, take more time in testing mode. The trade-off is clear: enforcement provides stronger protection, but a wrong policy can cause compatible sending servers to defer or fail delivery. A careful check before enforcement protects both security and continuity.
Treat your MTA-STS policy like any other operational email record. Review it after a provider migration, DNS change, certificate renewal, or new mail security gateway. The best time to find a mismatch is before a client sends a message your business cannot afford to miss.