MTA-STS HTTPS Requirements

Why MTA-STS Policy Hosting on mta-sts Subdomain HTTPS Matters for Deliverability

You send emails securely — you use TLS, you monitor bounces, you maintain sender reputation. But if your MTA-STS policy isn’t hosted over HTTPS on the mta-sts subdomain, your encryption efforts are ignored. Receiving servers won’t enforce TLS, and your emails may still flow in plaintext.

MTA-STS is a security protocol that forces email servers to use encrypted TLS connections, blocking fallback to unsecured transmission. But it only works if the policy is reachable via HTTPS with a valid certificate from a trusted CA. Without it, enforcing encryption fails — and deliverability takes a hit.

Think of MTA-STS as a gatekeeper on a secure bridge. If the gatekeeper’s sign (the policy) is behind an unsecured door (HTTP), no one checks your credentials. You must lock the door with a trusted key (HTTPS with valid CA certificate) for the gatekeeper to act.

Key takeaways

MTA-STS policies must be hosted on the mta-sts subdomain and accessible via HTTPS with a certificate from a trusted CA.
Without valid HTTPS, receiving servers ignore the policy, leaving emails vulnerable to interception and reducing trust-based deliverability.
Proper MTA-STS setup improves sender reputation and inbox placement by enforcing encryption at the transport layer.

What Is the mta-sts Subdomain and Why Does It Exist?

The mta-sts subdomain is a dedicated DNS namespace used exclusively to serve MTA-STS policy files via HTTPS. It doesn’t handle email delivery or serve web content—it exists solely to enable secure, authenticated email transport layer negotiation between sending and receiving mail servers. This subdomain must be publicly accessible over HTTPS, with valid SSL/TLS certificates, so any internet-connected host can retrieve the policy file without relying on email-specific protocols.

How It Fits Into the Bigger Picture

MTA-STS (Mail Transfer Agent Strict Transport Security) is designed to enforce encrypted SMTP connections between mail servers. But for that to work, receiving servers need a reliable, tamper-resistant way to fetch the policy that defines how encryption should be enforced. That’s where the mta-sts subdomain comes in—it’s the standardized location where policies are published and retrieved.

Think of it like a public key directory for mail servers: when you send an email to example.com, the receiving server checks https://mta-sts.example.com/.well-known/mta-sts.txt to load the policy. If that file is unreachable or served over HTTP, the MTA-STS enforcement can’t take place, and encryption might fail or be downgraded.

Why HTTPS Is Non-Negotiable

Security is why HTTPS isn’t optional here. Without HTTPS, anyone with network access could intercept or replace the policy file. An attacker could, for example, redirect traffic to an unencrypted connection or even disable encryption entirely. That’s why RFC 8461, the specification for MTA-STS, mandates that the policy file be served over HTTPS with a valid certificate from a trusted CA.

Let’s be clear—this isn’t a website. It’s not running a CMS or serving HTML. It’s a single, plain-text file hosted at a specific path. But it must be accessible just like any public HTTPS endpoint. This is why misconfigurations like certificate errors, incorrect DNS records, or missing .well-known paths are common causes of MTA-STS failures.

For those testing or implementing MTA-STS, tools like MailTester’s inbox placement and bulk verification can help identify whether your domain’s MTA-STS configuration is accessible and correctly formatted. The subdomain, while technical, is a critical piece of the email security stack—and getting it right means fewer fallbacks to unencrypted channels.

How Does MTA-STS Require HTTPS on mta-sts.example.com?

MTA-STS mandates that the policy file on mta-sts.example.com must be served over HTTPS with a valid, publicly trusted TLS certificate. Any HTTP response, self-signed certificate, or expired/invalid certificate will be rejected by compliant mail servers during connection setup—no exceptions. This ensures the policy cannot be intercepted or tampered with while in transit.

Why HTTPS is Non-Negotiable in MTA-STS

MTA-STS was designed to prevent man-in-the-middle attacks on the policy retrieval process. If a server were served over HTTP, an attacker could redirect the policy to a malicious endpoint or modify its content. This would allow an attacker to force TLS fallback or redirect outbound mail to a rogue server, breaking the security chain. The requirement is strict: even on non-standard ports, TLS must be properly configured and validated.

Compliant mail servers, such as those from Google, Microsoft, and Sendinblue, enforce this rule at the SMTP handshake stage. They verify the certificate chain using publicly trusted CAs—like Let's Encrypt, DigiCert, or Sectigo—before accepting any policy. A self-signed certificate, even if it's technically "valid," is not trusted by default and will result in a connection failure.

