How to Set Up MTA-STS Policy File

Why MTA-STS Matters for Email Deliverability in 2026

You send emails every day. But how do you know they’re not being intercepted or rerouted through insecure paths before reaching the inbox? Without MTA-STS, that’s exactly what can happen.

MTA-STS (Mail Transfer Agent Strict Transport Security) is a DNS-based protocol that forces email servers to use encrypted connections during transit. It’s like putting a lock on the mailbox that only allows trusted, secure handoffs. Without it, your messages risk being sent over unencrypted or unverified routes.

Enable MTA-STS to protect your sender reputation. It signals trust to receiving servers, reduces the chance of your emails being flagged as suspicious, and strengthens deliverability in an era where encryption is no longer optional.

Key takeaways

MTA-STS enforces encryption between email servers, preventing insecure or hijacked transit paths.
Implementing MTA-STS reduces the risk of spoofing and interception, directly improving sender reputation.
With growing scrutiny from major providers, MTA-STS is increasingly necessary for consistent inbox placement in 2026.

What Is an MTA-STS Policy File and How Does It Work?

You can think of an MTA-STS policy file as a digital passport for your email server. It’s a machine-readable document hosted on your domain’s web server that tells other email servers exactly how to securely connect to your mail transfer agents. It enforces encryption and authenticates your sending infrastructure by specifying required TLS versions and valid public keys, ensuring only trusted servers can deliver mail to you.

How MTA-STS Validates Connections

When another mail server tries to send you email, it first checks your domain’s MTA-STS policy file before making a connection. This happens automatically, through a DNS lookup that directs the receiver to the file hosted at https://yourdomain.com/.well-known/mta-sts.txt. If the file exists and the connection meets its requirements—like using TLS 1.2 or higher and presenting a valid certificate—the message is accepted.

This process prevents man-in-the-middle attacks and ensures your incoming mail isn’t intercepted or spoofed. It works alongside existing email security protocols like SPF, DKIM, and DMARC, but specifically guards against downgrade attacks and unencrypted delivery.

Let’s say you’re using a third-party email service. Their mail servers must comply with your policy file’s rules to deliver to your users. If they don’t, your inbound mail will be rejected—even if the message is otherwise valid. This makes MTA-STS an essential layer for inbox reliability.

What’s Inside the Policy File?

The file is simple in structure. It contains directives like version: STSv1, mode: enforce, and max_age: 86400 (meaning it’s valid for 24 hours). The enforce mode means only encrypted, authenticated connections are allowed. You can also include a testing mode to verify configuration without blocking delivery.

It can also include a list of valid public keys via the key_pinning directive. If a server presents a certificate that doesn’t match the pinned keys, the connection fails—even if the certificate is otherwise valid.

For a detailed guide on implementing MTA-STS with proper syntax and testing, the IETF RFC 8461 is the authoritative source [RFC 8461]. It explains every parameter, including how to set max_age, how to rotate keys, and how to use the testing mode safely.

Once set up correctly, MTA-STS significantly reduces the risk of spoofed or intercepted messages. For teams managing high volumes of outbound mail, it’s not just security—it’s trust infrastructure. If you're sending bulk email and want to protect your sender reputation, make sure your domain is protected by MTA-STS. You can verify your domain and catch potential issues early with our inbox placement testing.

MTA-STS Policy File vs. STS Records: What’s the Difference?

You don’t store your MTA-STS policy directly in DNS. Instead, you publish a policy file on your web server via HTTPS, and DNS holds a TXT record that points to it. The TXT record is called an STS record—it’s the pointer. The actual policy (what enforcement and validation rules to apply) lives in the file, served over HTTP(S). This separation lets you update the policy without changing DNS, and it supports secure, versioned delivery.

How the Two Work Together

Let’s say your domain is example.com. You create a file named mta-sts.txt and host it at https://example.com/.well-known/mta-sts.txt. Then, in your DNS, you add a TXT record with the name mta-sts.example.com and the value v=STS1; version=1; policy=https://example.com/.well-known/mta-sts.txt. That’s the STS record—it’s the map to the policy file.

The policy file itself contains your actual policy: whether you enforce TLS, how long the policy is valid, and if you allow fallbacks. It’s not stored in DNS, which keeps the DNS zone clean and avoids bloated records. This design is a deliberate part of the standard: RFC 8461 defines this structure for good reason—flexibility, security, and ease of maintenance.

