MTA-STS lets a receiving domain publish expectations for authenticated TLS delivery. It addresses the SMTP connection to the receiving service. It does not authenticate the message author's From address or encrypt the message all the way from one person's device to another.
A working deployment connects three things: the domain's actual inbound MX routes, the HTTPS policy and the DNS record that signals that policy. TLS reporting supplies a separate feedback path.
Establish the real receiving boundary
References: RFC 8461 §3.4, RFC 8461 §4.
List the MX hosts that accept mail for the domain, including backup services and an upstream security gateway. Verify TLS and certificate behaviour on the actual public receiving boundary, not only on an internal mailbox server.
Record who owns the MX route, policy hosting, certificate renewal and reporting destination. A hosted mailbox service does not necessarily host the customer's MTA-STS policy or operate every gateway in front of it.
Assess subdomains separately. MTA-STS does not use DMARC-style parent-policy inheritance. A receiving subdomain needs the configuration applicable to that domain.
Build a policy for the actual hosts
References: RFC 8461 §3.2, RFC 8461 §3.3.
Serve the policy from the required HTTPS location for the receiving domain. For example.com, the location is https://mta-sts.example.com/.well-known/mta-sts.txt. The HTTPS service needs a valid certificate for its policy hostname.
The policy identifies its version, mode, permitted MX patterns and maximum cache lifetime. Start with a scope-appropriate testing deployment and inspect the results before enforcement. Choose the observation period from the real traffic and dependencies rather than treating a sample duration as universal proof.
An illustrative policy for a fictional single-MX domain is:
version: STSv1
mode: testing
mx: mx1.example.net
max_age: 86400This example assumes mx1.example.net is the domain's actual receiving host and has appropriate SMTP TLS support. It is not a ready-made policy for another provider. Match permitted hosts precisely and include every legitimate receiving route.
Publish discovery and reporting separately
References: RFC 8461 §3.1, RFC 8461 §8.1, RFC 8460 §3.
At _mta-sts.example.com, an illustrative TXT value is v=STSv1; id=2026110701. The identifier signals a policy revision. Publish and verify the policy before advertising its new revision in DNS.
TLS-RPT uses its own record at _smtp._tls.example.com. An illustrative request is v=TLSRPTv1; rua=mailto:tls-reports@example.com, assuming that address exists and its collection path works.
Do not assume a DMARC rua destination automatically receives TLS reports, or that MTA-STS testing alone creates a working reporting request. Verify each record at the correct name and each destination through its own collection process.
Test the deployed chain
References: RFC 8461 §4, RFC 8461 §6.
Fetch the policy externally and confirm the required HTTPS endpoint serves the intended plain-text body with HTTP 200. Do not follow HTTP redirects: a redirect is not a valid policy fetch under RFC 8461 §3.3. Check discovery DNS and compare all advertised MX routes with permitted patterns.
Test SMTP TLS and certificate validation at each receiving route. A working web certificate on mta-sts.example.com does not establish that the MX server presents a valid SMTP certificate.
Review available TLS reports and controlled delivery evidence. Sending services differ in participation, so silence does not establish universal success. Keep the reporter, interval and affected MX with every observation.
In a synthetic case, a policy permits only the main gateway while DNS also advertises a backup MX. The backup accepts mail in ordinary tests but fails the policy match. Repair the policy or routing design before enforcement; do not dismiss the backup because its daily volume is small.
Plan enforcement and recovery around caches
References: RFC 8461 §5, RFC 8461 §8.3.
Enforce mode can prevent supporting senders from delivering through a non-compliant connection. Non-supporting senders are outside that assurance. Record the dependency and acceptable operational response before changing mode.
Sender caches can retain valid earlier policies for their max_age. Deleting discovery DNS or taking down the HTTPS endpoint is not an immediate global rollback. For withdrawal, publish a valid mode: none policy with a short lifetime, then update the discovery id. Keep both endpoints available until all earlier policies have expired, including older revisions with longer lifetimes. Count each lifetime from when that revision was last served, not merely from the next edit.
For a gateway migration, make the policy compatible with the planned transition, verify the new route and allow for cached versions. Keep the policy endpoint available while relevant senders may still rely on it.
The handover should join MX configuration, policy history, certificate ownership and report handling. MTA-STS stays useful when those moving parts are maintained together.