Let’s say you host your MTA-STS policy on mta-sts.example.com:8443. You can use a non-standard port—some systems use 8443 for internal staging—but the connection still requires a valid, trusted HTTPS certificate. If the certificate is expired, misconfigured, or issued by an untrusted CA, the receiving server will not load the policy, and encryption enforcement will be skipped.

Real-World Implications and Best Practices

When configuring MTA-STS, treat the mta-sts subdomain like any other critical service. Use a wildcard certificate for flexibility, ensure the DNS record (TXT) is correct, and test with tools like MXToolbox or RFC 8461 (the official MTA-STS specification) to validate the setup. Even minor misconfigurations—like a missing intermediate certificate—can result in failed validation.

For teams managing large email programs, verifying the full delivery stack—including MTA-STS—is crucial. You can test how well your domain’s policies hold up in real-world delivery scenarios with MailTester’s inbox placement testing. This gives you visibility into whether your policies are being respected by major inboxes like Gmail, Outlook, and Apple Mail.

Remember: the MTA-STS policy is only effective if every step—from DNS configuration to certificate trust—is flawless. HTTPS isn’t just a preference; it’s the foundation of the protocol’s security model.

What Are the Specific HTTPS Requirements for mta-sts Subdomain?

You must host your MTA-STS policy file on a subdomain (mta-sts.example.com) with a publicly trusted TLS certificate issued by a public CA, valid directly for that exact hostname, serving HTTPS on port 443 without relying on HTTP redirects from the root domain. The policy must be accessible via HTTPS only—no redirects, no fallbacks.

Required HTTPS Configuration for mta-sts

Use a certificate issued by a public Certificate Authority (CA), such as Let’s Encrypt or DigiCert. Self-signed or private CA certificates are not accepted by compliant MTAs.
The certificate must be valid for the exact domain mta-sts.example.com. Wildcards (e.g., *.example.com) or partial matches (e.g., example.com only) are invalid.
HTTPS must be available directly on port 443. The server must not rely on HTTP redirects from the root domain; the mta-sts subdomain must respond over HTTPS without exception.
Ensure your server does not redirect HTTP traffic to HTTPS for the mta-sts subdomain. A redirect breaks MTA-STS policy retrieval, as the policy must be fetched over HTTPS without intermediate HTTP requests.
Verify the certificate chain is complete and trustable by standard operating systems and mail transfer agents. You can test this using MXToolbox or SSL Labs’ SSL Test.

Why This Matters for Email Deliverability

Failure to meet these requirements means your MTA-STS policy cannot be retrieved by receiving servers, leaving your messages unprotected against man-in-the-middle attacks. This reduces your sender reputation and increases the chance of your emails being rejected or marked as suspicious.

MTA-STS is part of the broader email authentication ecosystem. When paired with proper SPF, DKIM, and DMARC setup, it significantly improves inbox placement. You can test how your domain’s entire authentication stack performs using MailTester’s inbox placement tester, which simulates real-world inbox filters.

Let’s be clear: even if your SPF and DKIM are set up perfectly, an improperly configured mta-sts subdomain can still block your inbound TLS connections. The spec is strict by design—this isn’t about convenience, it’s about security.

For teams managing large send volumes, verifying your entire email stack—including MTA-STS policy hosting—is easier with automation. MailTester’s verification API can help you detect misconfigurations across multiple domains at scale.

Step-by-Step: Setting Up HTTPS for mta-sts Subdomain

You must create a DNS A or AAAA record for mta-sts.example.com pointing to your public IP, configure your web server to serve HTTPS on port 443, obtain a valid SSL/TLS certificate from a trusted CA like Let’s Encrypt, install it, and place the mta-sts.txt policy file at https://mta-sts.example.com/mta-sts.txt. This ensures email clients can securely validate your MTA-STS policy and enforce encryption.

Configure DNS and Server

Create an A or AAAA record: Point mta-sts.example.com to your web server's IPv4 (A record) or IPv6 (AAAA record) public IP address. This tells the internet where to reach your policy endpoint.
Set up HTTPS listener: Configure your web server (Apache, Nginx, etc.) to accept HTTPS requests on port 443 for mta-sts.example.com. The server must not redirect or respond with 4xx/5xx errors.
Obtain and install a certificate: Use a trusted Certificate Authority like Let’s Encrypt. Tools like Certbot automate certificate issuance, validation, and installation. Your certificate must cover mta-sts.example.com exactly, without wildcards or mismatched names.

Test and Deploy Policy