Why This Matters for Deliverability

When another mail server tries to send to your domain, it checks the STS record in DNS first. It then downloads the policy file over HTTPS (so it can verify the content is genuine and hasn’t been tampered with). If the file says TLS is required and the sender doesn’t use it, the message can be rejected—preventing insecure transmission.

Because the policy file is external, you can test new configurations, roll back changes, or update policies without waiting for DNS propagation. It also lets you use your existing infrastructure—your web server handles the delivery, not DNS.

Even if you don’t use MTA-STS for outbound mail, you can still benefit from verifying that inbound mail is being sent securely. Tools like bulk verification help ensure sender domains have properly configured MTA-STS policies, reducing the risk of your messages being flagged or rejected due to weak encryption.

MTA-STS Policy File Example: A Real, Working Configuration

Place a file at https://yourdomain.com/.well-known/mta-sts.txt with the content version=STSv1; mode=enforce; max_age=86400. This tells receiving mail servers to require encrypted connections, enforce your policy, and cache it for up to 24 hours. It’s the simplest, most effective way to start protecting your domain from email spoofing and man-in-the-middle attacks.

What Each Field Really Does

The version=STSv1 directive is non-negotiable—it identifies the file as a valid MTA-STS policy. Without it, the file is ignored. The mode=enforce field is where the action happens: it tells recipient servers to reject any unencrypted mail from your domain. If you’re testing, you can use mode=none or mode=monitor to observe without blocking, but for production, enforce is the only option.

The max_age=86400 value sets how long receiving servers will cache your policy—86,400 seconds equals 24 hours. This reduces load on your server and gives you time to update the policy if needed. You can lower this to 3600 (1 hour) for faster changes, but 24 hours is a standard, safe default.

Why This Works in Practice

MTA-STS is part of a larger email authentication ecosystem. It works alongside SPF, DKIM, and DMARC, but it’s unique because it enforces encryption at the transport layer. If a server receives email from your domain on an unencrypted channel, and MTA-STS is in enforce mode, the email will be rejected—no exceptions.

You can check your setup using tools like OpenSPF’s SPF Check or MXToolbox. These validate TXT records and policy files without requiring you to send a test message. It’s also good practice to monitor your sending logs and DMARC reports to ensure enforcement isn’t accidentally blocking legitimate mail.

Once your policy is live, you’re no longer relying on receivers to trust your email by default. You’re explicitly telling them: “Only connect to me securely, or don’t connect at all.” This level of control is essential for domains that send transactional emails, financial notifications, or anything requiring high trust.

If you’re managing a bulk mailing list or integrating with platforms like Mailchimp or Klaviyo, validating your domain setup helps avoid deliverability issues. You can use automated verification tools like EmailListChecker’s bulk verification to test your domain configurations across thousands of email addresses in a single batch, including authentication alignment checks.

How to Set Up MTA-STS Policy File: Step-by-Step

You can set up an MTA-STS policy file by creating a plain text file named mta-sts.txt, adding the required policy string, uploading it to your web server’s /.well-known/ directory, ensuring it's served over HTTPS, and publishing a DNS TXT record for _mta-sts.yourdomain.com. This enables your domain to enforce TLS encryption for incoming mail, reducing the risk of interception.

Step-by-Step Setup Process

Create the policy file as a plain text file named mta-sts.txt. This file must be UTF-8 encoded and contain only the policy string. No extra characters or line breaks are allowed.
Define the policy using the format version=STSv1; mode=enforce; max_age=86400. The max_age=86400 sets the validity period to 24 hours, which is the standard and recommended duration for most setups.
Upload the file to the /.well-known/ directory on your web server. This location is specified by the standard and is the only path email clients and mail servers will check for the policy.
Ensure HTTPS access — the file must be available via HTTPS. HTTP will not work; the file must be served over a secure connection with a valid certificate.
Add the DNS TXT record with name _mta-sts.yourdomain.com and value v=STSv1; id=2026. The id field can be any unique identifier, but the value must be non-zero and follow the format specified in RFC 8461.

Verification and Best Practices

After setup, you can test your configuration using tools like MXToolbox's MTA-STS checker, which validates DNS and file accessibility. It’s important to monitor your domain’s status — misconfigurations can lead to email delivery failures.

