Prolateral Consulting Ltd
Prolateral Consulting Ltd
Knowledgebase Articles
Setup examples

Prolateral offers primary and backup domain (DNS) services, with servers in key geographic locations providing the best service possible.


How do I setup MTA-STS?
How do I implement MTA-STS?
How to create a MTA_STS policy?


In this knowledge article it is assumed you already have the following working:

  • A email server solution
  • Already receiving inbound emails for your domain/s.
  • Enabled TLS/SSL for SMTP on the email server.
  • Check all those email servers for TLS 1.2 and valid certificates

MTA-STS (Mail Transfer Agent - Strict Transport Security) is an email standard that secures inbound email. With a Internet published policy it specifies the security levels (like TLS) that the inbound receiving email servers will accept.

MTA-STS in a few steps

Create a MTA-STS policy file

The MTA-STS policy is a text file that is hosted on a https web server. An example of a MTA-STS policy file is below

version: STSv1
mode: testing
max_age: 604800

See the section below on generating a policy file.


Hosting the MTA-STS policy

The policy file needs to be placed in the webroot folder called /.well-known/mta-sts.txt

The webserver must have a valid SSL certificate and support HTTPS.


Create a mta-sts record in your DNS

Add to your domain name DNS a A record which points to the webserver hosting the MTA-STS.

Your MTA-STS policy should now be visible at


Create a _mta-sts TXT record in DNS

Add to your domain name DNS a TXT record that details a valid id to indicate when the MTA-STS was last updated.


Setting up MTA-STS

Let's look in more detail in the setting up of MTA-STS

Step 1 - Create a MTA-STS policy file

Initially let's create a MTA-STS policy file in testing mode.  The policy file itself is a plain text file called "mta-sts.txt"

The file needs to you saved in a folder under the webroot called ".well-known".

An example of a MTA-STS file is below.

version: STSv1
mode: testing
max_age: 604800

Let's examine each line of the file.

version: This must be the first line and must contain the value STSv1 for this policy file to be valid. 

The mode can be one of "enforce", "testing" or "none".  The mode indicates the expected behavior of the sending MTA in the case of a policy validation failure.

Enforce - In this mode, Sending MTAs MUST NOT deliver the message to hosts that fail MX matching or certificate validation or that do not support STARTTLS.

Testing - In this mode, Sending MTAs that also implement the TLSRPT (TLS Reporting) specification send a report indicating policy application failures (but only as long as TLSRPT is setup on the recipient domain). During testing, messages may be delivered as though there was no MTA-STS in place.

None - In this mode, Sending MTAs should treat the Policy Domain as though it does not have any active policy.


One or more patterns matching allowed MX hosts for the Policy Domain.

For example you could specify

mx:  <<-- profilter
mx:  <<-- backupMX
mx:  <<-- fakeMX

or you could simplify this as

mx: * 

However you specify the mx hosts, this policy must include all the mail servers that are configured to receive emails for your domain.  Think of MTA-STS like SPF. where SPF is a list of email servers that are allowed to send emails outbound on behalf of your domain name, MTA-STS is a list of mail server that can receive inbound emails for your domain name.

If you're not sure what to put in this field, at a minimum we would suggest you list here the same hosts as you have published in DNS for MX records.

max_age: Max lifetime of the policy specified in seconds with a max value of 31557600. Well-behaved clients will cache a policy for up to this value from the last policy fetch time. It is recommended to set this value in the range of a week (604800) or greater to mitigate the risks of attacks at policy refresh time.
Step 2 - Hosting the MTA-STS policy

The file you just generated in step 1 (mta-sts.txt) must be placed in a subfolder called ".well-known".  The subfolder must be created under the webroot top level.

You have two options when it comes to hosting the mta-sts.txt file.

Host the subfolder and mta-sts.txt file your existing web server.  However if you do you will need to add an alias to the hosting settings so the website answers to the hostname

Host the subfolder and mta-sts.txt file on a dedicated webserver that answers to the hostname

Whichever option you decide the webserver must have validate certificates for HTTPS traffic.

MTA-STS will not work on unsecure HTTP.

Step 3 - Create a mta-sts A (AAAA) record in DNS

You will need access to your domain name's DNS settings in order to create a DNS A record and/or a DNS AAAA record for the hostname "mta-sts" that points to the IP Address of the webserver hosting the MTA-STS policy.  You cannot use a DNS CNAME for mta-sts.

mta-sts A x.x.x.x

If you have your mta-sts policy hosted on several servers then you should create a matching number of A (or AAAA) records.

Once the record is added you should now be able to see the policy be navigating to

Step 4 - Create a _mta-sts TXT record in DNS

You will need access to your domain name's DNS settings in order to create a DNS TXT record with the name "_mta-sts"

_mta-sts TXT "v=STSv1; id=20240220135034Z"

v STS version 1 (STSv1)

The id is a short string used to track policy updates. This string MUST uniquely identify a given instance of a policy, such that senders can determine when the policy has been updated by comparing to the "id" of a previously seen policy.

It is suggested to make the ID unique and easy for someone to determine when a policy has been updated to set the id in the format of YYYYMMDDHHMMSSZ (E.g. 20240210135034Z equals 2024-03-10 13:50:34.  The "Z" on the end of the id is stating the timestamp is in Zulu time (UTC))

Additional reading

More information on MTA-STS can be found in the RFC8461.


like it, love it, then share it. Share this article on social media.

Did you enjoy this article?


The Origin of this information may be internal or external to Prolateral Consulting Ltd. Prolateral makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Prolateral makes no explicit or implied claims to the validity of this information. Any trademarks referenced in this document are the property of their respective owners.