MTA-STS Setup & DNS Guide [2026]

What Is MTA-STS?

MTA-STS (Mail Transfer Agent Strict Transport Security) is a protocol that forces sending mail servers to deliver email to your domain over encrypted TLS connections. Without MTA-STS, an attacker positioned on the network can intercept the initial SMTP connection and strip away the TLS upgrade command — a “downgrade attack” that forces the message to be transmitted in plain text, where the attacker can read or modify it.

MTA-STS closes this gap by publishing a policy that instructs senders: “Always use TLS when delivering to this domain. If TLS fails, reject the message instead of falling back to unencrypted delivery.”

The protocol is defined in RFC 8461 and works alongside TLS-RPT to provide visibility into TLS delivery failures.

Why MTA-STS Matters: Preventing Downgrade Attacks

SMTP (the protocol mail servers use to send messages to each other) was designed in 1982, before encryption was a priority. TLS support was added later via the STARTTLS extension, but it’s “opportunistic” by default: servers try to use TLS, but if it doesn’t work, they fall back to sending the message unencrypted.

This creates a vulnerability:

1. Sending server connects to your mail server over plain TCP
2. Your server advertises STARTTLS support in its greeting
3. An attacker intercepts the connection and removes the STARTTLS capability from the greeting
4. The sender thinks your server doesn’t support TLS
5. The message is delivered in plain text — readable and modifiable by the attacker

MTA-STS prevents this by moving the “does this domain require TLS?” decision out of the SMTP conversation (which the attacker controls) and into a signed, cached policy file that the sender fetches over HTTPS before attempting delivery.

Real-world impact: Email in transit can contain sensitive information — password reset links, financial statements, medical records, business contracts. TLS downgrade attacks have been observed in the wild, particularly in jurisdictions with state-level network surveillance.

How MTA-STS Works (RFC 8461)

MTA-STS uses two components to signal your TLS requirement:

1. DNS TXT Record

A TXT record published at _mta-sts.yourdomain.com signals that an MTA-STS policy exists:

_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20260301T120000"

The id field is critical: senders cache your policy file for the duration specified in max_age. When they see a new id value in DNS, they know to fetch the updated policy.

Best practice: Use a timestamp format for the id field (e.g., YYYYMMDDTHHMMSS) so you can track when policies were published.

2. Policy File (HTTPS)

The actual policy is served over HTTPS at:

https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

Example policy file:

version: STSv1
mode: enforce
mx: mail.example.com
mx: backup.example.com
max_age: 604800

You can specify multiple mx: entries — one per line — to list all valid mail servers for your domain.

Critical requirement: The policy file must be served over HTTPS with a valid certificate. The mta-sts subdomain itself needs its own HTTPS certificate (wildcard certificates covering *.yourdomain.com work).

The MTA-STS DNS Record

The MTA-STS DNS record is a simple TXT record that acts as a pointer to your policy file. It doesn’t contain policy directives itself — its job is to signal “this domain has an MTA-STS policy” and provide a version identifier so senders know when to refresh their cached policy.

DNS Record Format

_mta-sts.yourdomain.com.  IN  TXT  "v=STSv1; id=POLICY_ID"

Required fields:

• v=STSv1 — Version tag (must be exactly STSv1)
• id= — Policy identifier (alphanumeric string up to 32 characters)

Policy ID Best Practices

The id field can be any alphanumeric string, but recommended formats include:

• Timestamp: id=20260301T120000 (ISO 8601-like format)
• Semantic versioning: id=v2 or id=policy-v3
• Date-based: id=2026-03-01

When you update your policy file, increment the id value in DNS. Sending servers cache your policy for max_age seconds but will re-fetch it early if they see a different id in DNS.

Example DNS Records

Google Workspace:

_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20260301"

Microsoft 365:

_mta-sts.example.com.  IN  TXT  "v=STSv1; id=2026-03-01-01"

Self-Hosted Mail Server:

_mta-sts.example.com.  IN  TXT  "v=STSv1; id=enforce-v1"

How to Create the DNS Record

Most DNS providers support TXT records. The exact steps vary, but the general process is:

1. Log in to your DNS provider’s control panel
2. Navigate to DNS management for your domain
3. Create a new TXT record with:
   • Name/Host: _mta-sts (some providers want _mta-sts.yourdomain.com.)
   • Type: TXT
   • Value: v=STSv1; id=YOUR_ID_HERE
   • TTL: 3600 (1 hour) or your provider’s default
4. Save the record