Set mode=enforce instead of mode=monitor once you’re confident in your setup. The monitor mode is useful during initial rollout to catch issues without breaking delivery.

If you're managing email lists at scale, verify the accuracy of your addresses before deploying strong policies. A high bounce rate on verified addresses can trigger delivery issues even with MTA-STS in place. Use bulk verification tools to clean your list and ensure only valid email addresses are in use.

MTA-STS is not a substitute for proper authentication methods like SPF, DKIM, and DMARC, but it enhances them by enforcing encrypted connections. Use it as part of a layered defense.

MTA-STS Testing Mode vs Enforce Mode: Understanding the Impact

Setting up MTA-STS in testing mode lets you monitor how your email infrastructure handles policy enforcement without blocking any messages. Once you’ve validated that all sending partners comply, you can switch to enforce mode to actively reject connections from non-compliant servers. This staged rollout reduces the risk of deliverability issues during transition.

Testing Mode: Observe Without Interruption

When you set mode=testing, your MTA-STS policy logs all connection attempts but doesn’t block any mail. This lets you see which sending systems fail to meet the policy without disrupting delivery.

It’s ideal for rollouts. You can verify whether your email partners, including service providers or third-party senders, support MTA-STS before enforcing it. The goal is to identify gaps early—like outdated mail servers or misconfigured TLS settings—without breaking real communication.

The MTA-STS specification explicitly allows this approach, stating that testing mode helps organizations prepare for enforcement safely. It’s an industry-standard practice, supported by providers like Google and Microsoft for SMTP transport validation.

Enforce Mode: Block Non-Compliant Connections

In mode=enforce, your server actively rejects emails from any mail server that doesn’t comply with the MTA-STS policy. This includes servers that don’t support TLS 1.2+, don’t present a valid certificate, or fail to publish the policy file correctly.

Once you switch to enforce mode, you’re no longer accepting connections that don’t meet your security requirements. This reduces the risk of interception, spoofing, and email hijacking.

But enforcement must be deliberate. You should only move to mode=enforce after confirming that all partners—including marketing automation tools, CRM systems, and transactional mailers—support MTA-STS. A single non-compliant party can cause message delivery failures.

For example, if you use SendGrid, HubSpot, or Klaviyo, ensure they’re compliant before enforcing. You can test this using tools like inbox placement testing. Regular monitoring helps catch issues before they affect customers.

Use bulk email verification to clean your list and confirm sender reputation. A strong sending reputation increases the likelihood that your policy will be respected. Remember: MTA-STS isn’t a replacement for SPF, DKIM, and DMARC—it’s a complement. Together, they form a layered defense.

When in doubt, start with testing. Confirm the results. Then enforce. Rushing enforcement without validation is a common cause of deliverability spikes during rollouts.

MTA-STS DNS Record: How to Add It Correctly

You add the MTA-STS DNS record at _mta-sts.yourdomain.com with the value v=STSv1; id=20260405. The id field must be a unique string—use a timestamp or version number—without spaces or special characters. This helps mail servers verify policy updates and prevent MITM attacks.

Step-by-step DNS record setup

Log in to your domain’s DNS management portal (like Cloudflare, AWS Route 53, or your registrar’s dashboard).
Create a TXT record with the name _mta-sts.yourdomain.com. Replace yourdomain.com with your actual domain.
Set the value to v=STSv1; id=20260405. Use a unique identifier—like a date (e.g., 20251231) or a version (e.g., v1.2).
Ensure the ID contains only letters, numbers, and hyphens. No spaces, underscores, or symbols.
Do not add trailing spaces or extra quotes around the value—DNS is strict.
Save the record. Propagation can take a few minutes to several hours.

Verification and policy management

After setting up the DNS record, test it using tools like MxToolbox or RFC 8461 (the official specification) to confirm it resolves correctly.

When you update your policy, change the id value. This signals to receiving servers that a new policy is in effect. The system uses the ID to validate freshness and prevent replay attacks.

Keep the record live even after you start enforcing TLS. MTA-STS is not a replacement for SPF, DKIM, or DMARC—but it reinforces them. For best results, implement all three.

If you're checking email lists before sending, tools like bulk verification can help ensure your sending list is clean and reduces the risk of hitting policies tied to poor sender reputation.

MTA-STS Hosting Policy: Where to Store the File and How to Secure It

