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.
What is MTA-STS?
MTA-STS (SMTP MTA Strict Transport Security) is a way for a domain to tell every sending mail server two things: always use TLS to reach me, and here are the exact servers allowed to receive my mail. It is defined in RFC 8461.
Here is the gap it closes. When one mail server hands a message to another, it normally upgrades to encryption with a command called STARTTLS. That upgrade is optional. If it does not happen, the message goes through in plain text anyway. An attacker sitting on the network path can quietly delete the STARTTLS offer, the sending server sees no encryption on offer, and it delivers the message unencrypted without raising any alarm. That is a downgrade attack, and RFC 8461 §2 names it as the threat MTA-STS exists to stop.
MTA-STS removes the silent fallback. Once you publish a policy, senders that support MTA-STS refuse to deliver to a server that fails the TLS checks instead of dropping to plain text. The protection covers inbound mail arriving at your domain, and it is independent of DMARC, SPF, and DKIM. Those three protect the From identity on a message. MTA-STS protects the transport that carries it.
How MTA-STS works: the policy file and the TXT record
MTA-STS has two parts that work together. A small DNS record points senders at a policy, and the policy itself is a text file served over HTTPS.
1. The TXT record. You publish a record at _mta-sts.yourdomain.com that looks like this:
The id is an opaque label for the current policy version (RFC 8461 allows up to 32 alphanumeric characters). We derive ours from a hash of the policy contents, so it changes only when the policy changes. That is how a sender knows to fetch the new file instead of trusting a cached copy (RFC 8461 §3.1).
2. The policy file. The TXT record tells senders a policy exists. The policy itself lives at a fixed HTTPS address, https://mta-sts.yourdomain.com/.well-known/mta-sts.txt, and reads like this:
mode: enforce
mx: mail.yourdomain.com
mx: *.yourdomain.net
max_age: 604800
Each field has a job (RFC 8461 §3.2):
versionis alwaysSTSv1.modeis one oftesting,enforce, ornone. The next section covers all three.mxlists the inbound hosts allowed to receive your mail. You can repeat the line. A wildcard is allowed, but only on the leftmost label, so*.yourdomain.netis valid andmail.*.netis not.max_ageis how long, in seconds, a sender may cache the policy. RFC 8461 sets the ceiling at 31557600 seconds, roughly one year. For policies inenforcemode we cap it at 604800 seconds (one week) so a rollback never has to wait long to take effect.
Two details trip up most hand-rolled deployments. The endpoint must return an HTTP 200 over a certificate that is valid for mta-sts.yourdomain.com, and senders will not follow a 3xx redirect to find the file (RFC 8461 §3.3). The policy is line-oriented text, and the ABNF accepts either LF or CRLF endings. We serve CRLF, which is the conservative choice for the broadest sender compatibility, and it is exactly the file our endpoint returns for you.
The three modes: testing, enforce, none
The mode field decides what a sender does when a TLS check fails (RFC 8461 §5).
testing
Senders still deliver the mail even if a TLS check fails, but they send you a TLS-RPT report describing what went wrong. This is the safe observation phase. You see which senders would be affected before anything changes.
enforce
Senders must not deliver to a host that fails the MX match, fails certificate validation, or does not support STARTTLS. This is the mode that blocks downgrade attacks. Reach it only after testing looks clean.
none
Senders treat your domain as having no policy at all. This is how you turn enforcement off cleanly. A sender that cached an enforcing policy reads mode: none and stops enforcing instead of hitting a hole.
The recommended rollout is testing first, then enforce. Watch the reports, confirm every legitimate sender already reaches you over TLS, then promote to enforce. Every hosted policy we create starts in testing mode, and switching it to enforce in our dashboard takes a deliberate confirmation step, so nobody flips to enforcement by accident.
Why hosting the policy is the hard part
Writing the policy text is the easy part. The work that does not end is keeping an HTTPS endpoint and its certificate alive forever.
To self-host MTA-STS you have to stand up a web server on mta-sts.yourdomain.com, get a certificate that matches that exact hostname, renew that certificate automatically before it expires, and return an HTTP 200 with the policy body every single time a sender asks. None of that can lapse, and here is why that matters. If the endpoint starts returning a 500, or the certificate quietly expires while your policy is in enforce, then every sender that already cached your enforcing policy keeps enforcing. They can no longer verify your servers, so they defer or bounce legitimate inbound mail until you fix the endpoint. The protection you turned on becomes an outage.
That is the part we run for you, and you can check it against how we operate it:
- You publish one CNAME,
mta-sts.yourdomain.com CNAME mta-sts-proxy.dmarctrust.com.Nothing else in your zone changes. - We provision the HTTPS hostname through Cloudflare for SaaS, which issues and renews the certificate. You never handle TLS material.
- We serve the policy file, and we watch the
_mta-stsTXTidfor drift, so the version label you published always matches the file we serve. - When you disable hosting, we do not just yank the file. We switch the policy to
mode: noneand keep serving it for your fullmax_agewindow before we remove the hostname. A sender that cached an enforcing policy readsnoneand downgrades cleanly, so disabling never creates the outage above.
For a deeper operational walk-through, read our notes on how Receiver Shield hosts MTA-STS and TLS reporting and the MTA-STS failure modes we see most often.
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
TLS-RPT (RFC 8460) is the companion to MTA-STS. You publish a TXT record at _smtp._tls.yourdomain.com with v=TLSRPTv1; rua=mailto:..., and senders return a JSON report, typically covering a full UTC day, of how their TLS connections to you went. It tells you whether senders actually reached you over encryption, which is the evidence you need before you promote a policy to enforce. We decode those reports and group the failures by result type. The wire values RFC 8460 defines include starttls-not-supported, certificate-host-mismatch, certificate-expired, certificate-not-trusted, and validation-failure, plus the MTA-STS policy errors sts-policy-fetch-error, sts-policy-invalid, and sts-webpki-invalid. TLS-RPT is not DMARC reporting. It is a different RFC for a different purpose: transport encryption, rather than the From identity.
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 failure reports 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 (RFC 9990) or failure (RFC 9991) reporting.
- 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.
- Do I need a separate MTA-STS generator for the policy and DNS records?
- No. When you enable hosting we generate both for you: the policy file we serve at `.well-known/mta-sts.txt`, and the exact `_mta-sts` and `_smtp._tls` TXT records to publish. There is nothing to hand-write or paste into a third-party MTA-STS generator.
- What is the difference between MTA-STS and DANE?
- Both make senders require TLS for inbound mail, but they prove the receiving server's identity differently. DANE publishes a TLSA record in DNS and depends on DNSSEC to make that record trustworthy. MTA-STS skips DNSSEC and instead relies on an HTTPS policy served under a certificate from a public certificate authority. The tradeoff: DANE needs DNSSEC across your zone, while MTA-STS needs a reliable HTTPS endpoint and a renewing certificate. We host that endpoint and certificate for you.
- Where is the MTA-STS policy file hosted?
- On a custom hostname under your own domain, `mta-sts.yourdomain.com`, which you point at us with one CNAME. We provision it through Cloudflare for SaaS, issue and renew the certificate, and serve the policy at the required `.well-known/mta-sts.txt` path with a short cache lifetime so the changes you make take effect quickly.
Enforce TLS on inbound mail without managing certificates
One CNAME. We do the rest.