Verification: Use dig or nslookup to confirm the record is published:

dig _mta-sts.example.com TXT +short

Expected output:

"v=STSv1; id=20260301"

The MTA-STS Policy File

The policy file is a plain-text file served over HTTPS that contains the actual enforcement directives. It must be accessible at:

https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

Policy File Structure

version: STSv1
mode: enforce
mx: mail.example.com
mx: backup.example.com
max_age: 604800

Field details:

• version: STSv1 (required) — Policy version. Always STSv1 for RFC 8461.
• mode: (required) — Enforcement mode: testing, enforce, or none.
• mx: (required, at least one) — Allowed mail server hostnames. Must match your MX record hostnames exactly (including subdomains).
• max_age: (required) — Cache duration in seconds. Senders will cache this policy for this long before re-checking DNS.

Policy Modes Explained

Recommended rollout path:

1. Start with mode: testing and a short max_age: 86400 (1 day)
2. Monitor TLS-RPT reports for delivery failures
3. Fix any certificate or configuration issues
4. Switch to mode: enforce after 1-2 weeks of clean TLS-RPT reports
5. Increase max_age to 604800 (7 days) or longer

MX Hostname Matching

The mx: entries in your policy must match the hostnames in your MX DNS records — not the IP addresses, not the domain name, but the MX record target hostnames.

Example: If your MX records are:

example.com.  IN  MX  10  mail.example.com.
example.com.  IN  MX  20  backup.example.com.

Your policy file must list:

mx: mail.example.com
mx: backup.example.com

Wildcard support: RFC 8461 allows wildcard MX entries like mx: *.example.com, but not all senders handle wildcards correctly. Use explicit hostnames for maximum compatibility.

Max Age Recommendations

Trade-off: Longer max_age reduces DNS lookups and policy fetches (good for performance) but increases the time it takes for policy changes to propagate (bad for agility).

Example Policy Files

Google Workspace:

version: STSv1
mode: enforce
mx: smtp.google.com
max_age: 604800

Microsoft 365:

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

Self-Hosted (Multiple MX):

version: STSv1
mode: enforce
mx: mail1.example.com
mx: mail2.example.com
mx: mail3.example.com
max_age: 2592000

MTA-STS Policy Modes (testing, enforce, none)

MTA-STS supports three policy modes, allowing you to gradually roll out enforcement without breaking email delivery.

Mode: testing

In testing mode, sending servers check your TLS configuration but do not reject messages if TLS fails. Instead, they:

1. Attempt TLS delivery
2. If TLS succeeds, deliver the message over TLS
3. If TLS fails, deliver the message anyway (potentially unencrypted)
4. Report the failure via TLS-RPT

When to use testing mode:

• Initial MTA-STS deployment
• You’re unsure if all your mail servers have valid TLS certificates
• You want to collect TLS-RPT failure data before enforcing

Duration: Run testing mode for at least 7 days (ideally 14-30 days) to catch intermittent TLS failures.

Mode: enforce

In enforce mode, sending servers require TLS. If TLS fails for any reason, the message is rejected and the sender receives a delivery failure notice.

When to use enforce mode:

• After a successful testing phase with clean TLS-RPT reports
• You’ve verified all your MX servers have valid, matching certificates
• You’re confident in your TLS infrastructure

Risk: If your certificates expire or become misconfigured, you’ll stop receiving email. Monitor TLS-RPT reports and set up certificate expiration alerts.

Mode: none

In none mode, MTA-STS is effectively disabled. Senders will not enforce TLS even if the policy file exists.

When to use none mode:

• You need to temporarily disable MTA-STS without deleting DNS records
• You’re troubleshooting a TLS issue and want to revert to opportunistic TLS
• You’re decommissioning MTA-STS

Note: Setting mode: none in the policy file is different from deleting the DNS record. With mode: none, senders will still fetch the policy (and cache it for max_age), but they won’t enforce TLS. Deleting the DNS record signals “no MTA-STS policy exists.”

How to Set Up MTA-STS (Step-by-Step)

Setting up MTA-STS requires configuring DNS, hosting a policy file, and ensuring your mail servers have valid TLS certificates.

Prerequisites

Before setting up MTA-STS, verify:

1. Your mail servers support TLS. Most modern mail servers (Postfix, Exim, Microsoft 365, Google Workspace) support TLS by default.
2. Your mail servers have valid TLS certificates. The certificate’s Subject Alternative Names (SAN) must include the MX record hostnames.
3. You can host an HTTPS file. You’ll need a web server or hosting service that can serve the policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt.

Step 1: Create the Policy File

Create a plain-text file named mta-sts.txt with the following content:

version: STSv1
mode: testing
mx: YOUR_MX_HOSTNAME_HERE
max_age: 86400

Replace YOUR_MX_HOSTNAME_HERE with your actual MX record hostname(s). If you have multiple MX records, add one mx: line per hostname. You can also use our MTA-STS policy generator to build a valid policy file for your domain automatically.

Step 2: Host the Policy File

The policy file must be accessible at:

https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

Options for hosting:

• Static web server: Upload the file to a web server under the .well-known directory
• Cloudflare Pages / Netlify / Vercel: Deploy a static site with the .well-known/mta-sts.txt file
• Hosted MTA-STS service: Use a third-party service (like DMARCguard’s hosted MTA-STS) that manages the subdomain and policy file for you

HTTPS requirement: The mta-sts subdomain must have a valid HTTPS certificate. You can use:

• A wildcard certificate covering *.yourdomain.com
• A dedicated certificate for mta-sts.yourdomain.com
• Let’s Encrypt (free, automated certificates)

Verification: Open https://mta-sts.yourdomain.com/.well-known/mta-sts.txt in a browser. You should see the policy file contents (not a 404 or certificate error).

Step 3: Create the DNS TXT Record

Add a TXT record at _mta-sts.yourdomain.com:

v=STSv1; id=20260301

(Adjust the id value to match your deployment date or versioning scheme.)

Step 4: Verify the Configuration

Use an MTA-STS checker to validate your setup. The checker should confirm:

• DNS TXT record is present and valid
• Policy file is accessible over HTTPS
• MX hostnames in the policy match your actual MX records
• TLS certificates are valid

Step 5: Monitor TLS-RPT Reports

Enable TLS-RPT to receive reports about TLS delivery failures. This is essential during the testing phase — you’ll see which senders are failing to establish TLS and why.

Step 6: Switch to Enforce Mode

After monitoring testing mode for 7-14 days with no TLS failures, update your policy file to:

version: STSv1
mode: enforce
mx: YOUR_MX_HOSTNAME_HERE
max_age: 604800

Don’t forget: Update the id field in your DNS TXT record whenever you change the policy file. This signals to senders that they should re-fetch the policy.

MTA-STS for Google Workspace

Google Workspace supports receiving mail over TLS but does not automatically publish MTA-STS policies for customer domains. You must configure MTA-STS yourself.

Google Workspace MX Records

Google Workspace uses MX records pointing to aspmx.l.google.com and several alt servers:

example.com.  IN  MX  1   aspmx.l.google.com.
example.com.  IN  MX  5   alt1.aspmx.l.google.com.
example.com.  IN  MX  5   alt2.aspmx.l.google.com.
example.com.  IN  MX  10  alt3.aspmx.l.google.com.
example.com.  IN  MX  10  alt4.aspmx.l.google.com.

Google Workspace MTA-STS Policy

Your MTA-STS policy file should list only the primary MX hostname:

version: STSv1
mode: enforce
mx: aspmx.l.google.com
max_age: 604800

Why only the primary MX? Google’s TLS certificates cover aspmx.l.google.com and the alt servers, but the certificate validation is most reliable when senders connect to the primary. In practice, senders will try all MX records in order, and all Google Workspace MX servers support TLS.

Alternative (belt-and-suspenders): You can list all MX hostnames if you want strict enforcement:

version: STSv1
mode: enforce
mx: aspmx.l.google.com
mx: alt1.aspmx.l.google.com
mx: alt2.aspmx.l.google.com
mx: alt3.aspmx.l.google.com
mx: alt4.aspmx.l.google.com
max_age: 604800

Google Workspace Setup Checklist

1. ✓ Verify your MX records point to Google’s servers
2. ✓ Create the policy file with mx: aspmx.l.google.com
3. ✓ Host the policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
4. ✓ Add the DNS TXT record at _mta-sts.yourdomain.com
5. ✓ Start with mode: testing for 7-14 days
6. ✓ Switch to mode: enforce after monitoring TLS-RPT reports

MTA-STS for Microsoft 365

Microsoft 365 (formerly Office 365) supports TLS for inbound mail but requires manual MTA-STS configuration.

Microsoft 365 MX Records

Microsoft 365 uses MX records pointing to *.mail.protection.outlook.com:

example.com.  IN  MX  0  example-com.mail.protection.outlook.com.

(The exact hostname varies based on your tenant name.)

Microsoft 365 MTA-STS Policy

Your policy file should list your Microsoft 365 MX hostname:

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

Replace example-com with your actual MX record hostname.

Certificate note: Microsoft’s mail servers have valid certificates for *.mail.protection.outlook.com, so the TLS handshake will succeed for senders that support MTA-STS.

Microsoft 365 Setup Checklist

1. ✓ Find your MX record hostname (check your DNS or Microsoft 365 admin console)
2. ✓ Create the policy file with mx: your-tenant.mail.protection.outlook.com
3. ✓ Host the policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
4. ✓ Add the DNS TXT record at _mta-sts.yourdomain.com
5. ✓ Start with mode: testing for 7-14 days
6. ✓ Switch to mode: enforce after monitoring TLS-RPT reports

Exchange Online Considerations

Exchange Online is Microsoft 365’s mail service. MTA-STS configuration is the same as above — there’s no separate setup for Exchange Online vs. Microsoft 365.

MTA-STS for Self-Hosted Mail Servers (Postfix, Exim)

If you run your own mail server, setting up MTA-STS requires ensuring your server has a valid TLS certificate and publishing the policy.

Postfix

Postfix supports TLS by default. Verify your configuration includes:

smtpd_tls_cert_file = /etc/ssl/certs/mail.example.com.crt
smtpd_tls_key_file = /etc/ssl/private/mail.example.com.key
smtpd_tls_security_level = may
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

Certificate requirements:

• The certificate’s Common Name (CN) or Subject Alternative Names (SAN) must include your MX record hostname (e.g., mail.example.com)
• Use a certificate from a trusted CA (Let’s Encrypt is free and widely trusted)

Postfix MTA-STS policy example:

If your MX record is mail.example.com, your policy file should be:

version: STSv1
mode: enforce
mx: mail.example.com
max_age: 604800

Outbound MTA-STS support (Postfix as sender):

Postfix 3.4+ includes built-in MTA-STS support. Enable it with:

smtp_tls_policy_maps = socketmap:inet:127.0.0.1:8461:sts

You’ll need a separate daemon (like postfix-mta-sts-resolver) to fetch and cache MTA-STS policies. This is optional — it’s only needed if you want your Postfix server to respect other domains’ MTA-STS policies when sending mail.

Exim

Exim supports TLS with the following configuration:

tls_certificate = /etc/ssl/certs/mail.example.com.crt
tls_privatekey = /etc/ssl/private/mail.example.com.key
tls_advertise_hosts = *

Certificate requirements: Same as Postfix — the certificate must match your MX hostname.

Exim MTA-STS policy example:

version: STSv1
mode: enforce
mx: mail.example.com
max_age: 604800

Outbound MTA-STS support (Exim as sender):

Exim 4.94+ has experimental MTA-STS support. As of 2026, it’s not production-ready. If you need outbound MTA-STS enforcement, consider using a dedicated MTA-STS resolver or switching to Postfix.

Self-Hosted Setup Checklist

1. ✓ Verify your mail server supports TLS (Postfix, Exim, Sendmail all support it)
2. ✓ Obtain a valid TLS certificate for your MX hostname (use Let’s Encrypt)
3. ✓ Configure your mail server to use the certificate
4. ✓ Test TLS with openssl s_client -starttls smtp -connect mail.example.com:25
5. ✓ Create the MTA-STS policy file with your MX hostname
6. ✓ Host the policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
7. ✓ Add the DNS TXT record at _mta-sts.yourdomain.com
8. ✓ Start with mode: testing and monitor TLS-RPT reports
9. ✓ Switch to mode: enforce after successful testing

Hosted MTA-STS Solutions

Managing the mta-sts subdomain, HTTPS certificate, and policy file can be complex — especially for organizations without a dedicated web hosting infrastructure.

Hosted MTA-STS services handle this for you:

1. You delegate the mta-sts subdomain to the service (via CNAME)
2. The service hosts the policy file with a valid HTTPS certificate
3. You update your policy via a web UI or API
4. The service manages certificate renewals, policy versioning, and HTTPS hosting

Benefits:

• No need to manage HTTPS certificates for the mta-sts subdomain
• Simplified policy updates (change the policy in a UI, not by editing files on a server)
• Automatic id versioning when you update the policy
• Built-in TLS-RPT report aggregation

When to use a hosted MTA-STS service:

• You don’t have a web server or static hosting infrastructure
• You want to minimize operational overhead
• You’re managing MTA-STS for multiple domains
• You want integrated TLS-RPT reporting

MTA-STS vs DANE

Both MTA-STS and DANE solve the same problem — preventing TLS downgrade attacks — but they use different mechanisms and have different trade-offs.

Comparison Table

When to Use MTA-STS

Choose MTA-STS if:

• You don’t have DNSSEC enabled (or can’t enable it due to registrar limitations)
• You want faster deployment (DNSSEC setup is complex and time-consuming)
• You want maximum sender compatibility (MTA-STS is more widely supported)
• You’re using a hosted email provider (Google Workspace, Microsoft 365)

When to Use DANE

Choose DANE if:

• You already have DNSSEC enabled
• You need compliance with regulations that mandate DNSSEC (e.g., NIS2 in the EU)
• You want stronger cryptographic guarantees (DANE doesn’t rely on the WebPKI trust model)
• You’re in a region where DANE adoption is high (Europe, government sectors)

Can You Use Both?

Yes. Many organizations deploy both MTA-STS and DANE for defense in depth. Senders that support both will prefer DANE (stronger cryptographic validation) but fall back to MTA-STS if DNSSEC validation fails. Our 2026 email authentication research covers current adoption trends for both protocols.

Recommended approach:

1. Deploy MTA-STS first (easier, broader support)
2. Enable DNSSEC and add TLSA records once you’re comfortable with DANE’s complexity
3. Keep both active — they don’t conflict

How to Verify Your MTA-STS Configuration

After setting up MTA-STS, verify that everything is working correctly.

Manual Verification Steps

1. Check the DNS TXT record:

dig _mta-sts.example.com TXT +short

Expected output:

"v=STSv1; id=20260301"

2. Fetch the policy file:

curl https://mta-sts.example.com/.well-known/mta-sts.txt

Expected output:

version: STSv1
mode: enforce
mx: mail.example.com
max_age: 604800

3. Verify HTTPS certificate:

openssl s_client -connect mta-sts.example.com:443 -servername mta-sts.example.com

Look for:

• Verify return code: 0 (ok) — certificate is valid
• The certificate’s SAN includes mta-sts.example.com

4. Check MX hostnames match:

dig example.com MX +short

Confirm the hostnames returned match the mx: entries in your policy file.

Automated MTA-STS Checker Tools

Use an online MTA-STS checker to validate your configuration. These tools will:

• Fetch your DNS TXT record
• Retrieve the policy file over HTTPS
• Verify the HTTPS certificate is valid
• Check that MX hostnames match
• Identify common misconfigurations

TLS-RPT Reports for Validation

The most reliable validation comes from real-world delivery attempts. Enable TLS-RPT to receive reports from senders about TLS delivery successes and failures.

Key TLS-RPT fields to monitor:

• policy-type: sts — confirms senders are respecting your MTA-STS policy
• successful-session-count — should be high if your TLS is configured correctly
• failure-details — shows why TLS failed (certificate errors, hostname mismatches, etc.)

During the testing phase: TLS-RPT reports will show failures without affecting delivery. Fix any failures before switching to enforce mode.

Troubleshooting MTA-STS (stsfetchresult, certificate errors)

Common MTA-STS issues and how to fix them.

”MTA-STS policy is missing: STSFetchResult.None”

Meaning: The sending server couldn’t fetch your policy file.

Causes:

• The mta-sts subdomain doesn’t exist or doesn’t resolve
• No HTTPS service is running on the mta-sts subdomain
• The .well-known/mta-sts.txt file is missing
• HTTPS certificate is invalid or expired
• Firewall blocking HTTPS requests to the subdomain

Fix:

1. Verify https://mta-sts.yourdomain.com/.well-known/mta-sts.txt loads in a browser
2. Check the HTTPS certificate is valid and not expired
3. Confirm DNS resolves mta-sts.yourdomain.com to the correct IP
4. Check your web server logs for 404 or 500 errors

Certificate Hostname Mismatch

Meaning: The TLS certificate on your mail server doesn’t match the MX hostname in your policy.

Example: Your MX record is mail.example.com, but your certificate only lists example.com in the SAN.

Fix:

1. Obtain a new certificate that includes the MX hostname in the Subject Alternative Names
2. Use a wildcard certificate (*.example.com) that covers both example.com and mail.example.com
3. Update your policy file to match the certificate’s hostnames (not recommended — fix the certificate instead)

TLS-RPT Shows High Failure Rates

Meaning: Many senders are failing to establish TLS connections to your mail server.

Common causes:

• Certificate expired
• Certificate chain incomplete (missing intermediate CA certificates)
• TLS protocol version mismatch (server only supports TLSv1.0, sender requires TLSv1.2+)
• Cipher suite mismatch

Fix:

1. Review TLS-RPT failure reasons (failure-type field)
2. Test your mail server’s TLS with openssl s_client -starttls smtp -connect mail.example.com:25 -tls1_2
3. Use an SSL checker tool to validate your certificate chain
4. Update your mail server’s TLS configuration to use modern protocols (TLSv1.2+) and ciphers

Policy Not Updating

Meaning: You changed the policy file, but senders are still using the old policy.

Cause: Senders cache the policy for max_age seconds. They won’t re-fetch until:

1. The cache expires, OR
2. They see a new id value in the DNS TXT record

Fix:

1. Update the id field in your DNS TXT record whenever you change the policy file
2. Wait for DNS propagation (up to TTL seconds)
3. Senders will see the new id and re-fetch the policy

HTTPS Certificate for mta-sts Subdomain Expired

Meaning: The HTTPS certificate for mta-sts.yourdomain.com expired, so senders can’t fetch the policy.

Impact: New senders can’t fetch the policy and won’t enforce MTA-STS. Existing senders will continue using their cached policy until max_age expires.

Fix:

1. Renew the certificate immediately
2. Set up automated certificate renewal (e.g., Let’s Encrypt with auto-renewal)
3. Set up monitoring alerts for certificate expiration (ideally 30 days before expiry)

Wildcard MX Not Working

Meaning: You used mx: *.example.com in your policy, but some senders reject it.

Cause: Not all senders correctly implement wildcard MX matching per RFC 8461.

Fix:

1. Replace the wildcard with explicit hostnames
2. List all MX record hostnames individually in the policy file

Frequently Asked Questions

What is MTA-STS and why do I need it?

MTA-STS (Mail Transfer Agent Strict Transport Security) is a protocol that forces sending mail servers to use encrypted TLS connections when delivering email to your domain. You need it because standard SMTP encryption is opportunistic — attackers can strip away the TLS upgrade command and force messages to be sent in plain text. MTA-STS prevents this by publishing a policy that says “always require TLS or reject the message.”

What is the difference between MTA-STS and DANE?

MTA-STS and DANE both solve the TLS downgrade problem but use different trust models. MTA-STS relies on HTTPS certificates (WebPKI) and doesn’t require DNSSEC, making it easier to deploy. DANE relies on DNSSEC and TLSA records to authenticate mail server certificates. Many organizations deploy both for defense in depth.

How do I check if MTA-STS is configured correctly?

You can check your MTA-STS configuration by verifying that your DNS TXT record at _mta-sts.yourdomain.com returns a valid STSv1 record, and that your policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt is accessible over HTTPS and contains valid policy directives. Use TLS-RPT reports to monitor real-world delivery failures.

What does “MTA-STS policy is missing: STSFetchResult.None” mean?

This error means the sending server couldn’t retrieve your MTA-STS policy file. Common causes: the mta-sts subdomain doesn’t exist, HTTPS isn’t configured, the .well-known/mta-sts.txt file is missing, or the HTTPS certificate is invalid. Start by verifying you can access https://mta-sts.yourdomain.com/.well-known/mta-sts.txt in a browser.

Should I use MTA-STS with Google Workspace?

Yes. Google Workspace supports receiving mail over TLS but doesn’t automatically publish MTA-STS policies for your domain — you must set it up yourself. This means senders can still downgrade to unencrypted delivery if an attacker interferes. Publishing an MTA-STS policy forces senders to use TLS when delivering to your Google Workspace domain.

How do I set up MTA-STS for Microsoft 365?

Microsoft 365 requires you to manually configure MTA-STS by creating a DNS TXT record at _mta-sts.yourdomain.com and hosting the policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. Microsoft provides MTA-STS enforcement capabilities but doesn’t auto-publish policies for customer domains.

What is the .well-known/mta-sts.txt file?

The .well-known/mta-sts.txt file is the policy file that contains your MTA-STS directives. It must be served over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt and specifies your policy mode (testing/enforce/none), allowed mail server hostnames, and cache duration. Sending servers fetch this file to determine how to enforce TLS when delivering to your domain.

Related Protocols

• TLS-RPT — Reports TLS delivery failures (essential companion to MTA-STS)
• DANE — Alternative TLS enforcement using DNSSEC
• DMARC — Similar “monitor then enforce” deployment pattern