What is an MTA-STS Record and How to Set it Up?

Although TLS encrypts emails during delivery, it doesn't always prevent attackers from forcing a connection to fall back to an unencrypted SMTP session. This can expose sensitive emails to interception.

An MTA-STS record solves this problem by requiring sending mail servers to use encrypted TLS connections and verify the recipient's mail server before delivering an email. If you're wondering what is MTA-STS, it's an email security standard that protects emails during transmission and helps prevent downgrade attacks. It's supported by major email platforms, including Microsoft 365, Google Workspace, and Microsoft Exchange.

What Is MTA-STS?

MTA-STS, short for Mail Transfer Agent Strict Transport Security, is an email security standard that helps protect emails while they travel between mail servers. It was introduced under RFC 8461 to solve a common problem with email delivery. Although most email servers support Transport Layer Security (TLS), they don't always require it. If a secure connection cannot be established, some servers may fall back to sending the email without encryption.

This creates an opportunity for attackers to intercept or read sensitive information during transmission. MTA-STS prevents this by telling sending mail servers to use only secure, encrypted SMTP connections when delivering emails to your domain. If a secure connection cannot be established or the receiving server cannot be verified, the email is not delivered instead of being sent over an insecure connection.

If you're wondering what is MTA-STS, think of it as a security policy that tells other mail servers, "Only send emails to my domain if you can do it securely." This helps reduce the risk of downgrade attacks and protects confidential emails from being exposed while they're in transit.

MTA-STS works with popular email services like Microsoft 365, Google Workspace, Exchange, and Postfix. It doesn't replace SPF, DKIM, or DMARC. Instead, it adds another layer of protection by securing the connection between mail servers.

What Is an MTA-STS Record?

One of the biggest points of confusion about MTA-STS is that it isn't just a single DNS record. A complete MTA-STS configuration has two parts that work together: a DNS TXT record and a policy file hosted on your website. Both are required for MTA-STS to work properly.

DNS TXT Record

The first part is the DNS TXT record, which tells sending mail servers that your domain supports MTA-STS. It also includes an ID value that helps mail servers know when your policy has changed.

A typical DNS record looks like this:

Host: _mta-sts.example.com

Value:
v=STSv1; id=20260805

Here's what each part means:

• v=STSv1 specifies the version of the MTA-STS standard.
• id=20260805 is a unique identifier for the current policy. Whenever you update your policy file, you should change this value so that sending mail servers know to download the latest version.

MTA-STS Policy File

The second part is the policy file. This is a plain text file that must be hosted on your domain over HTTPS. A basic policy file looks like this:

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

This file tells sending mail servers which mail servers are allowed to receive emails for your domain and whether secure delivery should be enforced.

Many people searching for an MTA-STS record expect to find only a DNS entry. In reality, the DNS TXT record simply points mail servers to the policy file, where the actual security rules are defined. If either part is missing or configured incorrectly, MTA-STS will not work as expected.

How Does MTA-STS Work?

Once MTA-STS is configured, mail servers follow a simple process before delivering an email. This ensures the connection is secure and that the email is being sent to the correct destination.

1. The sending mail server starts delivering an email.
2. It performs a DNS lookup to check whether the recipient's domain has an MTA-STS TXT record.
3. If the TXT record is found, the sending server knows the domain supports MTA-STS and reads the policy ID.
4. The sending server downloads the policy file from the recipient's secure HTTPS endpoint.
5. It checks the policy to confirm which MX (mail exchange) servers are allowed to receive emails for the domain.
6. The server validates the TLS certificate presented by the recipient's mail server. This confirms that it is connecting to the correct server over an encrypted connection.
7. If all checks pass, the email is delivered securely. If the connection cannot be encrypted or the mail server doesn't match the policy, delivery is blocked when the policy is set to enforce.

This extra verification takes only a short time but adds an important layer of security. Instead of trusting any mail server that claims to accept emails for your domain, MTA-STS makes sure the server matches your published policy and supports a valid encrypted connection.

How to Set Up an MTA-STS Record

Setting up an MTA-STS record involves configuring both a DNS TXT record and a policy file. Together, these components tell sending mail servers how to securely deliver emails to your domain. Here's how to get started.

Step 1: Create the MTA-STS DNS TXT Record

The first step is to create an MTA-STS DNS TXT record for your domain. This record lets sending mail servers know that your domain supports MTA-STS and points them to your policy. It also includes a unique policy ID that helps mail servers identify when the policy has been updated.

Step 2: Create the MTA-STS Policy File

Next, create the MTA-STS policy file. This plain text file contains the rules that sending mail servers must follow when delivering emails to your domain. It defines the policy mode, the mail servers that are allowed to receive emails, and how long the policy should remain valid before being refreshed.

Step 3: Host the Policy File Over HTTPS

The policy file must be hosted on your domain over a secure HTTPS connection. It should be publicly accessible so that sending mail servers can retrieve and read it before delivering emails. Make sure your website uses a valid TLS certificate, as an invalid or expired certificate may prevent mail servers from accessing the policy.

Step 4: Update the Policy ID After Making Changes

Whenever you modify your MTA-STS policy, update the policy ID in your DNS TXT record. This tells sending mail servers that a new version of the policy is available and prompts them to download the latest copy instead of relying on a cached version.

Step 5: Verify Your Configuration

After publishing your MTA-STS configuration, verify that your DNS TXT record has propagated correctly and is publicly visible. You can use NSLookup's DNS lookup tools to check whether the record is accessible and contains the expected values.

You should also confirm that the policy file is available at the correct HTTPS location and can be accessed without errors. Verifying both the DNS record and the policy file helps ensure that other mail servers can successfully discover and apply your MTA-STS configuration.

MTA-STS Policy Modes

