What is the primary requirement for hosting an MTA-STS policy file?

The primary requirement is that the MTA-STS policy file must be accessible over HTTPS at a specific URL, https://mta-sts.yourdomain.com/.well-known/mta-sts.txt , and secured with a valid TLS certificate.

Can I use existing web hosting for my MTA-STS policy?

Yes, you can use existing web hosting, cloud storage, or a CDN, as long as it supports HTTPS for the mta-sts subdomain and can serve the policy file at the correct path.

Do I need a separate TLS certificate for the MTA-STS subdomain?

You need a TLS certificate that is valid for the mta-sts.yourdomain.com subdomain. This can be a separate certificate or a wildcard certificate that covers the subdomain.

What happens if my MTA-STS policy file isn't found or is insecure?

If the policy file is not found or is served insecurely (e.g., without a valid TLS certificate), sending mail servers will either ignore your MTA-STS policy or treat it as if no policy exists, potentially leaving your inbound email vulnerable to attacks. Regular monitoring can help you detect and verify MTA-STS issues .

Does MTA-STS require a dedicated server for its policy file? - MTA-STS - Email authentication - Knowledge base

An illustration of a server rack with email envelopes, a magnifying glass checking a policy file.

When implementing MTA-STS (Mail Transfer Agent Strict Transport Security), a common question that arises is whether a dedicated server is necessary to host the policy file. MTA-STS is a critical email security standard designed to enforce TLS encryption for SMTP connections, preventing downgrade attacks and man-in-the-middle attacks. It relies on a policy file, which essentially tells sending mail servers how to securely connect to your domain's receiving mail servers.

The core requirement for the MTA-STS policy file is that it must be served securely over HTTPS from a specific subdomain. This means that while you don't necessarily need an entirely separate physical server, you do need an environment capable of hosting a web server that meets these security criteria. The policy is fetched by sending mail servers, so its availability and integrity are paramount to the effectiveness of MTA-STS.

The primary goal is to ensure the policy file is always accessible, correctly formatted, and protected by a valid SSL/TLS certificate issued for the specific MTA-STS subdomain. Understanding these requirements will help determine the best hosting solution for your organization, whether it involves existing infrastructure or exploring new options.

Understanding MTA-STS policy hosting requirements

MTA-STS policies are served via a well-known URL at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. This means that any server hosting the policy must respond to HTTPS requests on port 443 for the subdomain mta-sts.yourdomain.com. The file itself is a plain text file, and you can learn more about what is the format of the MTA-STS policy file in our knowledge base. This setup is crucial for mail servers, like those managed by Google, to reliably discover and enforce your security policy.

The primary security aspect lies in the TLS certificate used. It must be valid and trusted by common certificate authorities, and it must cover the mta-sts subdomain. This is essential because the HTTPS connection ensures that the policy file has not been tampered with during transit, protecting against attackers trying to inject a malicious policy. The specific directory path for the MTA-STS policy file also contributes to its discoverability.

Key requirements for MTA-STS hosting

HTTPS enabled: The policy file must be accessible via HTTPS on port 443.
Specific subdomain: Hosted on mta-sts.yourdomain.com.
Valid TLS certificate: The certificate must be valid for the mta-sts subdomain.
Correct path: The file must be located at /.well-known/mta-sts.txt.

The question of a dedicated server then becomes less about physical hardware and more about meeting these technical requirements. A dedicated server could certainly meet them, but it's not the only, or necessarily the most efficient, solution. We'll explore alternatives in the following sections.

Dedicated versus shared hosting solutions

A dedicated server isn't strictly required for hosting your MTA-STS policy file. Many organizations successfully deploy MTA-STS using existing web infrastructure or cloud-based hosting solutions. The key is that the hosting environment must support HTTPS for the specific subdomain and be highly available. For example, you could leverage a content delivery network (CDN) or a shared web hosting service, provided it allows you to configure the necessary subdomain, SSL/TLS certificate, and file path.

Dedicated server approach

Control: Full control over server configuration and security.
Resources: Dedicated resources for performance and reliability.
Complexity: Requires more technical expertise to set up and maintain.
Cost: Generally higher cost compared to shared or cloud options.

Shared or cloud hosting alternatives

