MTA-STS Lifecycle Management Guidance
Implementing a strict Mail Transport Agent Strict Transport Security (MTA-STS) policy is crucial for safeguarding the security and integrity of your organisation's inbound communications. However, a key aspect that often goes overlooked is updating the MTA-STS policy file during mail provider migration. It’s easy to side-line the importance of updating your MTA-STS policy amidst the numerous activities that come with switching from an old to a new mail server. Yet, this step is critical for maintaining secure email communications. This guide provides a structured approach to ensure a thorough understanding of the necessary steps for updating your MTA-STS policy during mail server migration, whilst maintaining an enforced policy.
Migrating Mail Servers under Mail Transport Agent Strict Transport Security (MTA-STS) Enforce: Ensuring Seamless Email Deliverability
When migrating from an ‘old’ mail-server to a ‘new’ mail-server B under an MTA-STS policy set to “enforce,” it’s crucial to maintain secure email transport without downtime. Here’s how to manage this transition while keeping your policy mode consistently at enforce.
(For the purposes of this blog; mail-server A = old and mail-server B = new. Assumption: TLS-RPT is configured and pointing to NCSC’s Mail Check)
1. Preparation Steps
a. Update your Mail Exchange (MX) Records: Add mail-server B to your DNS MX records alongside mail-server A. Initially, set mail-server B with a higher priority that ensures mail-server A continues to serve as the primary receiver of emails until the transition to B is ready.
b. Update MTA-STS Policy File: Crucially, include both mail-server A and B in your MTA-STS policy file. It’s important to highlight that the policy mode remains on “enforce” throughout this process, ensuring that email communications are securely encrypted in transit. Including both servers in the policy file ensures compliance with the enforced security standards for email delivery to both servers.
2. Implementation Steps
a. DNS Changes Propagation: Allow time for the updated MX records to propagate fully. This ensures that email senders worldwide recognise both mail-server A and B as valid recipients under your domain’s enforced MTA-STS policy.
b. MTA-STS DNS Record Update: After adjusting your MTA-STS policy file, update your MTA-STS DNS TXT record by incrementing the version number (date of the change). This signals a policy update under enforcement mode, prompting sending servers to re-fetch the policy and recognise both mail servers as secure endpoints.
3. Transition Steps
a. Email Flow Monitoring: With the enforcement policy covering both servers, carefully monitor the email traffic. Ensure that mail-server B is effectively processing emails under the “enforce” mode without security or delivery issues.
b. Adjust MX Record Priority: Gradually shift priority to favour mail-server B, directing more email traffic to it while maintaining the enforcement mode. This ensures that the transition adheres to the strict security standards set by MTA-STS.
4. Final Steps
a. Continuous Monitoring: Keep a close eye on mail-server B’s performance as the primary server under the enforced policy, ensuring no disruption in secure email delivery.
b. MTA-STS Policy Final Update: Once confident in mail-server B’s capability, update the MTA-STS policy file to exclusively include mail-server B, reaffirming your commitment to enforced secure email transport.
c. DNS and MTA-STS Final Update: Remove mail-server A from the MX records and update the MTA-STS DNS record to reflect this change, with the policy still in “enforce” mode. Increment the version number to signal the final policy update.
d. Decommissioning Mail-Server A: With mail-server B now fully operational and the MTA-STS policy enforcement mode unchanged, you can safely decommission mail-server A.