MTA-STS Policy & TLS-RPT DNS Record Generator

MTA-STS Policy & TLS-RPT DNS Record Generator

Generate RFC 8461 Mail Transfer Agent Strict Transport Security (MTA-STS) policy files and _mta-sts/_smtp._tls DNS TXT records.

Presets:
Policy & DNS Configuration

Policy host: mta-sts.example.com

Strict security: rejects unencrypted/invalid TLS delivery.

Authorized Mail Exchange (MX) Hostnames2
mx:mail.example.com
mx:mx2.example.com
7 days (1 week)

Bump ID whenever you edit policy file so senders re-fetch.

TLS-RPT SMTP Incident Reporting (RFC 8460)
Domain: example.comMode: enforceMX Count: 2
RFC 8461 STSv1
version: STSv1
mode: enforce
mx: mail.example.com
mx: mx2.example.com
max_age: 604800
Lines: 6Chars: 86Size: 86 B
Served at https://mta-sts.<domain>/.well-known/mta-sts.txt
Enforcement Posture
enforceStrict TLS
Authorized Mail Targets
2 MX Patterns
Policy Cache Lifetime
7 days (1 week)

Zero-Latency Local Compilation

Synthesizes RFC 8461 policy files and DNS TXT records instantly in browser memory with zero network transmissions.

RFC 8461 & RFC 8460 Validation

Validates MX wildcard syntax, non-IP constraints, policy ID alphanumeric bounds, and HTTPS delivery standards.

Omni-Platform Deployment Ready

Exports ready-to-deploy snippets for BIND, Cloudflare, Route 53, Nginx, Caddy, Apache, and HashiCorp Terraform.

Technical Reference & Architecture Guide

MTA-STS Policy & TLS-RPT DNS Record Generator — Reference Guide

Comprehensive reference and best practices for generating RFC 8461 MTA-STS policy files, _mta-sts DNS TXT records, and RFC 8460 TLS-RPT reporting records.

Key Parameters & Controls

modestring (enforce | testing | none)

Defines the MTA-STS enforcement behavior for inbound SMTP connections. 'testing' requests sending MTAs to report TLS failures without dropping messages, 'enforce' requires valid TLS and drops non-compliant connections, and 'none' disables policy enforcement.

Default: testing
mxstring | string[]

List of allowed Mail eXchanger host patterns (FQDNs or single-level wildcards such as *.mail.example.com) that inbound sending servers are authorized to connect to and validate against TLS SAN certificates.

Default: mail.example.com
max_ageinteger (seconds)

The lifetime in seconds that a sending MTA should cache this MTA-STS policy locally. Typical production values range from 604800 (1 week) to 1209600 (2 weeks). Shorter durations (86400) are recommended during initial rollout.

Default: 604800
policy_idstring

A unique identifier string declared in the _mta-sts DNS TXT record (typically a timestamp or version hash like 2026101701). When updated, sending MTAs invalidate their cached policy and re-fetch mta-sts.txt over HTTPS.

Default: 20261017000000
ruastring (mailto URI)

The destination email address specified in the _smtp._tls TXT record where compliant sending MTAs deliver daily aggregated JSON-formatted TLS failure reports (TLS-RPT).

Default: mailto:[email protected]

Pro Tips & Best Practices

Always deploy your _smtp._tls TLS-RPT

Always deploy your _smtp._tls TLS-RPT record and set the MTA-STS mode to 'testing' for at least two weeks before switching to 'enforce'. Review incoming TLS-RPT aggregate reports to identify legacy sender cipher mismatches, expired intermediate certificates, or SNI issues without risking dropped production emails.

The policy file must be

The policy file must be served at https://mta-sts.<domain>/.well-known/mta-sts.txt with HTTP status 200, Content-Type text/plain, and a valid publicly trusted TLS certificate. Senders must not follow HTTP-to-HTTPS redirects across different hosts, and self-signed or expired certificates will cause immediate policy download failures.

