MTA-STS and TLS-RPT Setup: Enforce TLS Without Breaking Inbound Mail

Direct answer: MTA-STS (RFC 8461) is an inbound policy you host so sending servers refuse SMTP downgrades when they deliver to your domain. TLS-RPT (RFC 8460) is the daily JSON report of those TLS successes and failures. Publish TLS-RPT first, serve a testing-mode policy that lists your real MX names, watch reports, then flip to enforce and bump the policy id. ArawaMail does not document writing these records for you.

The problem MTA-STS actually solves

SPF, DKIM, and DMARC answer “who is allowed to send as this From.” They do not answer “must other servers use TLS when they hand mail to my MX.” Classic SMTP can still advertise STARTTLS and then be downgraded on the path between two mail servers.

MTA-STS is that missing transport policy. It is MTA-to-MTA. It is not the TLS mode your laptop uses to submit mail. Client submission — STARTTLS on 587 versus implicit TLS on 465 — already has its own guide: STARTTLS vs Implicit TLS. Do not put IMAP or device SMTP hostnames into an MTA-STS policy. Those names are not MX.

Adoption is still thin. Public scans of the top million zones in early 2026 still show MTA-STS well under 1 percent (about 0.7 percent in published snapshots). Large receivers still honor it. Gmail, Microsoft 365, Yahoo, and iCloud are widely described as applying published policies in 2026. Google Workspace Help continues to document MTA-STS plus TLS reporting for inbound protection. Low zone adoption is not a reason to skip a policy that the mailboxes you care about already read.

The three artifacts

You need all three. Missing any one means senders cannot discover or cache a trustworthy policy.

1. The HTTPS policy file

Serve a plaintext file at:

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

The hostname is mta-sts under the domain whose inbound mail you are protecting. The file must be HTTPS with a valid public certificate for that hostname. A typical testing file looks like this:

version: STSv1
mode: testing
mx: mx1.example.net
mx: mx2.example.net
max_age: 86400

Replace the mx: lines with the exact MX targets in your live zone — the right-hand side of the MX records, not a guess and not a device hostname. ArawaMail publishes inbound MX onto the Cloudflare zone when you activate receiving. Public docs do not list those hostnames. Copy them from Cloudflare or from the product on the day you write the file. Never publish mx: mail.arawamail.com because it appeared in a blog post.

mode is testing or enforce. max_age is how long senders may cache the policy, in seconds. Start short (a day) while you are watching reports.

2. The _mta-sts TXT record

At _mta-sts.example.com:

v=STSv1; id=20260907t1

The id is a cache-buster, not a secret. Change it every time the policy file changes so senders refetch instead of waiting out max_age.

3. The TLS-RPT TXT record

At _smtp._tls.example.com:

v=TLSRPTv1; rua=mailto:[email protected]

RFC 8460 also allows an HTTPS rua. Reports are daily JSON summaries of TLS success and failure when other servers delivered to you. They are not DMARC aggregate reports. Do not parse them with a DMARC rua mailbox and expect the same schema. Point rua at a mailbox you actually read.

Testing first, enforce later

1. Create the report mailbox and publish _smtp._tls. You want a place for failures before you can cause them.
2. Create the mta-sts hostname, put a valid certificate on it, and serve the policy in mode: testing with the live MX list.
3. Publish _mta-sts with a new id.
4. Wait. Two weeks of clean reports that name the MX hosts you intended is a reasonable floor for a domain that already receives production mail.
5. Switch the file to mode: enforce, bump id, and consider raising max_age once the policy is stable.

Testing mode reports failures and still delivers. Enforce mode can fail closed. If the policy lists the wrong MX, or the certificate on an inbound MX hostname is wrong, senders that honor enforce will refuse the message rather than downgrade.

Google Workspace documentation still expects TLS 1.2 or newer and a valid public certificate that matches the inbound MX hostname. That certificate requirement is on the MX hosts, not only on mta-sts.

What ArawaMail does and does not write

ArawaMail requires an active Cloudflare zone. It publishes MX for inbound delivery when you activate receiving, and it publishes DKIM, SPF, and MAIL FROM records when you enable sending. Those paths are documented. MTA-STS and TLS-RPT are not.

Treat the policy file, the _mta-sts TXT, and the _smtp._tls TXT as operator-owned unless the live product later says otherwise. ArawaMail does not document hosting https://mta-sts./.well-known/mta-sts.txt.

