Policies - MTA-STS Overview

Updated November 14, 2025 15:52

This article contains information on Mail Transfer Agent Strict Transport Security (MTA-STS), explaining its role in securing email communication by enforcing TLS encryption, preventing downgrade attacks, and ensuring secure connections between mail servers.

What is MTA-STS?

MTA-STS establishes a standardized mechanism to promote secure communication between mail servers, enhancing the overall confidentiality and integrity of email exchanges.

MTA-STS is a protocol that enhances the security of email communications by enforcing secure and encrypted transport of emails between email gateways. Implementing MTA-STS can help mitigate the risk of man-in-the-middle attacks and unauthorized access to email content during transmission.

Through implementing MTA-STS email domain owners can specify that communication with their email servers should only happen over secure and authenticated channels, i.e. TLS enforcement. Mimecast Cloud Gateway (Secure Email Gateway) supports the MTA Strict Transport Security (MTA-STS) protocol.

Support for MTA-STS (Mail Transfer Agent Strict Transport Security)

Email Security Cloud Gateway provides support for MTA-STS (Mail Transfer Agent Strict Transport Security) in broad alignment with internet standard IETF RFC 8461 (https://datatracker.ietf.org/doc/html/rfc8461). Where Email Security, Cloud Gateway sends outbound emails to a recipient domain with a valid MTA-STS policy, the email delivery will be considered against the requirements of that MTA-STS policy and delivered as appropriate. For the outbound email from Mimecast Email Security Cloud Gateway, to consider and apply the recipient's MTA-STS policy, a configuration option is provided in the Secure Delivery definition; details can be found in the following article: Email Security Cloud Gateway - Secure Delivery Configuration.

Support for TLS Reports

In addition, Email Security Cloud Gateway provides automated daily TLS Reports (TLSRPT) in broad alignment with internet standard IETF RFC 8460 (https://datatracker.ietf.org/doc/html/rfc8460). Both MAILTO and HTTPS transport methods are supported. Mimecast will send these reports to the recipient domain, even though that recipient may not be a Mimecast Email Security Cloud Gateway customer. As defined by the RFC, these reports provide to the recipient domain information that the sending domain has gathered, such as the MTA-STS policies, the number of emails sent via an MTA-STS policy, the number of successful deliveries, and, importantly, the transmission failures along with a failure reason.
Recipient domains can then use this information for several purposes, including the detection of potential attacks as well as the analysis, review, and correction of unintended misconfiguration(s). Mimecast makes reasonable efforts to respect the RFCs identified above, and TLS Reports are provided on an 'as is' basis. No warranties or representations of any kind, express or implied, are given regarding the provided information's nature, accuracy, suitability, or otherwise. For more information, please see our website.

Pre-requisites & Requirements

HTTPS-enabled Web Server to host a file.
- Ability to create DNS Records.
- Email address or TLS Report Analysis tool to receive & process TLS Reports.
- Access to your Mimecast Administration Console to update Policies & Definitions.

MTA-STS Implementation Guide

The MTA-STS Implementation follows these high-level steps/milestones.

Note: Not every Secure Email Gateway or Email Service Provider supports MTA-STS and it is recommended to take a phased approach to the implementation of MTA-STS to minimize the risk of email delivery failures.

1. Identify the Domains you Wish to Protect

We recommend all domains & sub-domains that receive inbound emails should be considered in scope. Tip: Internal Domains in the Administration Console provides a consolidated list of all your domains protected by Mimecast. Each domain and sub-domain will require its own configuration. It can be useful, in complex or multi-domain environments to document the domains and phases by referring to the below example.

Internal Domain	MX Records	Policy File	DNS Records		TLS-RPT Recipient
Internal Domain	MX Records	Policy File	MTA-STS	TLS-RPT	TLS-RPT Recipient
example.com	Eu-smtp-inbound-1.mimecast.com Eu-smtp-inbound-2.mimecast.com	Generated ~~Published~~			tlsreports@example.com
info.example.com	Eu-smtp-inbound-1.mimecast.com Eu-smtp-inbound-2.mimecast.com App-X.info.example.com				tlsreports@example.com

2. Confirm all of your Email Servers Support TLS1.2 & Valid Certificates

Note: all Mimecast mail transfer agents (MTA's) support TLS1.2+ and Mimecast manages the certificates.

MTA-STS requires a minimum TLS version of 1.2. It is good practice to check that all of the MTAs that receive emails for your domains support TLS1.2 or higher. You can do this by using a TLS Checking tool like CheckTLS. If you find email servers that do not support TLS version 1.2 or higher you should exclude these from your policy file or consider updating the systems to support the required TLS version.

The following table provides an example of documenting the email servers, supported TLS versions, and policy decisions made as a result:

Internal Domain	MX Record	TLS 1.2	Cert	Action
example.com	eu-smtp-inbound-1.mimecast.com	Y	Y
example.com	eu-smtp-inbound-2.mimecast.com	Y	Y
subdomain.example.com	eu-smtp-inbound-1.mimecast.com	Y	Y
info.example.com	eu-smtp-inbound-2.mimecast.com	Y	Y
info.example.com	app-x.info.example.com	X	Y	Exclude from Policy

MTA-STS-enforced TLS will fail if a valid Publicly Trusted Certificate is not presented by the receiving MTA. You should confirm all of your receiving e-mail servers have a valid certificate installed (signed by a trusted third-party CA) and that you have a good process in place to renew certificates before they expire for any systems that you manage.

NOTE: Self-signed certificates (not signed by a trusted third-party CA) are not considered trusted and receiving e-mail servers wishing to validate the https:// published MTA-STS record will fail.

3. Create & Publish your MTA-STS Policy in Testing Mode

The MTA-STS policy is contained and published in a TXT file that's hosted on a web server at a well-known URI.

Option	Supported Values	Notes
version	STSv1	Required. Must be the first line. STSv1 is the only currently available and supported value.
mode	none testing enforce	none = Treat domain as if it has no active policy. testing = Use MTA-STS, Permit fall-back to plain text, Report on Failures if a TLS-RPT record is configured. enforce = Sending MTA's MUST NOT deliver email to hosts that fail MX Record Matching or Certificate Validation or do not support STARTTLS
mx	mx.example.com *.example.com	List the receiving email servers that are in scope. One line per server. Wildcards are supported.
max_age	0 – 31557600	Time in seconds to cache policy since last policy fetch time.

Testing MTA-STS Policy file Example

The following is an example of a policy file for a domain that uses Mimecast's UK Geographic region to protect their email as denoted by the 2 x mx: records listed:

Filename:

mta-sts.txt

File Contents:

version: STSv1

mode: testing

mx: eu-smtp-inbound-1.mimecast.com

mx: eu-smtp-inbound-2.mimecast.com

max_age: 86400

Note: To mitigate the risks of attacks at policy refresh time, it is expected that the max_age value typically be in the range of weeks or greater. Many organizations will choose to start with a lower max_age value and increase it as they progress through the implementation of MTA-STS, for example;

max_age value	Policy Cache Duration	Notes
86400	24 hours	Ideal during initial implementations or migrations where you're likely to want or need to adjust/update the policy file. Typical Modes: None / Testing
604800	7 days	Policy in place, stable operations with potential for some adjustment. Typical modes: Testing / Enforce
1814400	21 days	Stable operations Typical modes: Enforce

Publish the Policy File

The policy file must be publicly accessible over HTTPS at a "well-known" location so it will require a web server with a valid and trusted 3rd party certificate. The URL for the published file must match the following format where you replace the http://example.com portion with the domain name you are configuringMTA-STS for https://mta-sts.example.com/.well-known/mta-sts.txt

Note: The MTA-STS RFC 8461 states that if the MTA-STS policy file is not available when checked then the sending MTA should continue to deliver email as if no MTA-STS configuration exists.

It is possible to publish the mta-sts.txt policy file on multiple web servers to increase resiliency. You can do this by publishing multiple Host (A & AAAA) records pointing to the respective IP addresses of the systems hosting the files. This can also be managed by using a CDN (content distribution network).

Create the MTA-STS Discovery Record

A DNS TXT record is used to advertise that your domain names have MTA-STS policy file configured and that sending MTAs should look for the corresponding policy file. This DNS TXT record is called the MTA-STS policy discovery record. The MTA-STS policy discovery record must use the subdomain: _mta-sts.example.com whereexample.com is the domain that you are configuring MTA-STS on. The TXT value of the record MUST contain the following 2 properties separated by a semi-colon;

v=STSv1

Defines MTA-STS version being used.

STSv1 is the only value currently available and supported.

id=2023dec30cr1234

An alpha-numeric value of up to 32 characters, it must be unique and you must change it every time you update the policy file.

Picking something simple, such as a date & change request ticket number, can make managing this versioning easier.

Using the following example the resulting TXT record would be:

Record Type	Name	Value
TXT	_mta-sts.example.com	v=STSv1; id=2023dec30cr1234

4. Set up TLS Reporting (TLS-RPT) and Start Monitoring

TLS-RPT is a mechanism to instruct sending e-mail servers to generate and send the domain owners TLS reports that could be potential security or configuration issues relating to TLS for a specific domain. TLS Reports may include information about failed connection attempts or insecure cipher suites. Monitoring the TLS Reports for your domains will help identify when you're ready to progress through the implementation of MTA-STS, e.g. updating your MTA-STS Policy file from 'testing' mode to 'enforce'. (It is recommended to use a tool to analyze TLS Reports over trying to interpret the raw reports manually.) TLS Reports will usually be delivered to an SMTP e-mail address this could be an address you have created and managed or one provided by a TLS Report Analysis tool of your choosing. A DNS TXT Record is used to advertise that your domain is TLS-RTP enabled and also the endpoint or SMTP e-mail address the reports should be delivered. The TLS-RPT DNS Record must be named _smtp._tls.example.com.com where example.com is the email domain for which you are enabling TLS Reporting.

The TXT value of the record MUST contain the following 2 properties separated by a semi-colon;

v=TLSRPTv1

Defines the version of TLSRPT being used.

TLSRPTv1 is currently the only supported value.

rua=mailto:tls-reports@example.com

Where tls-reports@example.com is the email address provided by the selected tool or a dedicated or shared mailbox that you set up to receive the reports.

Using the following example the resulting TXT record would be:

Record Type	Name	Value
TXT	_smtp._tls.example.com	v=TLSRPTv1; rua=mailto:tls-reports@example.com

Note: It can take 24 hours or more for TLS Reports to start appearing in the destination mailbox or analysis tool. This is normal as many systems will be configured to collect reports over a period and send an aggregate of the results for that period.

5. Enable Outbound MTA-STS in your Mimecast Secure Delivery Definitions

To enable MTA-STS on outbound email you should create (or update) the Secure Delivery Definition in your Mimecast Account, details can be found in the following article Email Security Cloud Gateway - Secure Delivery Configuration.

6. Upgrade your MTA-STS policy to Enforce Mode

You are now ready to consider moving to MTA-STS Enforce Mode, which means that inbound email will not be delivered if the connection does not support TLS1.2 or higher or a valid certificate is not presented. Before moving to enforce mode, you should review the TLS-Report information that has been collected during the period in which you had a testing mode policy in place to check there is no misconfiguration. Any misconfiguration detected should be resolved before progressing the policy to enforce mode. Generally, at least 4-6 weeks of testing mode data should be considered before updating your policy file though you may opt to take a bit more time for your organization to ensure e-mail delivered less frequently (e.g. quarterly or annually) is considered. To update your policy file to enforce you should edit your policy file to change the mode to enforce and increase the maximum age value to a value of several weeks, in the example we use 3 weeks. Once the updated policy file is published you must remember to update the id attribute in the MTA-STS Discovery TXT Record.

Enforce MTA-STS Policy file Example

The following is an example of a policy file for a domain that uses Mimecast's UK Geographic region to protect their email as denoted by the 2 MX records listed.