Verify HTTPS connectivity: Test the setup using curl -I https://mta-sts.example.com or openssl s_client -connect mta-sts.example.com:443. Ensure the response returns HTTP 200 and includes a valid certificate chain.
Upload the mta-sts.txt policy: Place the policy file in the root directory of your HTTPS server. The file must be named exactly mta-sts.txt and contain valid MTA-STS policy syntax.
Confirm accessibility: Access https://mta-sts.example.com/mta-sts.txt in a browser or via curl. The file should load without redirects, authentication prompts, or HTTP errors. Check it via tools like MXToolbox or RFC 8461 for correct formatting.

Failure at any step breaks the chain. A misconfigured DNS or invalid certificate prevents email clients from enforcing TLS. Even a redirect to www or example.com invalidates the policy.

The 3 steps described in “Configure DNS and Server”, in order.

For teams building or maintaining email infrastructure, testing your MTA-STS setup is critical. You can verify your entire email flow, including policy reachability, with tools that simulate inbound mail behavior. MailTester’s inbox placement test checks how your domains perform across major email providers, including TLS and policy validation.

Once live, your domain gains stronger encryption guarantees. This is especially important for regulated industries or high-volume senders where deliverability depends on trust signals.

Common HTTPS Misconfigurations That Break MTA-STS

You’re not just hosting an MTA-STS policy file—you’re serving it over HTTPS with strict rules. If your mta-sts.example.com certificate is wildcard, redirects HTTP to HTTPS, or has a broken chain, mail servers reject your policy. This breaks alignment and leaves your outbound messages vulnerable to rejection or routing delays. RFC 8461 mandates direct, secure access—no exceptions.

Wildcard Certificates Are Not Enough

Using a wildcard certificate like *.example.com fails when the exact hostname mta-sts.example.com is required.
Even if the SSL handshake succeeds, DNS validation and certificate matching will fail if the CN or SAN doesn’t match the exact subdomain.
Always issue a dedicated certificate for mta-sts.example.com—this is non-negotiable.

Redirects and Chain Issues Break Policy Retrieval

HTTP-to-HTTPS redirects break MTA-STS policy retrieval—the client must receive the policy file directly over HTTPS.
Using a reverse proxy that redirects or strips headers (like Host or Connection) can cause the policy to be unavailable or misread.
Ensure your certificate chain includes all required intermediates; missing CAs are rejected by mail servers—even if the end certificate appears valid.
Test your config with MXToolbox or DigiCert’s SSL checker to catch chain or redirect issues early.
Verify the policy file is served directly at https://mta-sts.example.com/.well-known/mta-sts.txt with a 200 response, no redirects.

Let’s be clear: MTA-STS requires a direct, secure, and unmodified path. Any deviation, no matter how small, breaks the chain of trust. Tools like inbox placement testing can help you validate the entire delivery path, including MTA-STS behavior, but only if the policy is correctly hosted.

How to Test Your mta-sts Policy and HTTPS Setup

You can validate your mta-sts policy and HTTPS configuration by checking the file’s accessibility via HTTPS, confirming a 200 OK response with the correct content type, ensuring no redirects, and verifying the certificate chain. Use tools like MXToolbox and curl to test in real time.

Step-by-Step Validation Process

Go to MXToolbox’s MTA-STS Check and enter your domain. It will confirm whether the mta-sts.txt file is publicly accessible at https://mta-sts.example.com and if the HTTPS connection is properly configured.
Run the following command in your terminal: curl -I https://mta-sts.example.com/mta-sts.txt. This retrieves the HTTP response headers without the full file, which is ideal for quick testing.
Check that the response includes: HTTP/2 200 OK and Content-Type: text/plain; charset=utf-8. These are required for compliance with the MTA-STS specification (RFC 8461).
Look for any 3xx redirect responses (like 301 or 302). If your domain redirects to another URL, the policy will fail validation. The MTA-STS policy must be available directly at the mta-sts subdomain.
Verify your certificate is issued by a trusted CA and chains correctly. Use Qualys SSL Labs’ SSL Test to analyze the full certificate chain and ensure it’s not self-signed or expired.

Common Pitfalls to Avoid

Many organizations fail MTA-STS checks due to outdated or misconfigured DNS records, incorrect file placement, or using HTTP instead of HTTPS. Even a single redirect breaks compliance.

Use a real HTTPS endpoint. Self-signed certificates or missing intermediate certificates will result in trust failures. This includes checking that your server supports modern TLS versions, especially TLS 1.2 or higher.

If you’re unsure, test with a free tool like the MailTester Inbox Placement Tester, which simulates real-world email delivery scenarios and surfaces issues with policy setup, TLS, and deliverability signals.