When creating an MTA-STS policy, you must choose a policy mode. The mode tells sending mail servers how strictly they should apply your MTA-STS rules. There are three available modes: none, testing, and enforce.

The none mode is mainly used when you're setting up MTA-STS or making changes to your configuration. It lets mail servers discover your policy without requiring them to follow it.

The testing mode helps you verify that everything is configured correctly before enabling strict enforcement. Since email delivery isn't blocked during testing, it's a safe way to identify and fix issues.

The enforce mode provides the highest level of protection. It ensures that emails are delivered only over encrypted TLS connections to authorized mail servers. If a secure connection can't be established or the receiving server doesn't match your policy, the sending mail server will refuse to deliver the email. For most organizations, it's best to switch to enforce only after thoroughly testing the configuration.

Common MTA-STS Errors

Even a small configuration error can prevent MTA-STS from working as intended. Here are some of the most common issues and how they affect email delivery.

Missing MTA-STS TXT Record

If the MTA-STS TXT record is missing from your DNS, sending mail servers won't know that your domain supports MTA-STS. As a result, they won't attempt to retrieve your policy file or apply its security rules. Check that the TXT record exists under the correct _mta-sts subdomain and is publicly visible through DNS.

Policy File Returns a 404 Error

Mail servers expect to find the MTA-STS policy file at a specific HTTPS location. If the file returns a 404 Not Found error, they cannot retrieve your policy. This means MTA-STS won't be applied, even if the DNS record is configured correctly. Ensure the file is hosted at the required path and is publicly accessible.

Invalid HTTPS Certificate

The MTA-STS policy file must be served over HTTPS using a valid TLS certificate. If the certificate is self-signed, issued to the wrong domain, or otherwise invalid, sending mail servers may reject the connection and fail to retrieve the policy. Always use a trusted certificate authority and verify that the certificate matches your domain.

Incorrect Content-Type

The policy file should be served as plain text. If your web server returns the wrong Content-Type, some mail servers may not process the file correctly. Verify your server configuration to ensure the policy file is delivered with the appropriate MIME type and without unnecessary formatting or redirects.

Incorrect MX Names

The MX entries listed in your MTA-STS policy must match the mail servers that actually receive email for your domain. If the names are incorrect, incomplete, or outdated, sending mail servers may reject the connection when the policy is enforced. Review your DNS MX records and update the policy whenever your mail infrastructure changes.

Policy ID Not Updated

The policy ID in the DNS TXT record tells sending mail servers when a new version of the policy is available. If you update the policy file but leave the same ID, mail servers may continue using the cached version until it expires. Change the policy ID whenever you modify the policy file.

Invalid Policy Syntax

A policy file with missing fields, unsupported values, or formatting errors may not be parsed correctly by sending mail servers. Even a small syntax mistake can prevent the policy from being applied. Validate the file carefully and make sure it follows the format defined in the MTA-STS specification.

Expired TLS Certificate

An expired TLS certificate on the server hosting your MTA-STS policy can stop mail servers from securely retrieving the file. Since MTA-STS relies on HTTPS, an expired certificate breaks the trust required for the connection. Monitor certificate expiry dates and renew certificates before they expire to avoid service disruptions.

MTA-STS vs STARTTLS

MTA-STS and STARTTLS both help secure email delivery, but they don't do the same job. STARTTLS is a protocol that upgrades an SMTP connection from unencrypted to encrypted using TLS. However, it is optional. If a secure connection cannot be made, some mail servers may still send the email without encryption.

MTA-STS makes this process more secure. It tells sending mail servers that emails must be delivered over an encrypted TLS connection. It also checks that the receiving mail server is the correct one. If these security checks fail, the email is not delivered instead of being sent over an insecure connection. This helps protect emails from downgrade attacks and keeps sensitive information safe while it's in transit.

MTA-STS vs DANE

MTA-STS and DANE are both designed to improve email security during transmission, but they use different methods.

MTA-STS uses a DNS TXT record and a policy file hosted over HTTPS to tell sending mail servers how to securely deliver emails. It is easier to set up because it does not require DNSSEC.

DANE (DNS-based Authentication of Named Entities) stores TLS certificate information in DNS and relies on DNSSEC to verify that information. This provides strong protection, but it also makes DANE harder to deploy, since DNSSEC must already be enabled.

If your domain already uses DNSSEC, DANE may be a good choice. For many organizations, however, MTA-STS is easier to implement and provides strong protection against insecure email delivery. Some organizations use both standards together to strengthen email security even further.

Secure Your Domain with an MTA-STS Record

Setting up an MTA-STS record is an important step toward securing email delivery. By requiring encrypted SMTP connections and verifying recipient mail servers, MTA-STS helps protect emails from interception and downgrade attacks. However, your configuration is only effective if the DNS record and policy file are published correctly. After making changes, check that your DNS records are publicly accessible and up to date. You can also run a Free DNS Health Check to identify DNS configuration and security issues.

Frequently Asked Questions

Can I use MTA-STS without DMARC?

Yes. MTA-STS and DMARC protect different parts of your email system. MTA-STS secures emails while they are being sent between mail servers, while DMARC helps stop attackers from sending fake emails using your domain. Although you can use MTA-STS on its own, using both together gives your domain better email security.

How long does it take for an MTA-STS record to start working?

After you publish your MTA-STS DNS record and policy file, it can take anywhere from a few minutes to 48 hours for the changes to appear everywhere. The exact time depends on your DNS provider and DNS propagation. Some mail servers may also keep using a cached copy of your policy until it expires.

Does MTA-STS protect incoming or outgoing emails?

MTA-STS mainly protects emails sent to your domain. It tells other mail servers how to securely deliver emails to you. Your outgoing emails are protected only when the recipient's domain has also set up MTA-STS and follows the same security standard.