You must host your MTA-STS policy file at /yourdomain.com/.well-known/mta-sts.txt on an HTTPS-enabled web server, accessible publicly without authentication or redirects, and with caching disabled to ensure updates propagate immediately. The file must be readable by any mail server validating your policy.

Place the File on Your HTTPS Web Server

MTA-STS relies on DNS lookups followed by an HTTP request, so the file must be served over HTTPS. This isn’t optional—non-HTTPS servers will cause verification failures, even if the file exists. Let’s be clear: if your site doesn’t support HTTPS, MTA-STS will not work. Use a trusted certificate from a public CA to avoid chain validation errors.

Once your HTTPS endpoint is live, place the file at https://yourdomain.com/.well-known/mta-sts.txt. This path is standardized in RFC 8461: the Internet Engineering Task Force defines the exact location and format. You can verify compliance by checking your file against the official specification RFC 8461.

Ensure Accessibility and Timely Updates

The file must be publicly accessible—no login walls, no IP restrictions, no redirects. A redirect can cause the policy to be ignored entirely. If you use a CDN, ensure it serves the file with no caching or with a very short TTL (shortest possible). Disabling cache is critical: MTA-STS policies can change during security incidents, and old versions must not persist.

Some hosting providers, like CloudFront or Akamai, allow cache control headers. Set Cache-Control: no-cache, no-store, must-revalidate and Expires: 0 to prevent stale copies. This ensures the latest policy is fetched on each mail server request, keeping your security posture current.

If you’re testing the setup, use MxToolbox to validate your MTA-STS policy via their diagnostic tools. It checks the file path, HTTPS status, and header compliance.

For teams managing large email lists or running automated sends, you’ll want to verify the health of your domain's delivery setup. Before deploying MTA-STS, test your entire workflow. Use bulk verification to clean your list and ensure only valid, deliverable addresses remain. That way, you’re not locking down a flawed email infrastructure. Your MTA-STS policy isn’t just a config—it’s part of your sender reputation. Keep it clean, correct, and always up to date.

Common MTA-STS Misconfigurations to Avoid

You might think setting up MTA-STS is straightforward, but small mistakes like the wrong file path, missing the v=STSv1 prefix, or using testing mode incorrectly can break encryption enforcement. These errors cause delayed or failed TLS handshakes, increasing the risk of intercepts. For context, the IETF’s RFC 8461 specifies the exact format and placement—double-checking against it avoids 90% of common issues.

File Location and DNS Record Basics

Place the MTA-STS policy file at /.well-known/mta-sts.txt, not /mta-sts.txt. Misplacing it breaks discovery and prevents email clients from finding the policy.
Always start your DNS TXT record with v=STSv1. Omitting this prefix means the record won’t be recognized, and MTA-STS won’t activate, even if the file is otherwise correct.
Don’t rely on tools that auto-generate the DNS record without validating the full format. Use an authoritative source like the IETF’s RFC 8461 to verify syntax.

Mode and Accessibility Pitfalls

Don’t use mode=none or mode=testing in production. These modes disable TLS enforcement. Use mode=enforce once you’ve confirmed the policy is working across your outbound mail stream.
Ensure the policy file is publicly accessible over HTTPS, with no redirects, redirects to non-TLS endpoints, or 4xx/5xx errors. You can test this using MXToolbox or a simple curl command with TLS.
Never serve the file from a private or restricted location—your domain’s public web server must host it. If you’re using a content delivery network, verify it doesn’t block public access.

Let’s be clear: even one misstep here can leave your outbound messages vulnerable. You don’t need to wait for a breach to fix this. Test your setup before going live.

“MTA-STS is one of the few standards that actively secures email in transit. Get it right—or risk sending data in plaintext.”

For teams managing large outbound lists, pre-verification reduces misconfigurations. Use the bulk verification tool to clean your sender list before deploying new policies. It’s not just about delivery—it’s about trust and compliance.

How to Test Your MTA-STS Configuration

Use tools like MxToolbox or the MTA-STS Checker at mta-sts-checker.com to validate your DNS records and policy file. Enter your domain to check HTTPS access, version, and mode setting. Test both testing and enforce modes to confirm your email server behaves as intended. This prevents failed deliveries and improves sender reputation.

Step-by-Step Testing Process

