Free MTA-STS Hosting

Why MTA-STS is essential

SMTP was designed in 1982 without encryption. STARTTLS was added later to encrypt email in transit, but it has a critical flaw: it is opportunistic. A sending server announces STARTTLS support, and the receiving server can accept or ignore it. Nothing forces the connection to stay encrypted.

This creates a window for SMTP downgrade attacks. An attacker positioned between two mail servers can strip the STARTTLS command from the SMTP handshake. BGP hijacking, DNS spoofing, and network-level interception all make this possible. The sending server sees no encryption option and falls back to plaintext. The email travels unencrypted, readable by anyone on the path.

MTA-STS (RFC 8461) closes this gap. It tells sending servers: "This domain requires TLS. Never fall back to plaintext." The sending server must establish a valid TLS connection or queue the message for retry.

The deployment barrier: MTA-STS requires hosting a policy file at https://mta-sts.captaindns.com/.well-known/mta-sts.txt over HTTPS with a valid certificate. For many organizations, setting up and maintaining a dedicated web server for a single text file is disproportionate. CaptainDNS removes this barrier entirely.

What happens without MTA-STS

Without MTA-STS, your email transport relies solely on opportunistic TLS. Here is what that means in practice:

• Plaintext interception: any network-level attacker can read your emails by stripping STARTTLS. This is not theoretical. State-level surveillance programs and ISP-level interception have been documented.
• No sender verification: without a published policy, sending servers have no way to know your domain requires TLS. They will silently downgrade if anything goes wrong.
• Compliance exposure: regulations like GDPR, HIPAA, and PCI-DSS require encryption of sensitive data in transit. Opportunistic TLS alone does not meet this standard because it can be bypassed.
• Invisible failures: without TLS-RPT (the companion reporting protocol), you never learn that emails to your domain were delivered unencrypted. The problem is silent.

This is not hypothetical. In 2014, researchers documented large-scale STARTTLS stripping by network intermediaries across multiple countries. Google's Transparency Report later confirmed that a significant share of inbound emails still arrive without encryption. MTA-STS is the protocol designed to end this.

MTA-STS paired with TLS-RPT gives you both enforcement and visibility.

How MTA-STS works under the hood

MTA-STS uses two components that work together:

1. A DNS TXT record at _mta-sts.captaindns.com

This record advertises your MTA-STS policy and contains a unique policy ID. When the ID changes, sending servers know they must fetch a fresh copy of the policy.

Example: v=STSv1; id=20260308120000

2. An HTTPS-hosted policy file at https://mta-sts.captaindns.com/.well-known/mta-sts.txt

This file defines three things:

• mode: testing (report only) or enforce (reject on TLS failure)
• mx: the mail server patterns that must match your MX records
• max_age: how long sending servers should cache the policy (in seconds)

Example:

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

When a sending server wants to deliver email to your domain, it checks for the _mta-sts TXT record. If present, it fetches the policy file over HTTPS. It then validates the TLS certificate of your MX servers against the policy patterns. Delivery proceeds only if everything matches.

Trust on first use (TOFU): MTA-STS relies on the first successful policy fetch being legitimate. After that, the cached policy protects against future attacks for the duration of max_age. A longer max_age (7+ days) is recommended in enforce mode for this reason.

How it works

1. Create your policy

Sign in and create a new policy. Set your domain, mode (testing or enforce), MX patterns, and cache duration (max_age).

2. Verify domain ownership

Add the TXT verification record to your DNS. We detect it automatically within seconds.

3. Add deployment DNS records

Two DNS records:

• CNAME: Points mta-sts.captaindns.com to our policy server
• TXT: Advertises your MTA-STS policy at _mta-sts.captaindns.com

Your MTA-STS policy is live.

Compatible with major email providers

MTA-STS works with any email provider that uses standard MX records. The MX patterns in your policy must match your provider's mail servers:

When creating your policy on CaptainDNS, enter the MX patterns that match your provider. The dashboard validates them against your live MX records to prevent mismatches.

Hosted vs. self-hosted: which option to choose?

Choose hosted if you want MTA-STS deployed in minutes with zero infrastructure. Choose self-hosted if you need full control over the policy endpoint or operate in an air-gapped environment.

From testing to enforce: a progressive strategy

Deploying MTA-STS in enforce mode immediately is risky. If your MX patterns are wrong or a TLS certificate expires, legitimate emails get rejected. The recommended approach is progressive:

Phase 1: Deploy in testing mode (1 to 2 weeks)

Set mode: testing in your policy. Sending servers will attempt TLS and report failures via TLS-RPT, but will still deliver emails even if TLS fails. This gives you visibility without risk.

Phase 2: Analyze TLS-RPT reports

Review the reports to identify issues: certificate mismatches, MX patterns not covering all mail servers, or third-party senders with broken TLS. Fix each issue before moving forward.

Phase 3: Switch to enforce mode

Once reports show zero failures for at least a week, change the mode to enforce and increase max_age to 604800 (7 days) or more. On CaptainDNS, this is a single click in the dashboard. The policy ID rotates automatically.

Emergency rollback: if enforce mode blocks legitimate mail, switch back to testing immediately. Sending servers will fetch the updated policy and stop rejecting within minutes (or at most within the old max_age window).

MTA-STS and DANE: two complementary approaches

Two protocols exist to enforce email transport encryption: MTA-STS and DANE (DNS-based Authentication of Named Entities). They solve the same problem differently.

If your domain does not use DNSSEC, MTA-STS is your only option for enforced transport encryption.

If your domain uses DNSSEC, deploying both protocols gives the strongest protection: DANE eliminates TOFU for DNSSEC-aware senders, while MTA-STS covers senders that do not support DANE.

MTA-STS deployment best practices

1. Start in testing mode: identify TLS connectivity issues before switching to enforce.
2. Set up TLS-RPT: receive reports on TLS delivery failures. Use our TLS-RPT Generator.
3. Validate your MX records: ensure the MX patterns in your policy match your actual mail servers. Mismatches cause delivery failures in enforce mode.
4. Monitor before enforcing: analyze TLS-RPT reports for at least one week with zero failures before switching to enforce.
5. Use a long max_age in enforce mode: 604800 seconds (7 days) or more. This ensures sending servers cache your policy long enough to resist downgrade attacks.
6. Switch to enforce: once TLS-RPT reports confirm everything works, enable enforce mode for full protection.

Complementary tools

Guides and resources

• MTA-STS: the complete guide to securing your email transport - Everything you need to know about MTA-STS configuration and deployment.
• From testing to enforce: a progressive MTA-STS deployment strategy - Best practices for a gradual MTA-STS rollout.
• Configure MTA-STS for Microsoft 365 and Google Workspace - Step-by-step setup for the two most popular email platforms.
• MTA-STS Not Working? Complete Troubleshooting Guide - Diagnose and fix the most common MTA-STS configuration errors.
• MTA-STS vs DANE: which protocol to choose for securing email transport? - Detailed comparison to help you pick the right protocol.