What is the purpose of the MTA-STS 'mx' rule?

Mail Transfer Agent Strict Transport Security, or MTA-STS, is a security standard designed to protect inbound email. Its primary function is to ensure that emails are delivered over an encrypted connection, safeguarding them from eavesdropping and man-in-the-middle (MITM) attacks. Before MTA-STS, even if a sending server supported encryption, an attacker could potentially interfere with the connection and force a downgrade to an unencrypted channel.

Mailmodo says:

Visit website

MTA-STS is another email security protocol that is designed to prevent issues such as man-in-the-middle (MITM) attacks and address longstanding vulnerabilities...

The protocol works by allowing a domain to publish a policy that specifies two key things: that email must be sent over a secure Transport Layer Security (TLS) connection, and which specific mail servers are authorized to receive email for that domain. This policy is fetched by sending MTAs, which then know to refuse delivery if a secure connection cannot be established with one of the approved servers. At the heart of this authorization process is the mx rule.

Suped DMARC monitor

Free forever, no credit card required

Get started for free

Trusted by teams securing millions of inboxes

To use MTA-STS, a domain must publish a DNS TXT record and host a policy file on a specific web address. The DNS record signals that the domain supports MTA-STS, while the policy file contains the actual rules that sending servers must follow. This file is a simple text file with key-value pairs.

Practical 365 says:

Visit website

The policy file contains key pairs to define the version, the mode (enforce means that the domain uses MTA-STS; the other values are testing and none), and the maximum age for the policy.

The primary keys in this file are version, mode, max_age, and mx. The mode can be set to enforce, testing, or none, allowing domain owners to gradually roll out the policy. The max_age value tells sending servers how long to cache the policy. But the most critical part for server validation is the mx rule.

The purpose of the MTA-STS mx rule is to explicitly declare which mail servers are legitimate for your domain. It acts as an allowlist of hostnames. When a sending server initiates a connection, it performs a series of checks:

• Policy retrieval: The sender's Mail Transfer Agent (MTA) first looks up the MTA-STS DNS record for your domain to find the policy file.
• DNS lookup: The sender's MTA then performs a standard DNS lookup to find the MX records for your domain.
• Validation: The crucial step is here. The sender compares the hostnames from the DNS MX records against the hostnames listed in the mx rule of your MTA-STS policy.
• Secure connection: If a server from the MX records matches a hostname in the mx list, the sender will only deliver the email if it can establish a secure TLS connection and the server's certificate is valid and matches the hostname. If these conditions aren't met and the policy mode is enforce, the email is not delivered.

This mechanism directly prevents an attacker from redirecting your email by presenting a fake MX record. Even if an attacker could intercept DNS and point the sender to a malicious server, that server's hostname would not appear in your policy's mx list. The sending server would detect the mismatch and abort the connection, protecting the email's contents.

Zimbra : Blog says:

Visit website

For example, sometimes the TLS certificate is self-signed or a different DNS name is used for the MX server. Because MTAs fall-back to cleartext, this information leak is mostly invisible to the naked eye. MTA-STS helps solve this problem.

In essence, the mx rule adds a critical layer of authentication. It ensures that not only is the connection encrypted, but that it's an encrypted connection to the correct, authorized server. It transforms email delivery from a system of hopeful encryption to one of enforced, validated security.