# MTA-STS Checker

URL: https://iblockspam.com/tools/mta-sts-checker
Last updated: 2026-10-09

> Test your MTA-STS setup end to end: the DNS record, the HTTPS policy file, its mode and MX patterns, and TLS reporting.

Free tool: Fetch and validate your MTA-STS policy, match it to your MX hosts and check TLS-RPT. Use it at https://iblockspam.com/tools/mta-sts-checker

## What the MTA-STS Checker looks at

[MTA-STS](https://www.rfc-editor.org/rfc/rfc8461.html) has two parts: a TXT record that announces a policy, and a policy file served over HTTPS. This tool checks both, in the same way a sending server would:

1. **The TXT record** at `_mta-sts.yourdomain`. There must be exactly one record starting `v=STSv1`, with an `id` of 1 to 32 letters or digits ([RFC 8461 section 3.1](https://www.rfc-editor.org/rfc/rfc8461.html#section-3.1)).
2. **The policy host.** `mta-sts.yourdomain` must resolve to a public address.
3. **The policy file** at `https://mta-sts.yourdomain/.well-known/mta-sts.txt`. It must load with HTTP 200, over a valid certificate for that host name, without redirects ([section 3.3](https://www.rfc-editor.org/rfc/rfc8461.html#section-3.3)), and should be served as `text/plain`.
4. **The policy fields**: `version: STSv1`, `mode` (enforce, testing or none), one `mx` line per mail host, and `max_age` in seconds, at most 31557600 ([section 3.2](https://www.rfc-editor.org/rfc/rfc8461.html#section-3.2)).
5. **Your MX hosts against the policy.** Each MX host must match an `mx` pattern. A wildcard such as `*.mail.example.net` matches exactly one extra label ([section 4.1](https://www.rfc-editor.org/rfc/rfc8461.html#section-4.1)).
6. **TLS-RPT**: a TXT record at `_smtp._tls.yourdomain` starting `v=TLSRPTv1` with a `rua` address ([RFC 8460](https://www.rfc-editor.org/rfc/rfc8460.html)).

## How to read the results

- **Pass.** That part of the setup is valid.
- **Warning.** It works, but protection is weaker than it could be: testing mode, a short `max_age`, a wrong media type, or no TLS-RPT.
- **Fail.** Senders will ignore your policy, or, in enforce mode, refuse to deliver to some of your MX hosts.
- **Not tested.** A lookup or the policy fetch timed out. We wait 5 seconds; real senders wait longer.

## A working example

```
_mta-sts.example.com.  TXT  "v=STSv1; id=20261009T000000"
_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"
```

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

```
version: STSv1
mode: testing
mx: mx1.example.com
mx: *.mail.example.net
max_age: 1209600
```

## Common problems and fixes

**Certificate errors.** The policy host needs its own valid certificate covering `mta-sts.yourdomain`. A certificate only for `www` or the bare domain isn't enough.

**Redirects.** Many web hosts redirect everything to `www` or to a page. Senders must not follow redirects, so they never see your policy. Serve the file directly.

**MX host not in the policy.** This usually happens after a provider change or adding a filtering service. In enforce mode, senders refuse to deliver to that host. Add the new host, publish the file, and change the `id` in the TXT record so senders fetch it again.

**Short max_age.** RFC 8461 expects a value of weeks or more, so a cached policy keeps protecting you if an attacker blocks the next fetch. Use a short value only while testing.

**Changing the policy without changing the id.** Senders cache the policy and only re-fetch when the `id` changes. Update the id every time you edit the file.

Read [MTA-STS and TLS-RPT explained](https://iblockspam.com/blog/mta-sts-tls-rpt-explained) for the full setup.

## Limitations

- We fetch the policy once, from our server, with a 5-second limit. A slow server may work for senders that wait longer.
- We compare your current MX records with the policy. We don't connect to your mail servers to test their own TLS certificates, which senders in enforce mode also check.
- MTA-STS only protects mail from senders that support it. Many large providers do; some smaller servers don't.

## Related

Run the full [Email Health Check](https://iblockspam.com/tools/email-health-check) to see MTA-STS alongside MX, SPF, DKIM and DMARC.

## Frequently asked questions

### What is MTA-STS?

MTA-STS (RFC 8461) lets a domain tell sending mail servers to always use encrypted, authenticated TLS when delivering to it. Without it, an attacker on the network path can strip encryption from SMTP and read or alter mail in transit.

### What's the difference between testing and enforce mode?

In testing mode, senders still deliver if TLS fails and send you a TLS-RPT report about the failure. In enforce mode, senders that support MTA-STS refuse to deliver over a bad or missing TLS connection. Start in testing, then switch to enforce.

### Why does my policy need to list every MX host?

Senders in enforce mode only deliver to MX hosts that match an mx line in your policy. If you change mail provider or add a filtering service, update the policy and the id in the TXT record before you change the MX records.

### Do I need TLS-RPT as well?

It's optional but strongly recommended. TLS-RPT (RFC 8460) asks senders to email you daily reports of TLS failures, which is the only way to know whether switching to enforce would block legitimate mail.

### Is it safe to let you fetch my policy file?

Yes. We request only https://mta-sts.yourdomain/.well-known/mta-sts.txt, the public URL every sender reads. We refuse private addresses, don't follow redirects, and stop after 5 seconds or 64 KB.

---

Source: iBlockSpam, https://iblockspam.com/tools/mta-sts-checker (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt