What is MTA-STS?

What is MTA-STS?

MTA-STS (Mail Transfer Agent Strict Transport Security) is an email security standard defined in RFC 8461. It allows domain owners to publish a policy that instructs sending mail servers to require authenticated, encrypted TLS connections when delivering email to that domain.

Without MTA-STS, SMTP uses opportunistic TLS — meaning it will attempt a TLS connection but fall back to plaintext if TLS negotiation fails. This makes email vulnerable to downgrade attacks where a network attacker forces plaintext delivery to intercept or tamper with messages.

The Problem MTA-STS Solves

Standard SMTP has no mechanism to require TLS. An attacker intercepting the connection can strip the STARTTLS advertisement and force plaintext delivery — the sender cannot distinguish a legitimate TLS failure from an active attack. MTA-STS publishes the TLS requirement out-of-band via DNS and HTTPS, two channels an attacker would need to compromise simultaneously. A sender that retrieves and caches your policy will refuse plaintext delivery even if STARTTLS is stripped.

How MTA-STS Works

MTA-STS requires two components: a DNS TXT record and an HTTPS-hosted policy file.

Step 1 — DNS TXT record: Publish a record at _mta-sts.yourdomain.com signaling that a policy exists:

_mta-sts.example.com. IN TXT "v=STSv1; id=20260101000000Z"

• v=STSv1 — version tag (required).
• id= — a policy identifier that changes whenever your policy changes, allowing senders to detect updates. Typically a timestamp in the format YYYYMMDDHHmmssZ.

Step 2 — HTTPS policy file: Host a policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt with a valid TLS certificate:

version: STSv1
mode: enforce
mx: mail.example.com
mx: *.example.com
max_age: 604800

• version: Must be STSv1.
• mode: The enforcement mode (see below).
• mx: One or more MX hostname patterns that are authorized to receive mail for your domain. Wildcards are supported.
• max_age: How long (in seconds) senders should cache this policy. 604800 = 7 days.

Policy Modes

MTA-STS supports three policy modes:

• enforce: Sending servers must use valid TLS matching the authorized MX hostnames. If TLS negotiation fails for any listed MX, the message is not delivered and a TLS-RPT failure report is generated.
• testing: The policy is published but not enforced. Sending servers should still report TLS failures via TLS-RPT, but they will not block delivery on failure. Use this mode to identify issues before enabling enforcement.
• none: Indicates the policy is being retired. Senders should stop enforcing any previously cached policy for this domain.

Relationship with TLS-RPT

MTA-STS and TLS-RPT are complementary. MTA-STS enforces TLS; TLS-RPT reports when enforcement causes delivery failures. Recommended sequence: deploy TLS-RPT first, add MTA-STS in testing mode, resolve any certificate or MX hostname issues shown in reports, then switch to enforce mode.

MTA-STS Hosting with DDMARC

Hosting the policy file requires a subdomain with a valid TLS certificate serving /.well-known/mta-sts.txt over HTTPS. DDMARC can host this file for you — configure your policy in the dashboard and add a CNAME pointing mta-sts.yourdomain.comto DDMARC's servers. You only need to add the DNS TXT record yourself.

Frequently Asked Questions

Does MTA-STS affect outbound email from my domain?

No. MTA-STS only applies to inbound email delivery — it tells external sending servers how to connect when delivering mail to your domain. To protect your outbound email, ensure your sending infrastructure supports STARTTLS and consider deploying DMARC, DKIM, and SPF for authentication.

What happens if my TLS certificate expires while MTA-STS is in enforce mode?

Senders enforcing MTA-STS will fail to verify your TLS certificate and will not deliver email to the affected MX hostname. This can cause significant mail flow disruption. TLS-RPT reports will show a spike in certificate-expired failures. Renewing your certificate restores delivery — senders that have cached the policy will retry and succeed once the certificate is valid again.

How does MTA-STS differ from DANE?

Both MTA-STS and DANE (DNS-Based Authentication of Named Entities) enforce TLS for SMTP delivery, but through different mechanisms. DANE uses DNSSEC-signed TLSA records to pin certificate expectations directly in DNS — it requires DNSSEC deployment on both sides. MTA-STS uses a separate HTTPS-hosted policy file and does not require DNSSEC. MTA-STS has broader adoption today because DNSSEC deployment remains limited among sending MTAs.