What This MTA-STS and TLS-RPT Deployment Produces
The deployment has three concrete outputs: a directly reachable HTTPS MTA-STS policy, its DNS discovery record and a working TLS-RPT reporting destination. You will then verify the actual MX endpoints, interpret a sample JSON report and use the evidence to decide when to enforce. All example domains, addresses and counts are illustrative; they are not production test results.
A supporting sending MTA applies the receiving domain’s policy; only participating senders submit TLS-RPT reports. Publishing the records therefore does not establish coverage of all traffic. Keep SMTP connection results separate from SPF, DKIM, DMARC and inbox placement. If DANE is deployed, its DNSSEC and TLSA checks remain an additional dependency of the mail service.
Begin with DNS, HTTPS and MX ownership, then prepare a two-MX testing policy and reporting record. Use the hypothetical JSON to distinguish certificate, STARTTLS, policy-fetch and cache problems. The DANE sections cover integration and key changes for deployments that use it; MTA-STS does not have to precede DANE.
For protocol selection, failure precedence and provider DNS ownership, see the MTA-STS and DANE trust-model guide.
Before Deployment: DNS, HTTPS and Every MX Endpoint
List the receiving domain’s primary and backup MX hostnames, each IPv4/IPv6 address and the provider operating the service. Identify who can edit the TXT records, serve the mta-sts HTTPS endpoint and deploy MX certificates. Access to a web-hosting panel does not necessarily grant control of a shared mail server.
Check STARTTLS and the credential actually presented by every MX. MTA-STS requires the selected MX hostname in the certificate’s SAN, a valid certificate and a chain trusted by the sender. The HTTPS policy host has its own certificate requirement. Opportunistic STARTTLS alone does not enforce those checks for every sender, and a working primary MX does not verify a backup.
Prepare a collector for TLS-RPT attachments or HTTPS submissions before advertising it. During testing, participating senders can report MTA-STS failures without that policy preventing delivery. Enforce changes the consequence: a noncompliant path cannot be used. Record that distinction in the change plan before moving between modes.
Publish the MTA-STS Discovery Record and HTTPS Policy
MTA-STS publishes a policy over HTTPS and announces its presence through DNS. When a supporting sender has a valid, unexpired enforce policy, it must not deliver through an MX that fails policy matching or certificate validation, or that lacks STARTTLS. Initial discovery can still be suppressed before the sender has obtained and cached a policy; publication is not a universal downgrade-prevention guarantee.
How the pieces fit together
For the illustrative receiving domain example.com, configure two separate resources:
1) A TXT record at _mta-sts.example.com that advertises the policy version and change identifier.
2) A policy file served directly at https://mta-sts.example.com/.well-known/mta-sts.txt.
The TXT record contains the required version and id. The id uniquely identifies a policy revision; it does not have to be a date or an increasing number, and it is not a URL. Replace the example domain and use a new id when the policy changes:
_mta-sts.example.com. 3600 IN TXT "v=STSv1; id=policy1"Start with a testing policy and replace the MX names with the receiving hosts you actually use. Each allowed MX pattern has its own line. This example’s max_age is seven days in seconds, an illustrative cache lifetime to evaluate for your rollout:
version: STSv1
mode: testing
mx: mail1.example.com
mx: mail2.example.com
max_age: 604800Testing permits delivery as though the MTA-STS validation failure had not occurred; participating TLS-RPT senders can report those failures. Enforce prohibits delivery through an MX that fails the stated checks. None indicates that the domain has no active MTA-STS policy and is used for a controlled opt-out. The max_age value controls policy caching, not how long you must wait before enabling enforcement.
Why HTTPS matters
The policy URL must return a 200 response over HTTPS with a certificate valid for mta-sts.example.com and trusted by the sender. Serve the policy as plain text at the exact well-known path. MTA-STS clients must not follow HTTP redirects or use HTTP caching for retrieval; the protocol maintains its own policy cache. Verify the externally visible endpoint even if a CDN or reverse proxy serves it.
Common rollout pitfalls
Cover every active and backup MX with an allowed policy pattern before using it. The policy matches hostnames, so an IP rotation alone does not require a policy change. Validate STARTTLS, hostname coverage, certificate chains and renewal deployment across the actual endpoints. Use representative reports and connection tests before enforce; a week of elapsed time or an empty report mailbox is not sufficient. When the file changes, publish and verify it before changing the DNS id, and account for existing caches.
How this affects delivery
MTA-STS enforcement rejects a noncompliant delivery path; it does not fix the underlying connection. Affected mail can be delayed while the fault or policy is corrected. TLS-RPT reports from participating senders help identify the relevant MX and failure category, but absent reports are not evidence that every sender can deliver.
Keep certificate issuance, renewal and deployment in the maintenance plan for both the HTTPS policy endpoint and MX servers. For related setup choices, see CAA records and a multi-CA strategy and the ACME challenges guide. A successful renewal must also reach the service that clients contact.
The protocol requirements are defined in SMTP MTA Strict Transport Security, RFC 8461.
Publish TLS-RPT and Interpret the JSON Report
TLS-RPT lets participating senders report successful and failed SMTP TLS sessions to your domain. Reports are aggregated over a reporting interval, commonly daily. They describe transport-policy results, not individual message delivery or inbox placement, and the standard schema is not an inventory of negotiated cipher suites or attempted TLS versions.
What the record looks like
Publish a TXT record at _smtp._tls.example.com. The rua value advertises a working report destination; this example uses a mailbox. The protocol also supports HTTPS report submission and comma-separated destination URIs. Replace the address with a collector you operate or have configured to receive your reports:
_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"For mailto delivery, prepare the mailbox or collector to process the report attachments and validate incoming report messages, including their required reporting-domain DKIM signature. Monitor receipt and parser errors. Opening a mailbox without publishing the reporting record does not advertise the endpoint.
What you’ll see in the reports
Each report contains a reporting interval and one or more per-policy result groups. A group includes a nested policy object, total successful and failed session counts, and failure details. For an MTA-STS policy, mx-host holds the policy’s MX patterns; receiving-mx-hostname identifies the receiving MX involved in a reported failed attempt. Do not treat these as interchangeable or label all MX fields optional. Standard result names include certificate-host-mismatch and starttls-not-supported.
This hypothetical JSON report includes all 25 failures in its two detail entries: 17 hostname mismatches and 8 STARTTLS failures. The 100 successful sessions and other values are illustrative, not measured results. The policy-string and mx-host values are arrays, and the policy information is nested under policy:
{
"organization-name": "Example Sender",
"date-range": {
"start-datetime": "2025-01-01T00:00:00Z",
"end-datetime": "2025-01-01T23:59:59Z"
},
"contact-info": "postmaster@example.net",
"report-id": "example-report-1",
"policies": [
{
"policy": {
"policy-type": "sts",
"policy-string": [
"version: STSv1",
"mode: testing",
"mx: mail1.example.com",
"mx: mail2.example.com",
"max_age: 604800"
],
"policy-domain": "example.com",
"mx-host": [
"mail1.example.com",
"mail2.example.com"
]
},
"summary": {
"total-successful-session-count": 100,
"total-failure-session-count": 25
},
"failure-details": [
{
"result-type": "certificate-host-mismatch",
"sending-mta-ip": "203.0.113.44",
"receiving-mx-hostname": "mail1.example.com",
"receiving-ip": "192.0.2.10",
"failed-session-count": 17,
"failure-reason-code": "Certificate identity does not match MX hostname"
},
{
"result-type": "starttls-not-supported",
"sending-mta-ip": "198.51.100.22",
"receiving-mx-hostname": "mail2.example.com",
"receiving-ip": "192.0.2.20",
"failed-session-count": 8,
"failure-reason-code": "STARTTLS not advertised"
}
]
}
]
}In this example, investigate the certificate SAN and actual MX name for the 17 certificate-host-mismatch sessions, then inspect STARTTLS advertisement and the path to mail2.example.com for the 8 starttls-not-supported sessions. Correlate each with logs for the reporting interval. For certificate-not-trusted, inspect the served chain and the sender’s reason details. Real reports can count more than one failure category for a connection attempt, so summing detail rows does not always produce a unique session or lost-message count. Change the MTA-STS id when the policy file changes, not after every unrelated server repair.
The report structure and field definitions are specified in SMTP TLS Reporting, RFC 8460.
Additional Checks When the Deployment Uses DANE
For an existing or planned DANE deployment, keep two checks separate: DNSSEC validation of the relevant data, and the receiving credential’s match to usable TLSA associations. The sender needs DNSSEC, DANE and STARTTLS support; the receiving service needs STARTTLS and appropriate DNSSEC-published TLSA data. Do not treat a DNSSEC failure as authenticated absence of TLSA or use successful MTA-STS validation to bypass failed applicable DANE authentication.
What needs to be in place
Verify the DNSSEC validation path used to discover your MX hosts and the signed TLSA data for those hosts. If a provider owns the MX hostname and its DNS zone, that provider may need to publish the TLSA records. For a non-aliased MX named mail1.example.com, with SMTP on port 25 upgraded by STARTTLS, the TLSA owner name is:
_25._tcp.mail1.example.com.A TLSA record contains a certificate usage, selector, matching type and association data. The 3 1 1 combination means DANE-EE, the SubjectPublicKeyInfo (SPKI) selector and SHA-256 matching. Below is a syntactically complete example with a 64-character hexadecimal placeholder, not a verified association for a supplied certificate. Replace it with the SHA-256 digest of the DER-encoded SPKI from the certificate your SMTP server actually presents; do not publish this sample value for your service.
_25._tcp.mail1.example.com. 3600 IN TLSA 3 1 1 e0dba8afdeb77b8536b6a613a4cfe6528d313059d510be687109bf18ae636faeFor 3 1 1, renewing a certificate with the same public key preserves the SPKI digest. A key change needs a corresponding TLSA transition. During a planned rotation, publish old and new associations before changing the server key, allow previous TLSA and related signature caches to expire, then deploy and verify the new key before retiring the old association. No fixed number of hours applies to every zone.
Classify a DNSSEC or TLSA Failure
When a sender finds at least one usable, DNSSEC-secure TLSA record, it must authenticate the SMTP server with those records and must not deliver through that server if authentication fails. DANE-EE(3) relies on the leaf certificate association rather than public-CA trust or certificate-name matching; its name and expiry rules differ from MTA-STS. Maintain DNSSEC signatures, TLSA associations and other clients’ certificate requirements together. A published TLSA record without successful DNSSEC validation does not provide the same assurance.
The normative SMTP behavior is described in SMTP Security via Opportunistic DANE TLS, RFC 7672.
Record the Evidence for Testing and Enforcement
Use the following sequence as an operational change record. For each MX, record its hostname, IP, STARTTLS result, certificate SAN and chain, and observation time. Track report collection separately from endpoint readiness. If DANE is used, add its zone owner, DNSSEC result and actual association to that record.
Step 1: Turn on TLS‑RPT and listen
Publish the reporting TXT record and verify that the chosen mailbox or HTTPS collector receives and parses reports. Establish which sending organizations and MX paths appear in them. Combine the reports with delivery logs and external connection tests; do not interpret a quiet mailbox as proof that every path works.
Step 2: Publish MTA‑STS in testing mode
Publish a testing policy at the exact HTTPS endpoint, verify its certificate and response, and make sure every active MX is covered. Choose max_age with caching and future changes in mind; the example uses seven days, not a mandatory rollout duration. Update the DNS id when the policy changes and investigate recurring report failures.
Step 3: Move to enforce
Move to enforce after the MX, STARTTLS, certificate and report checks have passed for representative traffic and all relevant endpoints. Publish the new policy and change the id. Continue checking queues, connection logs and reports. Supporting senders with a valid enforce policy will refuse a noncompliant path, which can expose any missed configuration problem as a delivery delay.
Step 4: Verify DANE Integration Where Used
For DANE, validate DNSSEC and TLSA matching for each intended MX path. A shared-hosting customer may need the provider to manage the MX zone and certificate association. Plan key changes using overlapping TLSA records and the previous DNS cache lifetimes; test the resulting association before retiring the old record. This process can be prepared independently of the MTA-STS rollout.
Stable hostname ownership and a documented DNS change process help keep these settings aligned. For related naming and delegation considerations, see the domain planning guide for ccTLDs, gTLDs and delegations.
Certificate and DNS Maintenance
Consider a planned backup-MX addition. If the hostname is missing from an enforce policy, supporting senders cannot use it under that policy. If DANE coverage is intended, the new host’s TLSA publication and actual key must also be checked. Update and validate the relevant records before directing traffic to the host, while accounting for cached policies. This example illustrates a dependency, not a reported customer incident.
Certificates and deployment
For MTA-STS, the MX certificate must have a SAN matching the hostname and a valid chain to a root trusted by the sender. The HTTPS policy endpoint has its own hostname and certificate requirement. Automate renewal where supported, monitor failures and verify deployment to every service. Choose a validation method that fits the mail and web architecture; the ACME challenges guide explains the differences.
CAA and public certificate issuance
If you publish CAA records, keep them compatible with the public certificate authorities used for MTA-STS endpoints and MX certificates. CAA restricts issuance authorization; it does not replace DNSSEC validation or TLSA matching. DANE-EE itself does not require the same public-CA trust model. Review the CAA strategy guide when changing issuers or renewal workflows.
Plan MX and policy changes together
Before introducing an MX hostname, prepare its TLS service and certificate, publish and validate TLSA data if DANE coverage is intended, and add the hostname to the MTA-STS policy. Change the discovery id after verifying the updated policy file. Allow for previously cached policies that may not yet permit the new host, and keep existing usable MX paths during the transition. Lowering a TTL does not immediately shorten records already cached with an older TTL.
Keep transport results separate from reputation
Transport reports help diagnose policy and TLS faults. Sender reputation, message authentication and spam filtering have separate causes and evidence. If those are the problem, use delivery responses and the sender reputation guide alongside this transport checklist; enabling MTA-STS or DANE is not a reputation-repair step by itself.
Troubleshooting by Failure Type
Record the affected domain, receiving MX, sender, time interval and exact result before changing configuration. The following checks address different stages of the connection.
“My policy is unreachable”
Verify DNS for mta-sts.example.com, the certificate’s hostname and chain, and the exact well-known path. The endpoint must return the policy directly with HTTP 200 over HTTPS; redirects, login requirements, blocked paths or an HTML error page are not valid policy delivery. Check the externally visible response when a CDN or proxy is involved.
“We flipped to enforce and some senders can’t deliver”
For certificate-host-mismatch, compare the actual MX hostname and certificate SANs. For starttls-not-supported, check STARTTLS advertisement and the network path to every affected MX. Fix the underlying fault first. If an operational decision requires temporarily changing to testing, update the policy and id but account for cached enforce policies; this is not an immediate rollback switch. Use precise timestamps, hostnames and IPs when escalating a provider issue.
“Our DANE records broke after a cert change”
Recompute the expected association for the configured usage, selector and matching type, and compare it with the key actually presented. With 3 1 1, a new key changes the digest even if the certificate’s hostname stays the same. For a planned rotation, publish both associations before switching keys and wait for the previous TLSA/signature cache lifetime. Verify the new deployment and DNSSEC chain before removing the retired association.
“We added a backup MX and now the reports complain”
Confirm that the backup MX hostname matches an allowed MTA-STS pattern and presents a suitable certificate with STARTTLS. If DANE protection is intended for that path, verify its usable DNSSEC-secure TLSA association too. A missing TLSA record is not automatically a TLSA mismatch: sender behavior depends on the authenticated DNS result and its policy. Diagnose the actual lookup and connection result.
“How do I roll back safely?”
For MTA-STS, changing to testing or none and updating the DNS id announces a policy change, but existing caches may retain enforcement. A complete opt-out keeps the none policy and discovery endpoint available until previously served policies have expired. For DANE, coordinate DNS associations and server keys using the relevant cache lifetimes. Do not delete the working association before a replacement is deployed and verified.
Checks Before and After a Change
Use these checks when a policy, certificate, MX host or DNS setting changes:
Keep the MX scope explicit. List the hostnames or deliberately chosen patterns that serve the domain, including real backup hosts. A wildcard pattern has defined matching rules; it should reflect the intended provider scope, not an unexamined shortcut.
Track hostname and IP changes separately. MTA-STS patterns refer to MX hostnames. If only an IP address changes, the policy name may remain valid, but the new endpoint still needs the correct TLS service and certificate.
Test outside the local network. Verify public DNS, HTTPS policy retrieval and SMTP STARTTLS against the actual endpoints, including IPv4 and IPv6 where used. Internal DNS or a proxy can produce results that differ from what an external sender receives. Check SNI behavior too: MTA-STS clients must send the policy hostname when retrieving the HTTPS policy and the MX hostname when connecting over SMTP. SMTP servers must not require clients to send SNI; if it is absent or names an unsupported host, they must present a fallback certificate chain rather than reject the connection for that reason.
Record cache lifetimes. Account for MTA-STS max_age, DNS TTLs and relevant DNSSEC signature data. Plan changes from the previously published values; reducing a value now does not retroactively invalidate older cached data.
Retest the policy endpoint after web changes. Confirm that access controls, routing rules, redirects and CDN behavior still allow a direct 200 plain-text response at the well-known path. A successful page load at another URL does not verify MTA-STS retrieval.
When the Fault Is Outside SMTP TLS
If TLS negotiation and the applicable transport checks succeed, inspect the SMTP acceptance response and subsequent delivery handling. Recipient rejection, greylisting, rate limiting, spam filtering and domain-authentication policy are separate investigation paths. A TLS-RPT success count does not prove inbox placement or end-to-end message encryption.
Keep the policy-fetch check, MX certificate check and any DANE association check separately identifiable in the handover. An HTTPS policy certificate and an SMTP credential belong to different connections. Record which provider or team owns each result so a web endpoint fault is not assigned to the mail service, or a server-key mismatch to the reporting collector.
Example Records and Policy
These are separate configuration elements for the illustrative example.com domain. Replace domains, MX hostnames, report destinations and TLSA digests before use. The TXT and TLSA lines use DNS zone-file notation; a DNS provider’s form may require the owner name, TTL and value in separate fields. They are examples to adapt and verify, not a complete deployable mail-server configuration.
MTA‑STS DNS signal
_mta-sts.example.com. 3600 IN TXT "v=STSv1; id=policy1"MTA-STS policy at the HTTPS endpoint
version: STSv1
mode: testing
mx: mail1.example.com
mx: mail2.example.com
max_age: 604800TLS-RPT report destination
_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"DANE TLSA records for the example MX hosts
_25._tcp.mail1.example.com. 3600 IN TLSA 3 1 1 e0dba8afdeb77b8536b6a613a4cfe6528d313059d510be687109bf18ae636fae
_25._tcp.mail2.example.com. 3600 IN TLSA 3 1 1 e0dba8afdeb77b8536b6a613a4cfe6528d313059d510be687109bf18ae636faeThe two TLSA examples deliberately share the same illustrative key digest. Real hosts may use different keys and require different values. After verifying readiness for MTA-STS enforcement, change the policy file’s mode to enforce and replace the discovery TXT record with a new id, for example the following. Do not publish both id revisions simultaneously:
_mta-sts.example.com. 3600 IN TXT "v=STSv1; id=policy2"Hand Over the Deployment and Repeat Checks After Changes
The handover should identify the public policy URL and body, discovery id, permitted MX hosts, certificate deployment owners and report destination. Confirm the actual endpoints and report processing; a visible TXT record or the illustrative JSON in this article is not proof that production works. Keep each observed report tied to its interval and connection logs.
Repeat endpoint, policy and reporting checks after MX, certificate, key or DNS changes. Where DANE is used, verify DNSSEC and the planned TLSA transition separately. Retain the previous policy and cache values in the change record so an incident can be explained using what a sender could still have cached.
For related maintenance tasks, consult the guides to CAA records and multi-CA planning, ACME automation and sender reputation. Each addresses a different part of operating a mail service.