Two Cloudflare constraints matter:

• Mail-related hostnames should stay DNS-only (grey cloud), not proxied. A proxied MX target is the wrong shape for SMTP. A proxied mta-sts hostname can present the wrong certificate identity to policy fetchers.
• Do not copy placeholder device hosts from connect-device docs into the policy. Public device docs use example IMAP/SMTP names. Those are client settings, documented separately from inbound MX.

Connecting the zone is How to connect a Cloudflare domain to ArawaMail. Identity records are SPF, DKIM, and DMARC explained. Neither page is an MTA-STS wizard.

MTA-STS is not DANE, and it is not DMARC

DANE/TLSA pins TLS certificates in DNSSEC. It is a different mechanism. Mention it so you do not confuse the two; do not implement it from this page. Gmail relies on MTA-STS for inbound transport policy rather than inbound DANE. Microsoft 365 is the major provider documented as supporting both.

DMARC alignment decides whether a From domain is authenticated. MTA-STS decides whether the hop onto your MX must stay on TLS. A domain can pass DMARC and still accept cleartext inbound SMTP if no STS policy exists. The two controls stack; they do not substitute.

Outbound IP identity — PTR / reverse DNS on the sending hosts — is a third layer and lives in Reverse DNS and PTR records. Submission ports are in SMTP ports 25, 465, and 587.

How a rollout fails

• Enforce on day one with guessed MX. Senders cache a policy that does not match the zone. Inbound mail from STS-aware providers stops.
• Policy host proxied or certificate-mismatched. Fetchers cannot validate https://mta-sts.. The policy is ignored, or enforce fails closed once a stale good policy expires.
• File changed, id not bumped. Senders keep the old mode or the old MX list until max_age.
• Device SMTP names in mx:. The policy describes hosts that never accept inbound SMTP for the domain.
• No TLS-RPT mailbox. You flip to enforce blind.

The good path is boring: TLS-RPT first, testing policy that mirrors the live MX list, reports that name those hosts, then enforce plus a new id.

How we analyzed this

This is an operator setup guide. Protocol facts follow RFC 8461 (MTA-STS) and RFC 8460 (TLS-RPT). Receiver support statements reflect 2026 public documentation: Gmail honors MTA-STS rather than inbound DANE; Microsoft 365 documents both; Google Workspace Help still describes MTA-STS and TLS reporting for inbound protection. Adoption figures cite early-2026 public scans of the top million zones (about 0.7 percent, still under 1 percent). ArawaMail behavior is limited to public docs: Cloudflare zone required; receiving publishes inbound MX; sending publishes DKIM / SPF / MAIL FROM; no documented MTA-STS or TLS-RPT writer; no documented policy-file host. Exact inbound MX hostnames are omitted because they are not in public docs — copy them from the live zone before any policy is published.

Related guides

STARTTLS vs Implicit TLS · SMTP ports 25, 465, and 587 · Connect a Cloudflare domain · SPF, DKIM, and DMARC explained · Reverse DNS and PTR records · DMARC alignment vs SPF pass · Free email tools

FAQ

Does MTA-STS authenticate From the way DMARC does?
No. DMARC aligns identifiers with the visible From. MTA-STS constrains TLS when other servers deliver to your MX.

Does ArawaMail publish MTA-STS for me?
Not in public documentation. You host the policy file and you publish _mta-sts and _smtp._tls. ArawaMail does publish the inbound MX you must list in that file.

What goes in the policy mx: lines?
The MX hostnames currently in the zone for that domain — the targets receiving already uses. Copy them. Do not invent them. Do not use IMAP or submission hostnames.

Why start in mode: testing?
Testing reports TLS failures without refusing mail. Enforce can fail closed if the MX list or certificates are wrong.

Where do TLS-RPT reports arrive, and what do they look like?
Wherever you put in rua. They are daily JSON summaries of TLS success and failure, not DMARC XML.

Will enforce mode break mail if Cloudflare proxies the MX or the policy host?
It can. Keep mail MX DNS-only. Give mta-sts. a certificate that matches that hostname. A proxied orange-cloud name is the usual way to present the wrong identity.

Do I need DANE as well?
Only if you have DNSSEC and a reason to pin certificates that way. Gmail inbound policy is MTA-STS. This page is not a DANE tutorial.