MTA-STS is not optional for large-scale email senders aiming for high inbox placement. The policy only works if it’s served securely and consistently.

Once your setup passes all checks, you’re ready to enforce policy enforcement in your outbound mail flow. This increases trust, reduces spam filtering, and improves long-term deliverability.

What Happens If Your mta-sts HTTPS Policy Is Invalid?

If your mta-sts HTTPS policy is invalid—due to certificate errors, misconfigured HTTPS, or a non-existent policy file—receiving mail servers can't verify your TLS setup. They’ll fall back to non-TLS connections, leaving your emails vulnerable and signaling poor security hygiene. This weakens your sender reputation and increases your risk of being blocked by major platforms like Microsoft 365 and Gmail, which treat TLS enforcement as a mandatory security signal.

Why Invalid Policies Matter to Modern Email Infrastructure

When a receiving server checks your MTA-STS policy and finds it invalid, it treats your enforcement requirement as untrusted. It doesn’t just ignore it—it defaults to connecting without TLS, which reduces overall encryption in the email flow. This isn’t just a technical hiccup; it’s a clear signal to inbox providers that your sending practices don’t meet industry-standard security requirements.

For email services like Gmail and Microsoft 365, TLS enforcement is more than a checkbox. It’s a known factor in inbox placement decisions. According to the MTA-STS standard (RFC 8680), strict enforcement is intended to ensure that all mail is encrypted in transit. If your policy is invalid or unreachable, the receiving server cannot enforce that standard—and may downgrade your delivery priority accordingly.

No Enforcement, But Strong Expectations

There’s no built-in penalty for an invalid MTA-STS policy—no automated blacklisting or hard failure. But that doesn’t mean it’s harmless. In practice, systems like Google’s and Microsoft’s use a broad set of data points—including TLS support, DNS records, and historical sending behavior—to determine whether to deliver or quarantine a message.

Even if your policy exists, a misconfigured HTTPS setup (e.g., a self-signed certificate or expired cert) will cause the verification to fail. The outcome? Your domain loses a layer of trust. This matters especially when you're sending at scale—high volumes of mail with weak or unverified encryption raise red flags with both spam filters and reputation systems.

Let’s be clear: compliance isn’t optional anymore. MTA-STS is an established practice within enterprise email flows. Tools like inbox placement testing or bulk email list verification can help you check if your domains are properly configured and whether policies like MTA-STS are accessible and valid—before your messages hit the inbox, or worse, the spam folder.

How MailTester Helps You Verify MTA-STS Readiness

You can audit your email list for domains with properly configured MTA-STS policies using MailTester’s bulk verification API. It checks DNS records, ensures HTTPS is available on the mta-sts subdomain, and validates access to the policy file in real time—no guesswork, no delays. This helps you catch misconfigurations before they block encrypted mail.

Check Real-Time Policy and HTTPS Configuration

Let’s say you're preparing to enforce MTA-STS across your outbound traffic. You need more than just a DNS record—you need the policy file to be accessible over HTTPS on mta-sts.yourdomain.com. MailTester’s API checks this exact setup in real time, confirming not just the existence of the TXT record, but that the domain resolves, the certificate is valid, and the policy file loads correctly. This includes testing the mta-sts subdomain explicitly, so you don’t miss edge cases.

MTA-STS requires strict HTTPS compliance—no redirects, no mixed content, and a valid certificate. MailTester verifies these conditions during each check. For example, if a domain uses a self-signed certificate or has an expired SSL cert, the verification fails. This aligns with RFC 8461, which defines MTA-STS behavior and the need for secure transport.

“The MTA-STS policy file must be served over HTTPS with a valid certificate to be trusted by receiving mail servers.” — IETF RFC 8461

Interpret Results with In-App AI Assistance

After scanning your list, you’ll see verdicts like “valid,” “invalid,” or “risky”—but understanding why requires context. That’s where MailTester’s in-app AI assistant comes in. It doesn’t just return a result; it explains anomalies like expired certs, missing policy files, or DNS TTL mismatches. It flags patterns—like 90% of domains failing HTTPS—but doesn’t assume. You stay the decision-maker.

Use the bulk verification tool to audit large lists, or integrate the real-time API for automated checks in your onboarding or compliance workflow. Test individual domains like mta-sts.example.com with precision, even in staging or beta environments. This isn’t just about avoiding bounces—it’s about preparing for future encryption requirements in SMTP delivery.

MTA-STS isn’t just about sending mail securely. It’s about ensuring your domain is ready to participate in a trusted, encrypted email ecosystem. With MailTester, you verify readiness—not just in theory, but in practice, across every domain in your list.

