The short answer is yes, but not in the way you might think. MTA-STS doesn't validate that your MX records are simply "correct" on their own. Instead, it validates that the mail server a sending server is trying to deliver to is one that you have explicitly authorized in your MTA-STS policy file. It’s a crucial distinction and a core part of how MTA-STS secures your inbound email.
MTA-STS (Mail Transfer Agent Strict Transport Security) is a security standard designed to protect your email from man-in-the-middle and downgrade attacks. It essentially allows a domain to declare that it will only accept email over an encrypted TLS connection. This prevents an attacker from intercepting an SMTP connection and forcing it to be unencrypted, where they could read or manipulate the email's contents.
How the validation process works
When a mail server wants to send an email to your domain, it follows a specific set of steps to check for and apply your MTA-STS policy. The process starts, as always, with a DNS lookup for your domain's MX records to find out where to send the email. But then it adds a few extra steps.
This check involves looking for a special TXT record at _mta-sts.yourdomain.com. If that record exists, it points the sending server to a web-hosted policy file. This policy file is a simple text file that contains the rules for your domain, including the mode (testing or enforce) and a list of your authorized mail server hostnames.
- The sending server gets your domain's MX records.
- It also looks for and retrieves your MTA-STS policy from the web.
- The server then compares the hostname from the MX record to the list of authorized hostnames in your policy file.
- If the MX record's hostname matches an entry in the policy, the sender will attempt a secure TLS connection. It also validates that the server's certificate is valid and matches the hostname.
- If there is no match and your policy is in enforce mode, the email will not be delivered.
The validation is a cross-reference
So, MTA-STS validation isn't about checking if your MX records exist or are syntactically correct. It’s about performing a cross-reference check. Your MTA-STS policy acts as an independent allowlist for your mail servers. This ensures that even if an attacker could somehow manipulate the DNS response a sender receives for your MX records, they can't redirect your email to a malicious server because that server's hostname won't be listed in your policy file.
This direct link between the policy and the MX records is what gives MTA-STS its strength. However, it also means you must be careful. If you migrate your email service to a new provider, you will get new MX records. You must update your MTA-STS policy file to include these new hostnames *before* you change your MX records in DNS. If you don't, sending servers that have your old policy cached will see a mismatch and refuse to deliver your mail, causing a service outage.
What if a mismatch occurs?
The outcome of a mismatch depends on the mode set in your policy. MTA-STS has two primary modes:
Testing (mode: testing): In this mode, sending servers will still perform the validation check, but they won't block email delivery if it fails. Instead, they will send a report (if you have TLS-RPT configured) detailing the failure. This is ideal when first setting up MTA-STS, as it allows you to identify any configuration issues without impacting mail flow.
Enforce (mode: enforce): Once you are confident in your configuration, you switch to enforce mode. Now, if a sending server finds that the MX record points to a host not in your policy, or if a secure TLS connection cannot be established with an authorized server, the email will not be delivered. This is where the real security benefit lies.
In conclusion, MTA-STS absolutely uses and validates your MX records, just not for their own sake. It validates them against a secure, out-of-band policy that you control. This provides a powerful mechanism to ensure that your inbound emails are always encrypted and always delivered to the mail servers you have explicitly authorized.
