MTA-STS: Test Mail TLS Before You Enforce It
Summarize with AI
MTA-STS should move to enforcement only after every legitimate MX host supports STARTTLS, presents a valid matching certificate, and appears correctly in the published policy. Start in testing mode, review TLS reports, and prepare a cache-aware rollback. This protects inbound SMTP transport; it does not authenticate senders or improve cold-email inbox placement.
Inventory the receiving path first
MTA-STS tells compliant sending servers which MX hosts may receive mail for your domain and requires authenticated TLS when policy mode is enforce. A missing legitimate host or invalid certificate can delay mail, so the policy must follow the real receiving system rather than an old diagram.
List every published MX record, its priority, provider, hostname, certificate owner, and change owner. Include backup and low-priority hosts that rarely receive traffic. Test each hostname from outside your network for STARTTLS and the certificate it actually presents.
RFC 8461 requires the certificate to be unexpired, chain to a trusted root, and contain a matching DNS identity in the subject alternative name. A browser check of the provider's website does not test the SMTP certificate.
Publish the two discovery surfaces
The DNS marker lives at _mta-sts.<domain> as a TXT record. The policy lives at https://mta-sts.<domain>/.well-known/mta-sts.txt. The policy includes its version, mode, maximum cache age, and one or more allowed MX patterns.
Keep the HTTPS host highly available and use a certificate valid for mta-sts.<domain>. Make the policy body a controlled file with a named owner. The TXT record's identifier signals a new policy version; it is not the policy itself.
Start with mode: testing. Under the RFC, compliant senders can report validation failures while delivery may continue. Testing mode gives you evidence without intentionally making a policy mismatch block delivery.
Add TLS reporting before enforcement
TLS-RPT is a separate DNS record at _smtp._tls.<domain>. RFC 8460 defines v=TLSRPTv1 with an aggregate report destination in rua. Reports can contain successful and failed session counts, grouped failure details, policy information, and result types.
Confirm the report destination can receive, parse, store, and alert on those reports. Identify which failures come from legitimate senders and which are background noise. A report count without the active policy, date range, and MX inventory is not enough for an enforcement decision.
Our view: the release record should include representative senders and all valid MX paths, not a universal observation period. The RFCs do not prescribe a fixed number of clean days or a zero-failure threshold, so your approver must define what evidence is sufficient for this domain.
Use an explicit enforcement gate
Before changing to mode: enforce, require a signed checklist: every current MX appears in policy; every MX offers STARTTLS; every certificate validates and matches; HTTPS policy retrieval works externally; TLS reports arrive; failure classes are understood; the service owner and rollback owner agree; and the change window is recorded.
In enforce mode, compliant senders must not deliver to MX hosts that fail policy matching, STARTTLS, or certificate validation. One omitted backup host can therefore turn a policy mistake into delayed mail.
Change the HTTPS policy body before updating the TXT identifier. RFC 8461 warns that cached policies remain active until their max_age expires and recommends keeping old policy endpoints functional during overlap. DNS propagation is only one clock; sender-side caches are another.
Plan rollback before the change
A clean removal is not deleting both records immediately. RFC 8461 describes publishing a new mode: none policy with a short cache age, then signaling it with a new TXT identifier. Previously served policies and endpoints should remain available until old caches expire.
Write the exact rollback body, DNS change, approver, and waiting period into the release record. Preserve the old and new policy text. If mail delays appear, responders should not have to invent a sequence while the domain is under pressure.
Keep the boundary clear
MTA-STS protects SMTP transport to a receiving domain when the sending server supports the standard. It does not publish SPF authorization, add DKIM signatures, evaluate DMARC alignment, score reputation, or prove inbox placement.
The control becomes dependable when the domain owner can show the MX inventory, certificate tests, report evidence, approved policy, and rollback path in one place.
Prove the receiving path before enforcement
We can map your mail dependencies and change controls during an ICP and campaign-fit discovery call. Book your free discovery call →
Frequently Asked Questions
A strong positive reply rate for B2B cold email is 1.5–3%. Top-performing campaigns with tight targeting and personalized copy can hit 4–5%. If you're below 1%, it usually signals a deliverability or messaging problem, not a volume problem.
The safe range is 30–50 emails per inbox per day for warmed inboxes. That's why outbound systems use multiple inboxes (we use 80) to reach 40,000+ monthly sends while keeping each inbox well within safe limits. Sending more than 50/day from a single inbox risks spam folder placement.
Yes. The CAN-SPAM Act permits unsolicited commercial email as long as you include a physical address, an unsubscribe mechanism, accurate headers, and non-deceptive subject lines. Unlike GDPR in Europe, the US does not require prior opt-in consent for B2B cold outreach.
Domain warm-up typically takes 2–3 weeks. During this period, sending volume gradually increases while the email warm-up tool generates positive engagement signals (opens, replies) to build sender reputation. Skipping or rushing warm-up is the most common cause of deliverability problems.
Cold email is targeted, relevant outreach to a specific person based on their role, industry, or company, with a clear business reason. Spam is untargeted mass messaging with no personalization or relevance. The distinction matters legally (CAN-SPAM compliance) and practically (deliverability depends on relevance signals).
Sofia Urrego
Account Success, LeadHaste
Looks after LeadHaste accounts end to end, from targeting and copy through to the conversations that come back, so each client keeps improving month over month.