MTA-STS using Cloudflare Workers
We regularly review this blog post and update and republish where necessary. If there are any errors or omissions, or you have any suggestions for additions please get in touch using the contact form.
Last updated 7/7/2023
What is MTA-STS and why is it important…
Mail Transfer Agent Strict Transport Security (MTA-STS) tells other organisations and email providers that your domain supports Transport Layer Security (TLS) 1.2 or higher.
The aims of MTA-STS are to make it harder for an attacker to get emails sent to an attacker and make sure that TLS encryption is always used, to prevent downgrade attacks.
However, if the sender does not support TLS or MTA-STS then the email will likely still be delivered to you - just unencrypted. The sender needs to support MTA-STS in order for this to work. Thankfully, major email providers like Microsoft, Google and Yahoo! do. This means that they will not send email to your domain unless TLS is assured.
One way to deploy MTA-STS quickly, particularly if you are using Cloudflare already is via Cloudflare Workers. The benefits of using Cloudflare to deploy your MTA-STS policy at their edge is several-fold:
speed; your policy will deploy instantly around the world and will be highly available.
‘serverless’; your policy will hosted on the Cloudflare edge and not hosted on your web server, making it faster and more secure.
convenience; edit the policy from the Cloudflare portal rather than editing text files on a web server. You need to update the DNS record anyway so everything is done in one place.
simplicity; No changes are required to the website or web server to implement it.
More information about MTA-STS is available on the NCSC website:
https://www.ncsc.gov.uk/collection/email-security-and-anti-spoofing/using-mta-sts-to-protect-the-privacy-of-your-emails
and in the standards document RFC8461.
Using Cloudflare Workers to implement MTA-STS
In this example we will setup MTA-STA for 365labs.cloud using a Cloudflare Worker. The domain should already be in Cloudflare and the nameservers set to Cloudflare.
Select the domain in the dashboard and then choose Workers > Manage Workers > Create a Service.
Give your new service a new name such as mta-sts-yourdomain-tld and click Create Service.
Once the service has been created click Quick edit and replace the sample code in the worker with the code below. Edit the second line below and replace with your own domain and if not using Microsoft 365 your MX records. The text contents of the policy is contained within the backticks and can be customised depending on what you want your policy to be. Once customised click Save and Deploy.
const stsPolicies = {
"mta-sts.yourdomain.tld":
`version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 86400`
}
const respHeaders = {
"Content-Type": "text/plain;charset=UTF-8",
}
addEventListener("fetch", event => {
event.respondWith(handleRequest(event.request))
})
async function handleRequest(request) {
let reqUrl = new URL(request.url)
if (!stsPolicies.hasOwnProperty(reqUrl.hostname)) {
return new Response(`${reqUrl.hostname} is not defined in the mta-sts worker\n`, {status: 500, headers: respHeaders})
}
if (reqUrl.protocol === "https:" && reqUrl.pathname === "/.well-known/mta-sts.txt") {
return new Response(stsPolicies[reqUrl.hostname] + "\n", {status: 200, headers: respHeaders})
} else {
reqUrl.protocol = "https:"
reqUrl.pathname = "/.well-known/mta-sts.txt"
return Response.redirect(reqUrl, 301)
}
}
From the Triggers tab, click Create a Custom Domain and enter mta-sts.yourdomain.tld into the Route text box and click Add Custom Domain. This will create the necessary DNS records to point to the worker.
Once the code and DNS records are in place we need to set the worker to trigger based on a URL pattern.
Under routes click Add route. Under Zone choose the domain the worker is configured for and under route enter mta-sts.yourdomain.tld/*. You can make this rule more specific if you prefer.
Now when you visit https[:]//mta-sts.yourdomain.tld/.well-known/mta-sts.txt you should see the MTA-STS file output into the browser window.
Note: Some email providers will only process policies (including in testing mode) if the max_age value is 86000 seconds (1 day) or higher. Google is one of those providers. Even during testing you should use 86000 or higher to get accurate test reports.
Create the MTA-STS policy discovery record
You will need to create a DNS entry signalling that your domain has an MTA-STS policy.
You will need to create a DNS entry like the following example:
_mta-sts.365labs.cloud
It is of type TXT, and has the following format:
v=STSv1; id=20230707130000Z
The ID value must be unique and changed every time you amend your MTA-STS policy. In this case we have used yyyymmddhhmmssZ as a simple way of keeping the ID unique as well as recording when the record was last updated. The Z suffix just indicates Zulu Time. You can choose whatever id you like as long as it is changed and unique each time the policy changes.
Warning: Enabling MTA-STS in enforce mode from the outset could cause some email not to be delivered to you. It is better to use 'mode: testing’ and a fairly low max_age: value (but at least 86000). This will ensure everything is in working order before proceeding to enforcement.
Monitoring and reporting using SMTP TLS Reporting (TLS-RPT)
TLS-RPT will report on whether your email server is establishing good TLS connections, and will allow you to move progress to an MTA-STS policy of enforce.
You will need to create a DNS entry similar to ours:
_smtp._tls.365labs.cloud
It is of type TXT, and has the following format:
v=TLSRPTv1;rua=mailto:[email protected]
After at least a few weeks of monitoring those reports you should be able to move from mode: testing to mode: enforce.
We are using report-uri.com to collect TLS-RPT, but this service will also collect DMARC and CSP reports amongst many other things.
SMTP DNS-based Authentication of Named Entities (SMTP-DANE)
As an aside, DANE is a different standard to MTA-STS. DANE requires DNSSEC for authentication whereas MTA-STS uses certificate authorities for the authentication part.
If you are an Exchange Online (Microsoft 365) customer, then there is nothing you need to do as DANE is enabled by default for outbound email. DANE will be used when the destination domain advertises support for DANE.
Currently, inbound SMTP DANE isn't supported for Exchange Online. Microsoft anticipate support from the end of 2022 2023.
If you’d like to discuss MTA-STS, DANE or email security in general please get in touch. We can provide a free short report on your existing configuration. A detailed analysis and report can be provided for a fee.
Last updated 7/7/2023