Enter your domain into the MTA-STS Checker. Visit mta-sts-checker.com and input your domain. The tool will query your DNS for the MTA-STS policy record and check for file availability at the expected HTTPS location.
Verify the policy file is accessible via HTTPS. The checker confirms the file is reachable and served over a valid SSL/TLS connection. If the file is unreachable or served over HTTP, your configuration fails validation. Use RFC 8461 as a reference for correct file structure and requirements.
Confirm the correct version and mode are set. Ensure your policy file specifies the proper version (currently v1) and mode (testing or enforce). A mismatch here causes enforcement failures even if the DNS record is correct.
Test both testing and enforce modes. Start with testing to observe behavior without breaking actual deliveries. Once confirmed, switch to enforce. Use the checker again to validate the transition. This mimics the real-world rollout process used by large senders.
Check for common errors in the output. Look for red flags like “HTTP 4xx/5xx,” “invalid TLS,” “missing policy file,” or “incorrect version.” These indicate issues in DNS, HTTPS setup, or file content. Fix one layer at a time.

What to Watch For

If you’re seeing inconsistent results across tools, double-check your DNS TTL and allow time for propagation. Some tools cache responses for up to 24 hours. Ensure the HTTPS server serving the policy file is not blocking crawler traffic or requiring authentication.

Proper MTA-STS setup reduces the risk of spoofing and supports modern email security standards. It also signals to receivers that you follow best practices — a signal that can impact inbox placement over time. For teams managing large email lists, combining this with real-time verification can further reduce bounce rates and improve deliverability. If you’re building or maintaining email campaigns, validating your policy is a critical step.

For businesses deploying email at scale, tools like bulk verification help catch invalid addresses before sending. The verification API integrates directly into workflows to ensure only reliable addresses are used. Pairing policy validation with list hygiene gives you the most reliable, traceable delivery path possible.

Why MTA-STS Is a Must for Modern Email Infrastructure

Large email providers now require MTA-STS for high-volume senders, making it a foundational part of modern email infrastructure. Without it, your domain risks being excluded from secure mail exchanges.

MTA-STS blocks unauthorized relaying and protects against phishing and man-in-the-middle attacks by enforcing encrypted TLS connections. It also strengthens sender reputation, directly supporting compliance with email security standards like DMARC and SPF.

Even if enforcement isn't immediate, adopting MTA-STS early future-proofs your domain. Policy shifts are common, and readiness now avoids disruption later.

Sources

By early 2026, 937,931 of 1.8 million analyzed domains had valid DMARC records — up 79% in three years — but about 56% of them still sit at monitoring-only p=none. — DMARC Report (EasyDMARC 2026 data) (2026)
68% of domains that do have a valid DMARC record still use the non-enforcing p=none policy, leaving them open to spoofing. — Validity (2024)

Keep reading

Ready to put this into practice? Emaillistchecker.io verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What does MTA-STS do for my email sending?

MTA-STS ensures only encrypted connections are accepted from mail servers sending to your domain, reducing interception and spoofing risks.

Can I use MTA-STS with SendGrid or Mailchimp?

Yes, but only if the sending provider supports encrypted TLS sessions and the policy is correctly configured on your domain.

Is MTA-STS required to send emails?

No, but it is increasingly adopted by major providers for high-reputation domains and is becoming a baseline for secure delivery.

How long does it take for MTA-STS to take effect?

After DNS propagation and file activation, it typically takes 24 hours for global servers to adopt the new policy.

What happens if a sending server doesn’t support MTA-STS?

It will be rejected if the policy is set to enforce mode; it may be accepted in testing mode or skipped entirely if not validated.

Can MTA-STS prevent spam or phishing?

It prevents unencrypted relaying and helps verify sender identity but does not block spam content or phishing links directly.

How do I update my MTA-STS policy?

Update the file on your server and change the ID in the DNS TXT record to trigger a version refresh.

Does MTA-STS work with DMARC?

Yes, MTA-STS complements DMARC, DKIM, and SPF by securing the transport layer and verifying sender identity during delivery.

What’s the difference between MTA-STS and DMARC?

MTA-STS secures the transport layer (encryption), while DMARC validates sender authentication and provides reporting.

Can I host the MTA-STS file on a CDN?

Yes, but only if the CDN supports HTTPS and serves the file from the correct path without redirects or access restrictions.