Hosted MTA-STS · TLS-RPT
Hosted MTA-STS and TLS-RPT monitoring, in one CNAME record
MTA-STS tells senders to require TLS when delivering to your domain. We host the policy file, rotate the HTTPS certificate, and decode the TLS-RPT reports senders return. You publish one CNAME, we run the rest.
Built by Florian Le Goff & Marc Lelu, ex-Mailjet deliverability engineers. Last updated May 24, 2026.
Senders cannot enforce TLS unless you publish a policy
A sender that supports MTA-STS asks https://mta-sts.yourdomain.com/.well-known/mta-sts.txt for your policy. If nothing answers, the sender falls back to opportunistic TLS, and an attacker on the path can strip encryption without the sender noticing. RFC 8461 §5 describes the policy-retrieval and reporting flow we host on your behalf.
How it works in 3 steps
Publish one CNAME
Add mta-sts.yourdomain.com CNAME mta-sts-proxy.dmarctrust.com. in your DNS. No other record changes.
We provision the HTTPS hostname
We create a custom hostname in Cloudflare for SaaS. The certificate issues and renews on its own. You never touch TLS material.
We host the policy and parse TLS-RPT
We decode incoming TLS reports and group them by result type and MX host in your dashboard.
What you get
Hosted policy with auto-renewing certificate
We serve the policy file from a custom hostname under your domain. The HTTPS certificate renews itself, so there is nothing for you to operate.
Lifecycle states with safe rollback
Switch a policy from testing to enforce, or roll back. When you disable hosting we serve mode: none for your max_age window before deprovisioning, so caching senders never see a missing policy.
TLS-RPT scorecard
Failures grouped by result type (certificate_expired, starttls_not_supported, certificate_name_mismatch, tlsa_validation_failure) and by receiving MX host.
Out-of-sync detection on the _mta-sts TXT record
We warn you when the published id= field no longer matches the policy currently served, so senders don't keep refetching a stale file.
Free dashboard view, paid hosting
Every plan can see the status of MTA-STS and TLS-RPT for monitored domains. Hosting the policy on your behalf is part of the Pro plan.
Works alongside
Read your DMARC reports as a dashboard
Stop parsing aggregate XML by hand. See sources, alignment, and forensics in one view.
Read more →Check what your ESPs actually deliver
Inbox Inspector evaluates SPF, DKIM, and DMARC for every campaign your providers send.
Read more →MTA-STS common issues and how to fix them
Hands-on debugging walk-through of the failure modes we see most often.
Read more →Frequently asked questions
- Will senders cache the old policy if I disable hosting?
- Yes. That is why we keep serving the policy with `mode: none` for the duration of your `max_age` window before deprovisioning the hostname. Senders that already cached an enforcing policy see `mode: none` and stop enforcing cleanly.
- Does this work with Cloudflare-fronted domains?
- Yes. We use Cloudflare for SaaS, so you do not need to migrate the apex zone. You add one CNAME on the `mta-sts` label and we provision the HTTPS hostname end-to-end.
- What is the difference between modes `testing`, `enforce`, and `none`?
- `testing` tells senders to report failures but still deliver; `enforce` tells senders to reject mail that fails TLS checks; `none` tells senders to stop applying the policy. See RFC 8461 §5.
- Is TLS-RPT the same as DMARC reporting?
- No. TLS-RPT (RFC 8460) reports transport encryption failures and is separate from DMARC aggregate or forensic reporting (RFC 7489).
- Can I use this without DMARC?
- Yes. Hosted MTA-STS and TLS-RPT monitoring are independent of DMARC. You can run either, neither, or both.
Enforce TLS on inbound mail without managing certificates
One CNAME. We do the rest.