Mail Transfer Agent Strict Transport Security, or MTA-STS, is a crucial standard designed to secure email in transit. Its primary job is to prevent man-in-the-middle (MITM) attacks and SSL/TLS downgrade attacks during SMTP conversations. It ensures that when a sending mail server connects to a receiving mail server, the connection is encrypted with a valid and expected TLS certificate. But for this to work, the sending server must first discover and retrieve the receiving domain's MTA-STS policy. This retrieval is a well-defined sequence of steps that combines DNS lookups and HTTPS requests.
The entire process begins with the sending Mail Transfer Agent (MTA) checking for the existence of an MTA-STS policy for the recipient's domain.
The policy retrieval sequence
When a sending server that supports MTA-STS wants to send an email, it doesn't just connect to the recipient's MX record and hope for the best. Instead, it initiates a specific process to find and validate the security policy. This ensures that any subsequent communication adheres to the security standards defined by the receiving domain.
The sequence of events is as follows:
- Step 1: Check for the MTA-STS DNS record. The sending MTA performs a DNS lookup for a TXT record at _mta-sts followed by the recipient's domain. For example, for the domain example.com, it would query _mta-sts.example.com.
- Step 2: Validate the DNS record. If a TXT record is found, the MTA checks its content. It must start with v=STSv1 and contain an id tag. This ID is used to track policy updates. If no record is found, the domain does not support MTA-STS, and the email is sent without this added layer of security.
- Step 3: Fetch the policy file. With a valid DNS record confirmed, the MTA constructs a URL to fetch the actual policy file. The URL is always https://mta-sts.[domain]/.well-known/mta-sts.txt. It makes an HTTPS GET request to this URL. The connection must use a valid, trusted TLS certificate.
- Step 4: Validate the policy file. The MTA parses the downloaded text file. It checks the version (STSv1), the policy mode (enforce, testing, or none), the list of valid MX hosts, and the max_age value, which dictates how long the policy should be cached.
- Step 5: Cache the policy. If the policy is valid, the sending MTA caches it. It will use this cached policy for all subsequent emails sent to the domain for the duration specified by max_age (in seconds). This avoids having to repeat the DNS lookup and HTTPS request for every single email.
What happens after retrieval?
Once a policy is successfully retrieved and cached, the sending MTA uses it to enforce secure connections. When sending an email, it will check that the receiving server's MX record matches one of the hosts listed in the MTA-STS policy. Furthermore, it verifies that the server presents a valid TLS certificate that is not expired, is issued by a trusted certificate authority, and matches the hostname.
If the policy mode is set to enforce and any of these checks fail, the email is not delivered. Instead, it is typically queued and retried later. This strict enforcement is the core of MTA-STS, preventing emails from being intercepted or tampered with by a malicious actor forcing an insecure connection.
What is the file name for an MTA-STS policy?
What port does MTA-STS typically use for policy fetching?
What is the directory path for the MTA-STS policy file?
Does MTA-STS use SMTP or HTTPS for policy retrieval?
Does MTA-STS affect email routing decisions?
Does MTA-STS validate the MX records of a domain?
