Should I use MTA-STS or DANE?

Both if you can. DANE requires DNSSEC and is stronger where deployed; MTA-STS works without it and is supported by the largest providers. They coexist without conflict.

What does testing mode do?

Senders evaluate the policy and report failures via TLS-RPT but still deliver. It is the safe way to validate your mx list before switching to enforce.

Why is my updated policy being ignored?

Senders cache by the policy id in the TXT record. Changing the policy file without changing the id means nothing refetches until max_age expires.

Not technically, but deploying enforcement without reporting means delivery failures are invisible to you and visible only to the senders who gave up.

TLS & Email🌐 YAS server-sideAPI availableadvanced

MTA-STS & TLS-RPT

Validates MTA-STS policy (mta-sts.<domain>) and TLS-RPT reporting (smtp-tls-reporting).

Processed by YAS · not stored

Ready to runInstant execution

All tools →

MTA-STS & TLS-RPT — SMTP transport security

Checks the mta-sts TXT record, fetches /.well-known/mta-sts.txt over HTTPS, and reads the _smtp._tls TLS-RPT record.

What does this tool do?

Validates MTA-STS policy (mta-sts.<domain>) and TLS-RPT reporting (smtp-tls-reporting).

Why would I use it?

You want to enforce TLS for inbound mail with MTA-STS.
You are setting up TLS-RPT to receive transport failure reports.
You are auditing email transport security.

Real-life example

Input

example.com

Output

MTA-STS: v=STSv1; mode=enforce; mx: mail.example.com · TLS-RPT: rua=mailto:tls@example.com

Both records are fetched and explained.

Input → Process → Output → Next

Input: Enter a domain.
Process: YAS queries mta-sts.<domain> and smtp-tls-reporting.<domain>.
Output: Policy and reporting details, or MISSING flags.
Next action: Publish policies and start receiving TLS reports.

Common mistakes

Using mode=enforce before testing with mode=testing.
Publishing a policy without matching MX records (mail fails).
Forgetting the HTTPS endpoint for the policy body.

What the result means

MTA-STS tells senders to require TLS; TLS-RPT collects failure reports.

Privacy & security

Your input is sent to YAS infrastructure because the tool requires server-side processing or public network queries. Input is not stored.

API

Endpoint

POST https://yas.sh/api/v1/tools/mta-sts-tlsrpt

Request Header

Content-Type: application/json

cURL

curl -X POST "https://yas.sh/api/v1/tools/mta-sts-tlsrpt" \
  -H "Content-Type: application/json" \
  -d '{"input":"example.com"}'

JavaScript

const res = await fetch("https://yas.sh/api/v1/tools/mta-sts-tlsrpt", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
  "input": "example.com"
}),
});
const data = await res.json();

Python

import requests

r = requests.post("https://yas.sh/api/v1/tools/mta-sts-tlsrpt", json={"input":"example.com"})
data = r.json()

Field	Type	Required	Description
input	string	Yes	Domain, e.g. example.com

Success response

{ "result": { "stsTxt": { "found": true, "id": "20260808", "valid": true }, "policy": { "found": true, "mode": "enforce", "maxAge": 86400, "mx": ["mx1.example.com"] }, "tlsrpt": { "found": true, "rua": ["tlsrpt@example.com"] }, "issues": [] } }

MTA-STS (mta-sts TXT + /.well-known/mta-sts.txt) and TLS-RPT (_smtp._tls TXT) validation.

Error responses

400 VALIDATION_ERROR — invalid input or unsupported option.
413 PAYLOAD_TOO_LARGE — input exceeds the 64 KB limit.
429 RATE_LIMIT_EXCEEDED — rate limit exceeded (60 req/min).

Limits

Maximum input: 64 KB per request.
Rate limit: 60 requests/min per IP address.
Authenticated accounts benefit from higher tier quotas.

How MTA-STS & TLS-RPT works

MTA-STS (RFC 8461) fixes SMTP's downgradable opportunistic TLS without requiring DNSSEC. A domain publishes a TXT record at _mta-sts.<domain> carrying a policy id, and serves a policy file over HTTPS at https://mta-sts.<domain>/.well-known/mta-sts.txt listing permitted MX hostnames, a mode (testing, enforce, none) and a max_age. Sending servers fetch and cache the policy, and in enforce mode refuse to deliver if TLS or the MX name does not match.

TLS-RPT (RFC 8460) is the feedback channel: a TXT record at _smtp._tls.<domain> names an address to receive daily JSON reports of TLS negotiation successes and failures from participating senders. Together they provide enforcement plus visibility — the policy file supplies the trust anchor through the web PKI rather than through DNSSEC, which is the practical difference from DANE.

When to use it: real-world scenarios

Preventing SMTP downgrade attacks

Without MTA-STS or DANE, an attacker who can strip the STARTTLS capability causes mail to be delivered in cleartext. Enforce mode makes that a delivery failure instead.

Deploying transport security without DNSSEC

Where signing the zone is not feasible, MTA-STS provides comparable protection using HTTPS as the trust anchor.

Getting visibility into delivery TLS failures

TLS-RPT reports show which senders failed to negotiate TLS and why — data otherwise invisible to a receiving domain.

Validating a policy before enforcing it

Testing mode reports failures without blocking delivery, which is how you discover the MX host missing from your policy list.

Pro tips

Start in testing mode and read TLS-RPT for several weeks. Enforcing a policy with an incomplete mx list blocks legitimate inbound mail.
Change the policy id in the TXT record whenever the policy file changes; senders cache by id and will not refetch otherwise.
The policy host needs its own valid certificate for mta-sts.<domain>. An expired certificate there silently disables the policy.
Every MX hostname must appear in the mx list, including backups added later — this is the most common enforcement outage.

Limitations and edge cases

What this tool deliberately does not do, and where it will disagree with other implementations.

Protects inbound mail only; it constrains how other servers deliver to you, not how you deliver to them.
Trust depends on the web PKI, so a CA mis-issuance for the policy host undermines it — DANE's DNSSEC anchor does not have this property.
Only senders that implement MTA-STS honour the policy; adoption is good among large providers and patchy elsewhere.
Cached policies persist for max_age, so an error can take that long to stop affecting senders.

Frequently asked questions

Should I use MTA-STS or DANE?: Both if you can. DANE requires DNSSEC and is stronger where deployed; MTA-STS works without it and is supported by the largest providers. They coexist without conflict.
What does testing mode do?: Senders evaluate the policy and report failures via TLS-RPT but still deliver. It is the safe way to validate your mx list before switching to enforce.
Why is my updated policy being ignored?: Senders cache by the policy id in the TXT record. Changing the policy file without changing the id means nothing refetches until max_age expires.
Do I need TLS-RPT?: Not technically, but deploying enforcement without reporting means delivery failures are invisible to you and visible only to the senders who gave up.

Related tools

MX Health DMARC Inspector TLS Analyzer