When you're looking to implement MTA-STS (Mail Transfer Agent Strict Transport Security) to enhance your email security, understanding the correct policy filename and its placement is crucial. This security standard helps ensure that your emails are always sent over a secure, encrypted connection (TLS) and prevents downgrade attacks or man-in-the-middle attacks.
MTA-STS works by allowing your domain to declare that email servers sending mail to it must use a secure connection. If an incoming mail server tries to connect without TLS, or with a certificate that doesn't match your policy, the connection will be rejected or handled according to your defined policy. This significantly improves the reliability and privacy of your email communications, complementing other authentication standards like DMARC, SPF, and DKIM.
Getting the setup right, including the policy file, is key to successful deployment. A misconfigured MTA-STS policy can lead to email delivery issues, preventing legitimate emails from reaching your inbox. Therefore, precise adherence to the specification for naming and hosting the policy file is essential.
The standard filename for MTA-STS policy
The standard filename for MTA-STS policy
The filename for an MTA-STS policy is strictly defined by the standard to ensure consistent discovery by sending mail servers. It must always be mta-sts.txt. There are no variations or alternative names allowed for this file. This specific naming convention is crucial for the mechanism to function correctly, enabling sending mail servers to reliably locate and retrieve your domain's policy.
The file itself is a plain text file containing a set of key/value pairs that define your domain's MTA-STS policy. These pairs specify details like the protocol version, the policy mode (enforce, testing, or none), the maximum age of the policy, and the MX hosts allowed to receive mail for your domain. You can learn more about the format of the MTA-STS policy file for a deeper understanding.
Incorrectly naming this file, even by a single character or case difference, will cause sending mail servers to fail in retrieving your policy. This would lead to them either falling back to unencrypted delivery or rejecting mail, depending on your domain's DNS TXT record configuration. It's a precise system that requires strict adherence to the naming convention.
Where the policy file is located
Where the policy file is located
Beyond the filename itself, the location where this mta-sts.txt file is hosted is equally important. The MTA-STS policy file must be published on a web server over HTTPS at a very specific, well-known URI. This URI follows the structure: https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. The .well-known directory is a standard specified by RFC 8615 for host-specific metadata.
This means you need to create a subdomain, mta-sts.yourdomain.com, and ensure it has a valid TLS certificate. The policy file itself then resides within the .well-known directory on that subdomain. Proper configuration of this directory path is crucial for policy discovery. You can read more about the directory path for the MTA-STS policy file.
The URL must be accessible via HTTPS, which means a valid TLS certificate is required for the mta-sts.yourdomain.com subdomain. This is a critical security requirement, as it ensures the integrity and authenticity of the policy file itself.
Google provides excellent documentation on how to create an MTA-STS policy, including details on the policy filename and its specific location requirements. This resource from Google support offers a practical guide to setting up your policy correctly.
How policy discovery works
How policy discovery works
The discovery of your MTA-STS policy involves a two-step process: first, a DNS TXT record check, and then an HTTPS fetch. Sending mail servers (like Microsoft's mail flow enhancements) will query for a specific TXT record in your DNS for _mta-sts.yourdomain.com. This TXT record indicates that your domain supports MTA-STS and includes an id field that serves as a version identifier for your policy.
Once the TXT record is found and indicates MTA-STS support, the sending server then attempts to fetch the mta-sts.txt file from the https://mta-sts.yourdomain.com/.well-known/mta-sts.txt URL. The id value from the DNS record is used to determine if the retrieved policy is the latest version. If there's a mismatch or if the file cannot be retrieved, the policy fetch will fail. It's important to understand what happens if an MTA-STS policy file is not found.
DNS TXT record
Purpose: Advertises MTA-STS support and contains a version ID.
Location: Published at _mta-sts.yourdomain.com using the TXT record type. You can find more details on the DNS record type for policy discovery.
Content:v=STSv1; id=20240101000000;. The version field is critical.
HTTPS policy file
Purpose: Defines the actual MTA-STS policy with rules for secure connections.
Location: Hosted on a web server at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. It requires HTTPS for policy retrieval.
Content: Plain text with version, mode, mx, and max_age fields. The file needs a specific content-type for correct processing.
This two-part discovery mechanism ensures both efficiency and security. The DNS TXT record provides a quick signal about MTA-STS support and policy updates, while the HTTPS-served policy file guarantees the policy's integrity and confidentiality during retrieval. You don't necessarily need a dedicated server for your policy file, but it must be properly hosted and accessible.
Maintaining and updating your policy
Maintaining and updating your policy
Regular maintenance of your MTA-STS policy is as important as its initial setup. Every time you make a change to your mail servers (MX records) or wish to modify your MTA-STS policy settings (like updating the mode from testing to enforce), you must update both the mta-sts.txt file and its corresponding id in the DNS TXT record. This ensures that sending servers recognize the policy has been updated and fetch the new version.
Failing to update the id in the DNS TXT record after changing the mta-sts.txt file will result in sending mail servers continuing to use your old, potentially outdated, policy. This can compromise security or cause mail flow disruptions if your MX records have changed. Monitoring these changes is an important part of email deliverability. You can detect and verify MTA-STS policy changes.
Action
Required updates
Change MX records
Update mx fields in mta-sts.txt, increment id in DNS TXT record.
Change policy mode
Update mode field in mta-sts.txt, increment id in DNS TXT record.
The max_age field in your mta-sts.txt policy also plays a role in how quickly changes are propagated. This value specifies how long sending mail servers should cache your policy. A shorter max_age means changes will be picked up more quickly, which is useful during initial deployment or troubleshooting. Conversely, a longer max_age reduces the frequency of policy fetches, improving efficiency for stable policies.
The importance of correct setup
The importance of correct setup
Ensuring the correct filename and hosting location for your MTA-STS policy file is fundamental to the entire mechanism. Without this precision, other domains attempting to send you email cannot verify your secure mail transfer requirements. This leaves your inbound email vulnerable to passive eavesdropping and active attacks where an attacker might try to intercept or tamper with messages by downgrading the connection to an unsecured one.
Furthermore, misconfiguration can have severe consequences for email deliverability. If sending servers cannot find or validate your MTA-STS policy, they might default to rejecting your emails if they cannot establish a secure connection that meets their expectations. This is especially true if your policy is in enforce mode. Therefore, testing your policy thoroughly in testing mode before moving to enforce is a best practice.
Tools like Suped can help you monitor your email authentication, including MTA-STS, alongside DMARC, SPF, and DKIM. Our platform provides real-time alerts and AI-powered recommendations to ensure your policies are correctly implemented and maintained, helping you avoid deliverability issues and maintain robust email security. We make MTA-STS accessible to everyone, from SMBs to large enterprises.
Conclusion
Conclusion
The filename for an MTA-STS policy is strictly mta-sts.txt, and it must be hosted at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. Adhering to these precise specifications is critical for the effective implementation of MTA-STS, ensuring your inbound emails benefit from enhanced transport security and maintain optimal deliverability.
By correctly configuring and regularly updating your MTA-STS policy, you are taking a significant step towards a more secure email ecosystem. This protects your domain from common email attack vectors and reinforces trust with your senders and recipients. Always double-check your setup, especially the filename and path, to prevent any unforeseen deliverability or security issues.