What is the relationship between the 'mx' field and DNS MX records?

The 'mx' field in an MTA-STS policy should mirror the Fully Qualified Domain Names (FQDNs) of your DNS MX records. Sending mail servers use DNS MX records to find your mail servers and then consult the MTA-STS policy's 'mx' field to verify that these discovered servers are authorized to receive mail securely via TLS.

What happens if an 'mx' entry in the policy does not match a DNS MX record?

If an 'mx' entry in your MTA-STS policy does not match an active DNS MX record, or if the corresponding server fails TLS validation, compliant sending MTAs will not deliver email to that server. Depending on the MTA-STS policy mode , email delivery may be deferred or rejected.

Can I use wildcard entries in the 'mx' field?

No, MTA-STS policies do not support wildcard MX entries. Each Mail Exchange server that you intend to secure with MTA-STS must be explicitly listed with its full hostname in the 'mx' field.

How often should I update my 'mx' field?

You should update your 'mx' field whenever there are changes to your domain's mail infrastructure, such as adding or removing MX records, changing mail server hostnames, or migrating to a new email service provider. It's crucial to keep it synchronized with your active DNS MX records.

What is the 'mx' field in an MTA-STS policy used for? - MTA-STS - Email authentication - Knowledge base

An illustration of an email being securely transferred between two mail servers using an encrypted connection.

MTA-STS (Mail Transfer Agent Strict Transport Security) is a crucial standard for securing email in transit, protecting against attacks that attempt to downgrade or intercept communications. It allows a domain to specify that all inbound email must be delivered over a secure, authenticated TLS connection. At the heart of this policy is the 'mx' field, which plays a pivotal role in dictating exactly which mail servers are authorized to receive your domain's email securely.

The core function of the 'mx' field

The 'mx' field within an MTA-STS policy explicitly lists the Mail Exchange (MX) hostnames that are designated to receive email for your domain. When a sending mail server (MTA) wants to deliver an email to your domain, it first checks your domain's MTA-STS policy. If a policy exists, the sending MTA expects to connect to one of the MX hosts specified in the policy file and to establish a TLS connection with a certificate that is valid for that host.

This mechanism ensures that only the authorized mail servers are permitted to receive mail. It creates a critical layer of trust, as sending servers will only deliver mail if the receiving server's identity (as presented through its TLS certificate) matches what's declared in your MTA-STS policy. Without this, an attacker could potentially impersonate your mail server and intercept incoming messages.

Each MX record that you have configured in your DNS for inbound mail flow must have a corresponding 'mx' entry in your MTA-STS policy. This ensures comprehensive coverage for all your designated mail receivers. You can learn more about the purpose of the MTA-STS 'mx' rule in our detailed guide.

Example MTA-STS policy fragment with 'mx' entriesYAML

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

Ensuring secure mail delivery

The primary benefit of the 'mx' field is its ability to enforce a higher level of security for incoming email. By explicitly listing the expected MX servers, an MTA-STS policy tells sending servers, "These are the only mail servers authorized to receive email for my domain, and they must support TLS." This prevents attackers from redirecting mail to their own servers or forcing an unencrypted connection.

A key aspect of MTA-STS is its protection against downgrade attacks. Historically, email could fall back to unencrypted connections if TLS wasn't available. However, with an MTA-STS policy in enforce mode, if the 'mx' servers don't offer a secure connection or their certificate is invalid, the sending server will defer or reject the email, rather than sending it insecurely. This helps safeguard email privacy and integrity, as outlined in RFC 8461.

It is crucial that the 'mx' values in your MTA-STS policy accurately reflect the actual MX records published in your DNS. Any discrepancy can lead to email delivery failures, as sending servers will not be able to validate the intended recipient servers against the policy. This validation step reinforces trust and prevents man-in-the-middle attacks.

Failing to correctly list all your MX records in the 'mx' field of your MTA-STS policy can severely impact email deliverability. Sending servers following your policy will fail to find a matching, authorized MX host, resulting in delayed or rejected emails. This is why MTA-STS validation is so important.

