What is the content-type for an MTA-STS policy file?

When you're setting up MTA-STS (Mail Transfer Agent Strict Transport Security), every detail matters. One of the most common points of failure I see is an incorrectly configured policy file. The specific question of the correct Content-Type header is crucial. The correct Content-Type for an MTA-STS policy file is text/plain.

While text/plain is the fundamental requirement, it's also best practice to include the character set. Therefore, the most complete and robust value for the header is text/plain; charset=utf-8. This requirement is outlined in the official MTA-STS specification, RFC 8461, which defines how mail servers can declare their ability to receive TLS-secured connections.

Suped DMARC monitor

Free forever, no credit card required

Get started for free

Trusted by teams securing millions of inboxes

The Content-Type header is not just a suggestion; it's a mandatory part of the policy discovery process. When a sending mail server finds your MTA-STS DNS record, it attempts to fetch your policy file from a specific URL. The web server hosting this file must return it with the correct HTTP header so the sending server knows how to interpret the file's contents.

DMARCwise says:

Visit website

The MTA-STS policy file must be served via HTTPS on the mta-sts subdomain... The file must be served with a Content-Type response header of text/plain.

If the header is missing or incorrect (for example, if your server returns application/octet-stream), the sending server will likely fail to process the policy. This can lead to fetch errors and render your entire MTA-STS configuration useless, as external mail servers won't be able to retrieve and cache your security policy.

Medium says:

Visit website

Microsoft kept giving us an “StsPolicyFetchError” until we realised that we needed to send a Content-Type “text/plain; charset=utf-8” in the...

Ensuring the correct Content-Type is part of the broader MTA-STS setup process. The configuration depends on how you host your policy file, whether it's on a traditional web server like Nginx or a cloud service like AWS S3 or Cloudflare Pages.

• Create the policy file: First, create a plain text file named mta-sts.txt. This file contains key-value pairs that define your policy, such as the version, mode (e.g., enforce or testing), your MX records, and a max_age value.
• Host the file: Upload the file and make it available via HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. This is a standardized path that sending servers know to check.
• Set the header: This is the critical step. In your web server or hosting service's configuration, you must specify that any request for /.well-known/mta-sts.txt should be served with the Content-Type: text/plain response header.
• Publish DNS records:Finally, publish the corresponding TXT record in your DNS at _mta-sts.yourdomain.com to activate the policy and signal to the world that you support MTA-STS.

Once configured, it is a good idea to test that everything is working as expected. You can often do this by simply using your web browser or a command-line tool like curl to check the response headers of your policy file.

SANS Internet Storm Center says:

Visit website

Test that the policy can be retrieved and it should be returned with a Content-Type of "text/plain".

Getting the Content-Type right is a simple but non-negotiable step for a successful MTA-STS implementation. It ensures your policy is discoverable and enforceable, which is fundamental for protecting your domain's email traffic against interception and downgrade attacks.