What happens if the MTA-STS policy file is served with the wrong Content-Type?

If the MTA-STS policy file is served with an incorrect Content-Type, such as "application/octet-stream" instead of "text/plain; charset=utf-8", the receiving Mail Transfer Agent (MTA) will likely fail to parse or even retrieve the policy. This can lead to policy fetch errors, and the MTA-STS policy will be ignored, leaving your email traffic vulnerable to downgrade attacks.

Why is 'charset=utf-8' important for the MTA-STS policy Content-Type?

The 'charset=utf-8' parameter specifies the character encoding of the text file. UTF-8 is a widely used and robust encoding that supports a broad range of characters. Specifying it ensures that MTAs correctly interpret the policy file's content, preventing potential parsing errors or misinterpretations that could arise from incorrect character sets.

Can I use a different content type like 'application/json' for MTA-STS policies?

No, you cannot use "application/json" or any other content type for MTA-STS policies. The specification strictly requires "text/plain; charset=utf-8". Deviating from this will cause MTAs to reject the policy, as they are programmed to expect this specific content type to properly validate and apply your MTA-STS directives.

How can I check the Content-Type of my MTA-STS policy file?

You can check the Content-Type using command-line tools like 'curl' or through your web browser's developer tools. For example, using 'curl -I https://mta-sts.yourdomain.com/.well-known/mta-sts.txt' will show you the HTTP headers, including the Content-Type, returned by your server.

Does the MTA-STS policy file need to return an HTTP 200 status code?

Yes, the MTA-STS policy file must be served with an HTTP 200 (OK) status code . If the server returns a redirect (3xx status code) or any other error status, the policy will not be fetched or applied by sending MTAs. The file must be directly accessible at the specified URI.

What is the content-type for an MTA-STS policy file? - MTA-STS - Email authentication - Knowledge base

An illustration of secure email flow with MTA-STS protection

Mail Transfer Agent Strict Transport Security (MTA-STS) is a crucial protocol for email security, designed to prevent man-in-the-middle attacks by ensuring that all inbound emails use secure TLS connections. It relies on a policy file that outlines your domain's email security requirements. For MTA-STS to function correctly, Mail Transfer Agents (MTAs) need to fetch this policy file from a web server.

A common point of confusion and a frequent cause of policy fetch failures is the specific HTTP content type that an MTA-STS policy file must be served with. Improper configuration here can render your entire MTA-STS implementation ineffective, leaving your email traffic vulnerable to downgrade attacks.

Understanding MTA-STS policy files

The foundation of MTA-STS policy files

An MTA-STS policy file, typically named mta-sts.txt, is a plain text file that specifies rules for how other email servers should connect to yours. This file must be hosted on a web server at a specific, well-known URI: https://mta-sts.<yourdomain>/.well-known/mta-sts.txt. The content within this file dictates the version, mode, and MX records that are authorized for your domain.

Before an MTA attempts to retrieve the policy, it first checks your domain's DNS for a special TXT record that signals MTA-STS support. If this record is present and valid, the MTA proceeds to fetch the policy file via HTTPS. This process ensures that the policy itself is transported securely.

The entire interaction, from DNS lookup to policy retrieval, is designed to be automated and seamless for sending MTAs. However, this automation relies heavily on the policy file's format and its delivery being precisely as expected. Any deviation, particularly with the content type, can lead to the policy being ignored, effectively disabling your MTA-STS protection.

The critical content-type header for MTA-STS

The MTA-STS specification explicitly mandates that the policy file must be served with a specific Content-Type HTTP header. This header tells the receiving MTA how to interpret the data it's downloading. For an MTA-STS policy, the required content type is text/plain; charset=utf-8. This is critical because MTAs expect the policy to be a simple, human-readable text file encoded in UTF-8.

Required content-type

Ensure your web server serves the mta-sts.txt file with this exact Content-Type HTTP header.

MTA-STS policy content-typeHTTP Header

Content-Type: text/plain; charset=utf-8

If the web server responds with any other Content-Type, such as application/octet-stream or application/json, the receiving MTA will likely discard the policy. This is because it won't recognize the format and won't be able to parse the policy's directives correctly. This scenario often results in an "StsPolicyFetchError" or similar messages in logs, effectively nullifying your MTA-STS efforts. You can learn more about serving these files on Microsoft's documentation for MTA-STS

Serving the MTA-STS policy file correctly

Configuring your web server to deliver the correct Content-Type is usually straightforward. Most web servers, like Apache or Nginx, allow you to explicitly define content types for specific file extensions or locations. It's also crucial that the server responds with an HTTP 200 (OK) status code. Redirects (3xx status codes) are not supported for fetching the MTA-STS policy and will cause failures. This means the file must be directly accessible.

Example Nginx configuration for MTA-STS policynginx

location /.well-known/mta-sts.txt {
    add_header Content-Type "text/plain; charset=utf-8";
    return 200 "version: STSv1\nmode: enforce\nmx: mail.example.com\nmax_age: 86400";
}

After configuring your server, always test the delivery using tools like curl or a browser's developer tools to inspect the HTTP headers. Confirm that the Content-Type is correct and the status code is 200 OK. This verification step is crucial for detecting and verifying MTA-STS policy changes and preventing potential issues.

Ensuring secure email delivery with correct configuration

Properly configuring the Content-Type for your MTA-STS policy file is a small but mighty detail in the grand scheme of email security and deliverability. When correctly implemented, MTA-STS works in conjunction with other protocols like DMARC, SPF, and DKIM to form a robust defense against email spoofing and phishing attacks.

An illustration showing a web browser inspecting HTTP headers for an MTA-STS policy file, highlighting the Content-Type.

Correct content-type

Policy retrieval: MTAs successfully fetch and apply your security policy.
Enhanced security: Inbound email traffic is secured with TLS, preventing eavesdropping.
Domain reputation: Projects a trustworthy image, improving overall email trust.

Incorrect content-type

Policy ignored: MTAs cannot parse the policy, reverting to less secure options.
Security vulnerabilities: Emails may be sent over unencrypted connections, risking interception.
Troubleshooting overhead: Requires manual debugging to identify the subtle misconfiguration.

The details matter, and even a small misstep in server configuration can have significant security implications. For further reading, dmarcwise.io provides setup instructions detailing the necessity of the text/plain content type. Continuous monitoring of your MTA-STS status is essential to catch and correct these issues promptly.

Maintaining robust email security

Ensuring the correct Content-Type for your MTA-STS policy file is a fundamental step in establishing strong email security. It is a testament to how crucial technical precision is in safeguarding your email ecosystem against pervasive threats like spoofing and phishing. Overlooking such a detail can undermine your entire security posture, making your domain appear less trustworthy and potentially impacting your email deliverability (or blocklist status).

To effectively manage and monitor your email authentication protocols, including MTA-STS, a robust platform is indispensable. Suped offers a comprehensive solution for DMARC monitoring, SPF, DKIM, and deliverability insights. With AI-powered recommendations, real-time alerts, and SPF Flattening, Suped simplifies the complexities of email security, helping you fix issues and strengthen your policies with ease. Our platform is built for scale, making it ideal for MSPs and enterprises needing to manage multiple domains efficiently. Start with Suped's generous free plan today to ensure your email infrastructure remains secure and compliant.