Limited time: 50% OFF on your first payment.
InboxWarm.ai Logo

Check Your MTA-STS Record

Verify your MTA-STS DNS record for free and confirm your domain signals TLS-encrypted mail delivery. Catch a missing or malformed policy before senders fall back to plaintext.

Enter a Domain

You have 5 more free checks today.

What is MTA-STS?

MTA-STS (Mail Transfer Agent Strict Transport Security) lets a domain declare that incoming SMTP connections must use TLS with a valid certificate. It combines a DNS TXT record at _mta-sts.yourdomain.com with a policy file served over HTTPS at mta-sts.yourdomain.com/.well-known/mta-sts.txt. The DNS record advertises that a policy exists and carries an id that changes whenever the policy updates.

Without MTA-STS, SMTP’s opportunistic TLS can be silently stripped by an attacker on the path, forcing mail to be delivered in plaintext. MTA-STS closes that gap by instructing sending servers to refuse delivery if TLS cannot be negotiated. It pairs naturally with TLS-RPT, which emails you reports when a sender cannot honour the policy. The standard is defined in RFC 8461.

Why check your MTA-STS record?

1Confirm the policy is discoverable

If the DNS record is missing or malformed, senders never look for your policy file — verify it resolves

2Catch an id that never changes

The id must update on every policy change or caches serve a stale policy — a checker surfaces the current value

3Prevent silent TLS downgrades

A working record signals senders to require encryption, protecting mail in transit from interception

4Validate before enforce mode

Confirm the record and policy align while in testing mode so switching to enforce does not bounce legitimate mail

How MTA-STS works — step by step

1

You host a policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt describing the mode, MX hosts, and max_age.

2

You publish a TXT record at _mta-sts.yourdomain.com containing the version and a unique id.

3

A sending server about to deliver mail queries that TXT record and sees a policy is advertised.

4

It fetches the HTTPS policy file, validates the receiving MX and its TLS certificate against it.

5

If the policy is in enforce mode and TLS cannot be validated, the sender refuses to deliver rather than falling back to plaintext.

MTA-STS record syntax

DNS TXT record and policy file example
_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=20240118T120000Z"

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

DNS tag breakdown

v=STSv1— protocol version, always first
id=— unique token, changes on every policy update

Policy file fields

mode
enforce, testing, or none — enforce refuses delivery when TLS fails, testing only reports.
mx
The mail server hostnames the policy applies to; wildcards like *.example.com are allowed.
max_age
How long (in seconds) senders may cache the policy — commonly one to four weeks.
version
Always STSv1; identifies the policy format in the served file.

Common MTA-STS failures and fixes

Policy file unreachable

The .well-known file must load over HTTPS with a valid certificate — fix the host before senders can apply it

Stale id

Forgetting to bump id after editing the policy makes senders keep the old one — change it on every update

MX mismatch

If the mx entries do not match your real MX records, enforce mode blocks legitimate mail — keep them in sync

Jumping straight to enforce

Start in testing with TLS-RPT so you catch problems before enforce mode can bounce messages

FAQs

Frequently Asked Questions

MTA-STS (Mail Transfer Agent Strict Transport Security) lets your domain tell sending servers that mail must be delivered over TLS with a valid certificate. It combines a DNS TXT record at _mta-sts.yourdomain.com with an HTTPS-hosted policy file. Without it, SMTP’s opportunistic encryption can be stripped by an attacker on the network path, forcing your mail to travel in plaintext.

The TXT record at _mta-sts.yourdomain.com holds two things: the version (v=STSv1) and an id — a unique token you must change every time you update the policy file. The record does not contain the policy itself; it simply advertises that a policy exists and signals, via a changed id, when senders should re-fetch it.

The mode is set in the HTTPS policy file, not the DNS record. In testing mode, senders report TLS failures (via TLS-RPT) but still deliver mail, letting you find problems safely. In enforce mode, senders refuse to deliver if TLS cannot be validated. Best practice is to run in testing with reporting enabled first, then switch to enforce once you confirm everything works.

Both require TLS for inbound mail, but they anchor trust differently. DANE uses DNSSEC and TLSA records to pin certificates, so it depends on DNSSEC being deployed. MTA-STS uses the public web PKI and an HTTPS-hosted policy, so it works without DNSSEC. Many domains adopt MTA-STS first because it is simpler to deploy on existing infrastructure.

Common reasons are a missing or malformed TXT record, an id that was not updated after a policy change, or a policy file that does not load over HTTPS with a valid certificate. This checker verifies the DNS record; also confirm the file at /.well-known/mta-sts.txt is reachable and that its mx entries match your real MX records.