How to detect and verify MTA-STS policy changes and locations?

Detecting and verifying MTA-STS policy changes and locations primarily involves a two-phase process: first, querying the DNS for a specific TXT record, and then retrieving a policy file via HTTPS from a well-known URL. Receiving Mail Transfer Agents (MTAs) initiating this process first check for a _mta-sts.<domain> DNS TXT record. This record contains a policy ID and points to the location where the actual policy is hosted. Subsequently, the MTA fetches the mta-sts.txt policy file from a standardized HTTPS URL, typically https://mta-sts.<domain>/.well-known/mta-sts.txt. Verification is critical, requiring validation of the HTTPS server's certificate chain against trusted roots and ensuring the hostname matches. Policy changes are reflected and detected based on the 'max_age' directive within the policy file, which specifies how long the policy can be cached before a new check is required. Both manual command-line checks using tools like 'dig' and 'curl', and automated online validation tools, simplify this complex verification process, helping administrators confirm proper implementation and quickly identify any misconfigurations or unauthorized alterations.

The detection and verification of MTA-STS policy changes build upon the foundational two-phase lookup by focusing on the active methodologies. This involves a systematic approach to confirm the integrity of both the DNS TXT record and the HTTPS-hosted policy file. Practical verification methods range from manual command-line execution, using tools like 'dig' to inspect the '_mta-sts' DNS TXT record for the policy ID and 'curl' to retrieve the 'mta-sts.txt' policy file, to leveraging specialized online validation tools. These automated tools streamline the process by performing comprehensive checks, including DNS lookups, secure retrieval of the policy file via HTTPS, validation of the TLS certificate, and parsing of the policy content to ensure correct formatting, matching IDs, and proper 'max_age' and 'mode' settings. Continuous monitoring services are also crucial, providing alerts for discrepancies or unauthorized alterations, which is vital given real-world scenarios such as Yahoo's observed transition between enforcement and testing modes.

Receiving mail servers initiate MTA-STS policy detection through a two-step process, first querying a DNS TXT record in the `_mta-sts` subdomain, then fetching the detailed policy from a specific HTTPS URL. Policy updates are managed by the `max_age` value, which dictates how long a policy is cached before a new retrieval is prompted. Verification critically relies on the secure HTTPS connection used for policy retrieval, ensuring the authenticity of the policy data. It is important to note that the policy may be hosted on the domain associated with the MX record, ensuring proper alignment for email reception.

Sending Mail Transfer Agents (MTAs) play a crucial role in detecting and verifying MTA-STS policies. This process begins with the sending MTA querying the DNS for a specific TXT record, typically `_mta-sts.<domain>`, which indicates the policy's existence and location. Following this initial DNS lookup, the MTA proceeds to fetch the actual policy file over a secure HTTPS connection from a standardized, well-known URL path, commonly `https://mta-sts.<domain>/.well-known/mta-sts.txt`. A critical step in this retrieval is the validation of the HTTPS server's TLS certificate chain against trusted root Certificate Authorities, ensuring both the authenticity of the policy source and that the hostname matches. Policy changes are primarily detected and applied based on the `max_age` directive specified within the policy file, which dictates how long sending MTAs should cache the policy before re-fetching it to check for updates. Administrators can verify their implementation using tools like Google Admin Toolbox Dig or by checking server configurations, ensuring the policy is correctly hosted and accessible.