Best Practices to Maintain MTA-STS Integrity Over Time

You need consistent monitoring, automated renewal, and active verification to keep your MTA-STS policy effective. Without it, your SMTP traffic can fall back to unencrypted delivery, increasing vulnerability to spoofing, interception, and poor inbox placement. Treat MTA-STS not as a one-time setup but as an ongoing security control—like TLS certificates or SPF records. Let’s walk through the must-do practices for lasting integrity.

Automate Renewal and Monitor for Policy Drift

Use automated scripts to renew your mta-sts subdomain certificate, especially if using Let’s Encrypt. Manual renewal risks outages during expiration windows.
Set up daily or hourly checks to ensure the policy file at mta-sts.yourdomain.com/.well-known/mta-sts.txt hasn’t been overwritten, deleted, or corrupted.
Integrate policy file validation into your CI/CD or DNS management workflow so changes are tested before deployment.

Monitor Infrastructure and Reassess Annually

Include mta-sts subdomain HTTPS availability in your infrastructure alerting system. A broken HTTPS connection breaks MTA-STS enforcement.
Use tools like MXToolbox or RFC 8461 to validate policy file syntax and HTTPS reachability regularly.
Review MTA-STS compliance annually or after any major TLS/SSL policy, server, or mail gateway change—you can’t assume stability over time.
Test your policy’s real-world impact using inbox placement tools. MailTester’s inbox placement service can help confirm if your policy improves delivery rates and reduces spam filtering.

An incorrectly configured or expired MTA-STS policy doesn’t just fail silently—it can degrade sender reputation and reduce inbox placement by up to 20% in some cases. It’s not about being perfect; it’s about being consistently correct.

Remember: MTA-STS is not a checkbox. It’s a long-term commitment to encrypted, authenticated SMTP delivery. By automating renewal, validating file integrity, and reviewing compliance regularly, you reduce risk and improve deliverability. If you're managing large lists, use MailTester’s bulk verification to catch invalid or non-STS-ready domains before they cause issues.

Final Note: MTA-STS Is Not Optional — It’s a Deliverability Requirement

MTA-STS is no longer a niche security feature. It’s a fundamental requirement for inbox placement with major providers like Google and Microsoft.

Domains that fail to host a valid MTA-STS policy on the mta-sts subdomain with HTTPS enforcement face degraded deliverability and risk reputation penalties, especially under stricter inbox filtering policies.

Deploying MTA-STS correctly—ensuring HTTPS is properly configured and policies are publicly accessible—is a minimal investment with significant returns in trust, consistency, and delivery reliability.

Sources

DMARC adoption among top domains surged 75% between 2023 and 2025 — from 27.2% to 47.7% — in the wake of Google and Yahoo's bulk-sender authentication requirements. — EasyDMARC 2025 DMARC Adoption Report (2025)
Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)

Keep reading

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

Frequently asked questions

Can I use a wildcard certificate for mta-sts.example.com?

No. The certificate must be issued specifically for mta-sts.example.com. Wildcard certificates like *.example.com are not valid for policy delivery.

Do I need to run a web server just for mta-sts.example.com?

Yes. The mta-sts subdomain must serve the policy file via HTTPS. A file-only host or DNS-only config will not work.

What happens if my mta-sts policy file is missing or returns a 404?

Receiving servers will not enforce TLS and may skip enforcement or treat your domain as not compliant, affecting deliverability.

Can I use HTTP at mta-sts.example.com with a redirect to HTTPS?

No. Redirection is not allowed. The policy file must be served directly over HTTPS with no intermediate redirects.

How often should I test my MTA-STS policy?

Test at initial setup and after any SSL/TLS or DNS change. Quarterly reviews are recommended for long-term consistency.

Does MailTester support MTA-STS policy verification?

Yes. MailTester’s bulk and real-time verifications include DNS and HTTPS checks for mta-sts policy availability and correct configuration.

What if my domain doesn’t use MTA-STS — do I still need HTTPS?

HTTPS is not required for all subdomains, but having it for mta-sts.example.com makes your mail security stronger and future-ready.

Can a misconfigured mta-sts policy harm my sender reputation?

Indirectly yes. While no penalty is issued for MTA-STS failures, non-compliance reduces trust signals, which may impact inbox placement over time.

Is MTA-STS used by Gmail and Microsoft 365?

Yes. Both services support MTA-STS enforcement and evaluate policy availability as part of sender reputation and email security.

What happens if my mta-sts.txt file has syntax errors?

Receiving servers may fail to parse the policy. Ensure the file contains only valid directives and follows the RFC 8659 specification.