An illustration showing a break in email security, with an email unable to pass through a barrier due to a vulnerability.

Configuring the 'mx' field in your policy

The 'mx' field is part of the MTA-STS policy file, which is usually hosted on a web server at a specific path. The file's format is straightforward, and each MX hostname should be listed on a separate line under the 'mx' key. It is vital to ensure that these entries precisely match the FQDNs (Fully Qualified Domain Names) of your MX records. For example, if your DNS MX record is mail.example.com, your policy should reflect that exact hostname.

When setting up your MTA-STS policy, you will also need a TXT record in your DNS to signal the presence of the policy. This TXT record contains an id tag that helps identify policy changes. Be aware that MTA-STS does not allow wildcard MX entries, so each MX host must be explicitly named. The format of the policy file itself is simple and human-readable.

Ensuring that your MTA-STS policy accurately lists all current and future MX records is a continuous task. Any changes to your mail infrastructure, such as adding new mail servers or migrating to a different provider, will require an update to your MTA-STS policy. Failure to do so can lead to service disruptions and email delivery problems.

Match FQDNs: Ensure each 'mx' entry in the policy exactly matches the Fully Qualified Domain Name of your MX records.
Include all MX hosts: List every MX server responsible for receiving mail for your domain.
Update regularly: Review and update your policy whenever your email infrastructure changes.

Correct 'mx' configuration

DNS MX record: 10 mail.example.com

MTA-STS PolicyYAML

mx:
  - mail.example.com

Security: Sending MTAs can successfully validate the receiving server's identity.
Deliverability: Emails are delivered securely without issues.

Incorrect 'mx' configuration

DNS MX record: 10 mail.example.com

MTA-STS PolicyYAML

mx:
  - example.com

Security: MTA-STS validation fails due to mismatch, compromising security.
Deliverability: Emails are deferred or rejected by compliant sending MTAs.

Monitoring MTA-STS and the 'mx' field

Even with a perfectly configured MTA-STS policy, continuous monitoring is essential. Discrepancies between your policy's 'mx' entries and your actual MX records, or issues with TLS certificates on your mail servers, can lead to email delivery problems. TLS-RPT reports (TLS Reporting) are designed to provide feedback on MTA-STS policy compliance, allowing you to detect and rectify these issues.

Manually sifting through these reports can be time-consuming and complex. This is where a dedicated DMARC and email security platform becomes invaluable. Suped offers robust DMARC monitoring capabilities that extend to MTA-STS. Our AI-powered recommendations help you quickly identify and fix issues related to 'mx' field mismatches or certificate problems, ensuring your policy is always enforced correctly.

With Suped, you get real-time alerts on policy violations, a unified platform for DMARC, SPF, and DKIM, and deliverability insights, allowing for proactive management of your email security posture. This comprehensive approach ensures that your 'mx' configuration is always accurate and your email remains secure.

Feature	Manual Monitoring	Suped Monitoring
Policy validation	Requires manual inspection of policy files and DNS records.	Automated checks for correct 'mx' field configuration and TLS.
Error detection	Relies on parsing TLS-RPT reports and identifying issues.	Real-time alerts and AI-driven recommendations for fixes.
Unified view	Separate tools and dashboards for different email protocols.	Combines DMARC, SPF, DKIM, and MTA-STS insights in one platform.

Safeguarding your email infrastructure

The 'mx' field is a fundamental component of MTA-STS, serving as the explicit declaration of your authorized mail exchange servers. By accurately listing these servers and ensuring they maintain valid TLS certificates, you significantly enhance the security of your inbound email traffic, protecting your communications from interception and tampering.

Implementing MTA-STS, including a well-configured 'mx' field, is a critical step towards achieving robust email security and improving your overall deliverability. It demonstrates a commitment to email best practices, which is increasingly important for maintaining sender reputation and ensuring messages reach their intended recipients.

Leveraging platforms like Suped for DMARC monitoring and MTA-STS insights provides the tools you need to effectively manage and maintain these essential security policies. This proactive approach helps secure your email infrastructure, maintain trust, and ultimately support reliable communication.