MTA-STS and TLS-RPT Guide - Enforce Encrypted Email Delivery

SMTP was designed to deliver mail opportunistically. If TLS is available, mail servers use it. If TLS fails, many senders historically fell back to cleartext delivery. That fallback is useful for compatibility, but it creates a downgrade path: an attacker who can interfere with SMTP can try to force delivery without encryption.

MTA-STS (Mail Transfer Agent Strict Transport Security) tells sending mail servers: "only deliver to my MX hosts over valid TLS." TLS-RPT gives those senders a reporting address so you can see certificate failures, policy mismatches, and downgrade attempts.

For sender authentication, start with SPF, DKIM, and DMARC. MTA-STS is the transport-security layer that complements them.

What MTA-STS Protects

MTA-STS protects inbound delivery to your domain's MX hosts. A supporting sender checks your policy before delivering mail. If the policy is in enforce mode, delivery must use TLS with a valid certificate for a host that matches your policy.

It protects against:

• Passive cleartext exposure when SMTP would otherwise downgrade
• Active TLS stripping between sender and receiver
• Delivery to unexpected MX hosts not listed in your policy
• Expired, invalid, or name-mismatched certificates on your mail servers

It does not authenticate the sender. That is still SPF, DKIM, and DMARC.

The Three Moving Parts

1. MTA-STS TXT Record

Publish a TXT record at _mta-sts.yourdomain:

_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=2026050501"

The id is a version string. It can be a date, timestamp, or deployment ID. Change it whenever the HTTPS policy changes.

2. HTTPS Policy File

Host this file:

https://mta-sts.example.com/.well-known/mta-sts.txt

Example policy:

version: STSv1
mode: testing
mx: mail.example.com
mx: *.mail.example.com
max_age: 86400

Fields:

The policy host must serve a valid public TLS certificate. Do not put the policy behind authentication, redirects that break clients, or IP allowlists.

3. TLS-RPT TXT Record

Publish a TXT record at _smtp._tls.yourdomain:

_smtp._tls.example.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Reports are aggregate JSON documents. They show which senders saw successful TLS delivery and which saw failures.

Safe Rollout

1. Confirm all MX hosts support STARTTLS.
2. Confirm every MX host presents a valid certificate.
3. Publish _mta-sts TXT with a fresh id.
4. Host a policy file in mode: testing.
5. Publish _smtp._tls TXT so reports arrive.
6. Review reports for at least several days.
7. Fix certificate, hostname, or MX mismatches.
8. Change the policy to mode: enforce.
9. Increase max_age once stable.

Testing mode is not optional. It is the difference between learning about problems and causing mail deferrals.

DNScale Setup

Create the two TXT records in your DNScale zone:

curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "_mta-sts",
    "type": "TXT",
    "content": "v=STSv1; id=2026050501",
    "ttl": 3600
  }'

curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "_smtp._tls",
    "type": "TXT",
    "content": "v=TLSRPTv1; rua=mailto:tls-reports@example.com",
    "ttl": 3600
  }'

Host the policy file on your web infrastructure at mta-sts.example.com.

Verification

Check DNS:

dig TXT _mta-sts.example.com +short
dig TXT _smtp._tls.example.com +short

Check policy fetch:

curl -fsS https://mta-sts.example.com/.well-known/mta-sts.txt

Check MX hosts:

dig MX example.com +short
openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com

Look for a valid certificate chain and a hostname that matches the MX policy.

Common Mistakes

• Enforcing before reports have been reviewed
• Listing example.com in the policy when the MX is actually mail.example.com
• Forgetting to update the _mta-sts id after changing the policy
• Hosting the policy on HTTP instead of HTTPS
• Using a certificate valid for the website but not for the MX hostname
• Sending TLS-RPT reports to a mailbox nobody monitors

Related Guides

• SPF record explained
• DKIM explained
• DMARC explained
• BIMI record guide
• TXT records