15 minutesAdvanced

MTA-STS Setup Guide

Configure MTA-STS to enforce TLS encryption for incoming email and prevent downgrade attacks.

What is MTA-STS?

MTA-STS (Mail Transfer Agent Strict Transport Security) allows domain owners to declare that their mail servers support TLS and that sending servers should refuse to deliver mail if a secure connection cannot be established. This prevents man-in-the-middle attacks and TLS downgrade attacks.

How MTA-STS Works

Step 1

DNS Record

Publish _mta-sts TXT record

Step 2

Policy File

Host policy at .well-known URL

Step 3

Sender Checks

Sending server fetches policy

Step 4

TLS Enforced

Connection requires valid TLS

Requirements

Before setting up MTA-STS, ensure your mail servers meet these requirements:

Valid TLS Certificate

Your MX servers must have valid certificates from a trusted CA (not self-signed)

Certificate Chain

The full certificate chain must be properly configured

Matching Hostnames

Certificates must match the MX hostnames exactly

TLS 1.2 or Higher

Mail servers should support modern TLS versions

Step 1: Add DNS Record

Add a TXT record at _mta-sts.yourdomain.com to signal that MTA-STS is enabled:

DNS TXT Record

Host: _mta-sts

Type: TXT

Value: v=STSv1; id=20240115120000

About the ID field

The idfield is used to indicate policy changes. When you update your policy, change the ID (we recommend using a timestamp like YYYYMMDDHHMMSS). Sending servers will re-fetch the policy when they see a new ID. On DDMARC's managed hosting you never touch this: the ID is bumped for you on every policy change, after the new policy content is already being served.

Step 2: Host Policy File

Create a policy file and host it at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

Example Policy File

version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

Field	Required	Description	Example
version	Required	Policy version (always STSv1)	STSv1
mode	Required	Policy mode (testing, enforce, none)	enforce
mx	Required	Mail server hostnames (can repeat)	mx1.example.com
max_age	Required	Policy cache time in seconds	604800

mode: testing—Testing Mode

Senders will report failures via TLS-RPT but will still deliver email without TLS if needed. Use this first.

mode: enforce—Enforce Mode

Senders must use TLS. If TLS fails, email will not be delivered. Only enable after thorough testing.

mode: none—None Mode

Disables MTA-STS. Use this to gracefully disable the policy.

Growth and above

Managed MTA-STS Hosting

Steps 1 and 2 above are the manual path. From the Growth plan upward, DDMARC hosts both halves for you — the policy file over HTTPS with certificates handled automatically, and the _mta-stsTXT record with its ID. Set it up on your domain's Hosted Services tab, then delegate with two CNAME records.

Add both CNAME records (replace example.com with your domain):

_mta-sts.example.com  CNAME  example.com._mta-sts.dmarc.ddmarc.com
mta-sts.example.com   CNAME  mta-sts-serve.dmarc.ddmarc.com

The first delegates the policy ID TXT record; the second points at the host that serves your policy file. Both are required — with only one of them, verifiers either never notice a policy change or cannot fetch the policy at all. The exact values are shown on the Managed MTA-STS card; copy them from there.

Managed policies start in testing mode. A wrong policy in enforce blocks your inbound mail, so DDMARC will not switch a policy to enforce unless every live MX host for the domain matches the policy's mx patterns. If a host does not match, the switch is refused and the unmatched hosts are named. You can override deliberately — the override is recorded — but fixing the mx list is almost always the right answer.

DANE/TLSA — the other transport control

MTA-STS anchors trust in the public certificate authorities plus a web policy. DANE anchors it in DNSSEC instead: you publish TLSA records at _25._tcp.<your-mx-host> that pin the certificate your MX presents, and a DNSSEC-validating sender refuses to deliver if the presented certificate does not match. The two are complementary, and large senders check both.

What DDMARC does here

Reports your DNSSEC status for the domain (secure, unsigned, bogus or indeterminate) — DANE is only meaningful on a DNSSEC-signed zone.
Looks up TLSA records for your MX hosts, and probes the live certificate each MX presents to confirm it actually matches what the TLSA record pins.
Both checks are advisory only. They appear as information in the DNS health card and never change your security grade — publishing (or not publishing) DANE cannot move your score up or down.

Background reading: what is DANE and what is DNSSEC.

Step 3: Enable TLS-RPT (Recommended)

TLS-RPT (TLS Reporting) allows you to receive reports about TLS connection failures. Add a TXT record at _smtp._tls.yourdomain.com:

TLS-RPT DNS Record

Host: _smtp._tls