The 'mx

The 'mx:' lines in your policy file must match both your public DNS MX records and the SAN entries on your mail server's TLS certificate. If your MX is mail.example.com, ensure your MTA presents a certificate valid for mail.example.com or *.example.com. Single-level wildcards (*.example.com) are permitted in MTA-STS policy files, but multi-level wildcards are rejected.

Common Gotchas & Troubleshooting

Policy Fetch Fails: Sending MTAs Report HTTPS Connection or Certificate Errors on mta-sts Subdomain

Ensure that DNS A/AAAA records exist for 'mta-sts.<yourdomain>' and that your web server serves a trusted certificate specifically covering mta-sts.<yourdomain> (or *.yourdomain). Avoid using wildcards that span multiple subdomains, verify port 443 is accessible globally, and ensure the server responds within the standard 10-second timeout without cross-domain redirects.

Legitimate Inbound Emails Rejected or Dropped Under 'enforce' Mode

Check if an MX server's TLS certificate has expired, does not include the exact hostname declared in the MX record, or fails to offer STARTTLS. If an unexpected mail routing change occurred without updating the MTA-STS policy, temporarily switch mode to 'testing' and update the DNS policy_id to force immediate cache invalidation across sending MTAs.

Frequently Asked Questions

What is the difference between MTA-STS and DANE TLSA?▼

MTA-STS (RFC 8461) relies on standard Web PKI (HTTPS and CA-signed certificates) and DNS TXT records to protect SMTP STARTTLS against downgrade and man-in-the-middle attacks. In contrast, DANE (RFC 7672) uses DNSSEC and TLSA records to pin cryptographic certificates directly in DNS, requiring full DNSSEC implementation which many top-level domains and registrars still do not support.

Why is the DNS policy_id (id parameter) critical for MTA-STS?▼

Sending MTAs cache MTA-STS policies according to the max_age directive (often 1-2 weeks). Senders check the _mta-sts.<domain> DNS TXT record for changes to the 'id=' value before attempting an HTTPS fetch. If you modify your policy file but fail to update the id parameter in DNS, remote senders will continue using the obsolete cached policy until max_age expires.

What happens if a sending MTA does not support MTA-STS?▼

Senders that do not implement RFC 8461 simply ignore the _mta-sts DNS TXT records and the HTTPS policy file. They proceed with standard opportunistic STARTTLS negotiation, falling back to plaintext transmission if STARTTLS is not offered or negotiation fails.

Can I specify multiple MX hosts in a single MTA-STS policy file?▼

Yes. You can declare multiple 'mx:' directives, each on its own line (e.g., 'mx: mx1.example.com', 'mx: mx2.example.com', or 'mx: *.mail.example.com'). Every MX record published in your domain's public DNS must have a matching 'mx:' line in the active MTA-STS policy.

Related Tools & Utilities

All Tools →
JWT Token Decoder & Security InspectorSecurity

Decode JSON Web Tokens, inspect header/payload claims, calculate expiration time and verify integrity locally.

Open tool→
Cryptographically Secure Password GeneratorSecurity

Generate ultra-secure passwords using Web Crypto API with custom length, symbols, and memorability.

Open tool→
Multi-Algorithm Hash Generator (SHA-256, SHA-512, MD5)Security

Compute instant cryptographic hashes entirely in browser with zero server transmission.

Open tool→
JSON Web Token (JWT) Debugger & Signature VerifierSecurity

Decode, verify, and inspect JWT headers, payloads, and claims with local secret or public key without sending data to servers.

Open tool→
Password Entropy & Security Strength AuditorSecurity

Evaluate password resilience against brute-force attacks with Shannon entropy calculations, zxcvbn pattern matching, crack time estimates, and zero server transmission.

Open tool→
Client-Side AES-GCM / CBC Encryptor & DecryptorSecurity

Encrypt and decrypt strings and files using modern AES-GCM 256-bit cryptography powered by the native browser Web Crypto API.

Open tool→