Mail Transfer Agent Strict Transport Security (MTA-STS) is a security standard that helps protect email from interception and man-in-the-middle attacks. It does this by allowing a domain to declare that it will only accept emails over a secure, encrypted TLS connection. If a secure connection can't be established, the sending server won't deliver the email, preventing potential downgrade attacks where an attacker forces a connection to switch from secure to insecure.
The short answer is yes. The MTA-STS standard, as defined in RFC 8461, explicitly allows for the use of wildcards in the MX patterns listed within the MTA-STS policy file. This means you can specify a pattern like *.example.com to match multiple mail servers without having to list each one individually.
How do wildcards work in an MTA-STS policy?
Your MTA-STS policy is a simple text file hosted on a specific subdomain. Within this file, you define several key-value pairs. The mx key is where you list the hostnames of your mail servers. This is also where you can use a wildcard. A wildcard must be in the form of a leading label, like '*.'.
For example, if your domain uses Microsoft 365 for email, your MX record might look something like yourdomain-com.mail.protection.outlook.com. Instead of listing this exact hostname, you could use a wildcard in your MTA-STS policy to match it and other potential mail servers at Microsoft:
mx: *.mail.protection.outlook.com
This simplifies configuration, especially for organizations that manage many domains all pointing to the same email service provider.
Should you use wildcard MX records in your policy?
While wildcards are permitted, their use is a point of discussion. Some security professionals advise against them. The main argument is that being more specific is always better for security. A wildcard could potentially match unintended or future mail servers that you may not want to authorize.
However, using wildcards is often a practical necessity. Major email providers like Google and Microsoft use a wide array of MX hosts, and these can change without notice. Using a wildcard provided by them is often the only sustainable way to implement MTA-STS without constant manual updates.
Here's a summary of the considerations:
- Simplicity: Wildcards significantly simplify the policy file, especially when using a large third-party email provider.
- Maintenance: You avoid the need to update your policy every time your provider adds or changes a mail server hostname.
- Specificity: The downside is a loss of specificity. You are trusting the entire subdomain of your provider, which is generally safe but less precise than listing exact hostnames.
Ultimately, the decision comes down to balancing security with practicality. For most businesses using a major email service, following the provider's recommendation, which often includes a wildcard, is the most sensible approach. If you manage your own mail servers with static hostnames, using explicit names is the more secure choice.
Does MTA-STS work with any TLS certificate?
Does MTA-STS require a specific root certificate authority?
Does MTA-STS validate the MX records of a domain?
Does MTA-STS rely on a specific DNS record name for discovery?
What is the purpose of the MTA-STS 'mx' rule?
Does MTA-STS affect DNS records for email?