Simplicity: Easier setup and lower maintenance overhead.
Scalability: Scales easily with traffic demands.
Integration: Can integrate with existing web services.
Cost: Often more cost-effective for policy file hosting.

The choice often comes down to your existing infrastructure, budget, and technical expertise. For many, utilizing an existing web server that can host a static file, or a cloud storage solution configured to serve content over HTTPS, is a perfectly viable and cost-effective approach. What matters is adhering to the protocol, not the underlying hardware.

Example MTA-STS policy filetext

version: STSv1
mode: enforce
mx: mail.yourdomain.com
mx: *.yourdomain.com
max_age: 604800

Setting up DNS and TLS for MTA-STS

Beyond the server itself, correct DNS configuration is paramount. You need a DNS TXT record for _mta-sts.yourdomain.com that announces the presence of an MTA-STS policy. This record contains a version identifier and a policy ID. It's how sending MTAs discover that your domain supports MTA-STS and where to find its policy. This is distinct from what DNS record type is used for other authentication protocols.

An illustration of a hand adjusting DNS records with an SSL certificate icon.

The TLS certificate for your mta-sts subdomain needs to be current and valid. Many services offer free TLS certificates, such as Let's Encrypt, which can be easily integrated into most web hosting setups. This ensures the communication between the sending mail server and your policy host is encrypted and authenticated. You might also be interested in what port MTA-STS typically uses for policy fetching.

Component	Requirement	Example
DNS TXT Record	Named _mta-sts.yourdomain.com, specifies version and ID.	v=STSv1; id=20230101000000;
Web Server Hostname	Must serve HTTPS for mta-sts.yourdomain.com.	mta-sts.yourdomain.com
Policy File Path	Fixed path /.well-known/mta-sts.txt.	https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
TLS Certificate	Valid for mta-sts.yourdomain.com, trusted by CAs.	SSL/TLS cert from Let's Encrypt

You also need to understand what is the file name for an MTA-STS policy to ensure proper configuration. The integration of DNS and TLS is what makes MTA-STS a robust security mechanism, independent of whether the server is dedicated or shared. It's the adherence to these standards that provides the security, not the specific hosting model.

Verifying your MTA-STS implementation

Once you've set up your MTA-STS policy file and DNS records, it's crucial to verify that everything is working as intended. Sending mail servers will periodically check your DNS TXT record and then attempt to fetch the policy file over HTTPS. If any part of this process fails, such as an invalid TLS certificate or an inaccessible policy file, MTA-STS will not be enforced, leaving your email traffic vulnerable.

DNS TXT record: Confirm that the _mta-sts DNS TXT record is correctly published and resolvable. You can check this using standard DNS lookup tools.
HTTPS accessibility: Verify that your policy file is accessible via HTTPS at the specified URL: https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. Ensure it returns an HTTP 200 OK status.
TLS certificate validity: Check that the SSL/TLS certificate for mta-sts.yourdomain.com is valid, unexpired, and correctly configured. There are numerous online tools to check SSL certificates.
Policy content: Ensure the policy file contains the correct version, mode, MX records, and max_age directives.

Automated monitoring is highly recommended to stay on top of MTA-STS compliance. Platforms like Suped provide robust DMARC monitoring and can help you detect and verify MTA-STS policy changes, ensuring continuous email security. Suped's AI-powered recommendations and real-time alerts simplify the process of fixing issues and strengthening your policy, making it an invaluable tool for anyone managing email security. We offer the most generous free plan available for DMARC reporting and monitoring.

Conclusion

To summarize, MTA-STS does not explicitly require a dedicated server for its policy file. The critical factors are that the policy file must be: hosted over HTTPS on the mta-sts.yourdomain.com subdomain, protected by a valid SSL/TLS certificate, and accessible at the standard /.well-known/mta-sts.txt path. Any web server environment capable of meeting these technical specifications, whether it's a shared hosting plan, a cloud storage service, or existing infrastructure, can successfully host the policy.

The focus should be on the proper configuration of the DNS TXT record, the secure hosting of the policy file via HTTPS, and continuous monitoring to ensure compliance and prevent service disruptions. By adhering to these standards, you can effectively implement MTA-STS and significantly enhance the security of your inbound email traffic.