MTA-STS and TLS Reporting: A Careful Rollout

If your domain already has SPF, DKIM and DMARC, the next email review may concern transport: how other mail servers protect messages while delivering them to your organisation. These are different controls. Passing a sender-authentication check does not establish that every delivery connection used authenticated encryption.

SMTP's STARTTLS extension allows a connection to be upgraded to TLS. Its specification discusses interference with that negotiation and the need for an appropriate local security policy. RFC 3207 is the protocol background for this distinction.

MTA-STS gives supporting sending servers a policy for delivery to your domain. TLS reporting supplies feedback about transport-policy outcomes. Plan both around the mail service you actually operate, including backup routes and third-party gateways.

Establish the receiving service

List every public MX hostname and who operates it. Confirm that each intended route supports the required TLS connection and presents an appropriate certificate. Include rarely used backup MX hosts: a route can look harmless until another route fails and senders start using it.

If a provider manages your mail, use its documented inbound configuration and ask who is responsible for transport-policy support. Do not copy a policy from another customer with a similar-looking domain. A filtering gateway in front of Microsoft 365 changes the receiving hosts that outside senders encounter.

Keep this inventory alongside the SPF, DKIM and DMARC configuration. They should have a common owner even though they protect different parts of mail delivery.

Collect reports before relying on enforcement

RFC 8460 defines SMTP TLS reporting and its DNS discovery record. For example, an organisation controlling example.com could publish this TXT value at _smtp._tls.example.com:

v=TLSRPTv1; rua=mailto:tls-reports@example.com

Replace the example with a destination you control and can process. Confirm the reporting service's setup requirements before using a third-party address. The reports describe aggregate success and failure information; they are not a complete inventory of every message or proof that every sender participates.

Give somebody responsibility for reviewing the reports. Check failures by receiving host and sending organisation, and retain enough history to distinguish a persistent certificate problem from a short-lived network event. A reporting mailbox that nobody reads adds administration without improving the rollout decision.

Publish a narrow testing policy

Under RFC 8461, policy discovery uses a TXT record at _mta-sts and a file served over HTTPS at https://mta-sts.example.com/.well-known/mta-sts.txt. The file identifies the permitted MX hosts, operating mode and cache lifetime. Begin in testing mode; supporting senders can report policy failures without enforcing this policy's delivery restriction.

An illustrative file for a domain with one receiving hostname is:

version: STSv1
mode: testing
mx: mail.example.com
max_age: 86400

This is an example, not a policy to paste into a live domain. Match the MX entries to the receiving service and choose the initial lifetime deliberately. Publish the required discovery record with a policy identifier, and verify the HTTPS file from outside the hosting network.

Test certificate validity, hostname matching, file accessibility and the reported policy from more than one external vantage point. Check both the policy host and the mail hosts. A valid certificate on the website does not establish that the receiving mail server is configured correctly.

Make enforcement a delivery decision

Review a representative period of normal mail activity, including important suppliers and any secondary routes. Investigate unexplained failures and check that alerts reach the people who can fix them. Agree how a delivery interruption will be handled before changing the policy to enforce and updating its discovery identifier.

Keep monitoring after enforcement. Add an MTA-STS review to any mail-provider migration, MX change or certificate change. The person changing mail routing needs to know that an existing transport policy may constrain the new destination.

Plan rollback around cached policies. Removing a DNS record does not instantly remove policy already held by senders. RFC 8461 describes a controlled policy-removal procedure, including publishing none and allowing earlier caches to expire. Keep the policy website available during that transition.

The completion criteria should be practical: the intended hosts are covered, reports are processed, known routes work, and somebody owns the policy during future changes. Record that scope clearly; MTA-STS does not turn email into end-to-end encrypted messaging or require every remote sender to support it.

References

• IETF, RFC 3207: SMTP Service Extension for Secure SMTP over TLS. Accessed 17 October 2026.
• IETF, RFC 8460: SMTP TLS Reporting. Accessed 17 October 2026.
• IETF, RFC 8461: SMTP MTA Strict Transport Security. Accessed 17 October 2026.