Generate MTA-STS policy files and DNS records to enforce TLS for incoming email connections.
MTA-STS is the inbound-mail equivalent of a 'no plaintext' sign on your front door: it tells other mail servers that connections to your domain's mail exchangers must be TLS-encrypted, and that unencrypted delivery should be refused rather than accepted. This generator produces the two artifacts the standard requires - the DNS TXT record under _mta-sts.yourdomain and the policy file that must be served over HTTPS from mta-sts.yourdomain. The usual surprise: it governs mail arriving at your domain, not mail you send.
A concrete input and expected output from the current implementation.
Input
Domain: example.com. MX records: mail.example.com (priority 10), mx2.example.com (priority 20). Mode: enforce.
Expected output
DNS TXT record: _mta-sts.example.com. 3600 IN TXT "v=STSv1; id=20260816000000" Policy file, to be served at https://mta-sts.example.com/.well-known/mta-sts.txt: version: STSv1 mode: enforce mx: mail.example.com mx: mx2.example.com max_age: 604800
The TXT record carries the policy id that sending servers read first; the HTTPS file carries the actual rules. The mx lines must mirror the domain's MX hostnames exactly, and max_age of 604800 seconds (one week) tells senders how long to cache the policy. The id is tool-generated and should change whenever the policy content changes.
RFC 8461 couples a DNS TXT record with an HTTPS-hosted policy file. A sending server first reads the TXT record at _mta-sts.yourdomain, which carries the current policy id, then fetches the policy from https://mta-sts.yourdomain/.well-known/mta-sts.txt over a certificate-validated TLS connection. Only when both succeed does the policy take effect; any failure leaves the domain treated as if it had no policy.
The file declares a mode (enforce, testing, or none), the mx hostnames senders may connect to, and max_age, the number of seconds senders cache the policy. In enforce mode, MTA-STS-aware senders refuse delivery unless the connection is TLS-protected and terminates at a listed mx host, closing the STARTTLS-downgrade hole where a mid-connection attacker could strip encryption.
No. The policy governs inbound delivery - connections other servers make to your MX records - and it is enforced by the sending side. Outbound mail from your own servers is outside its scope, and so is inbound mail to a domain that has not published a policy. If you want outbound protection, MTA-STS does not apply; other mechanisms would.
Enforcement binds only senders that implement MTA-STS and have successfully fetched your policy over HTTPS with a valid certificate for mta-sts.yourdomain. Senders that cannot fetch the policy, that predate the standard, or that fail certificate validation simply deliver without it. Running mode: testing with TLSRPT reporting (RFC 8460) shows what senders would do before you enforce.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Generate strong, random passwords with customizable length, character sets, and complexity requirements.
Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.
Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.
Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.
Scan and decode QR codes from uploaded images or your device camera to extract embedded data.
Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.