Email Encyclopedia: What is MX Resolution

What is MX Resolution #

Overview #

MX resolution (Mail Exchange Record, commonly referred to as “MX record” or “mail exchange record”) is a type of resource record in the Domain Name System (DNS) used to specify the mail server that receives emails for a domain. By setting up a set of MX records with “priority” parameters, domain owners can control mail delivery order and disaster recovery strategies between different servers. For organizations using self-built or enterprise-level cloud email, properly maintaining MX resolution is a core component in ensuring email deliverability, traffic distribution, and security.

History #

• 1982: Jon Postel and others systematically described Internet mail in RFC 822 “Standard for the Format of ARPA Internet Text Messages”; in the same year, RFC 882/883 proposed early drafts of MX records. • 1986: RFC 974 “Mail routing and the domain system” formally defined the structure of MX records, priority semantics, and resolution processes, providing DNS layer support for SMTP mail exchange. • Subsequently revised multiple times, the current MX record specification is primarily inherited from RFC 5321 (2008, updated from RFC 2821).

How It Works #

MX Record Structure #

An MX record consists of the following fields: • Name: Domain name (e.g., example.com.) • Type: MX • Preference: Integer priority, the smaller the number, the higher the priority • Exchange: Hostname responsible for receiving mail (must resolve to an A or AAAA record)

Example: #

example.com. 3600 IN MX 10 mx1.example.com. example.com. 3600 IN MX 20 mx2.backup-example.com.

Resolution Process #

a. The sending MTA (Mail Transfer Agent) queries the authoritative DNS server for the MX records of the recipient’s domain. b. If no MX record is configured, according to the “implicit MX” rule in RFC 5321, the system falls back to querying the A/AAAA record with the same name. c. After obtaining a set of MX records, the MTA first attempts to connect to the server with the lowest numerical priority; if the connection fails or returns a 4xx/5xx bounce, it tries the next priority level. d. After successfully establishing an SMTP session, the email is delivered along the link to the target mailbox.

Priority and Load Balancing #

• Redundancy: Setting up multiple MX records with different priorities allows automatic switching to backup servers when the primary server fails. • Load Balancing: Configuring multiple MX records with the same priority - clients typically choose randomly or sequentially, implementing simple traffic distribution.

Configuration and Management #

• Basic Configuration – Add MX record entries in the authoritative DNS management platform. – Ensure that the hostname in the Exchange field has resolvable A/AAAA records, otherwise it will cause a “Non-existent domain (NXDOMAIN)” error.

• Common Errors – Missing trailing dot ("."): May cause subdomain concatenation errors. – MX pointing to CNAME: Explicitly prohibited by RFC 2181. – Priority conflicts: Setting all to the same number yet expecting primary-backup relationships. – TTL too long: Cannot take effect quickly when migrating mailboxes; TTL too short increases DNS query load.

• Monitoring and Troubleshooting – Use command-line tools such as dig, nslookup, host to verify resolution results. – Test connectivity to ports 25/465/587 via telnet or openssl s_client. – Locate 4xx/5xx bounce reasons in combination with SMTP logs (such as Postfix, Exim, Microsoft Exchange Transport Log).

Business Email Scenarios #

In corporate environments, MX resolution has the following significance:

Custom Domain: Through customized MX records, businesses can route “user@company.com” emails to self-built or hosted mailboxes. Multi-region Deployment: Configure independent MX groups for different continents, combined with GEO DNS to provide nearby access and reduce latency. Smooth Migration: During the parallel period of new and old email systems, use tiered priority MX records to implement gradual switching.

Security and Supporting Mechanisms #

• SMTP-TLS: Enable STARTTLS or SMTPS on the server ports specified in MX resolution to ensure link encryption. • SPF (Sender Policy Framework): Declare sending IPs in TXT records to reduce forgery. • DKIM (DomainKeys Identified Mail): Sign outbound emails to prevent tampering. • DMARC (Domain-based Message Authentication, Reporting and Conformance): Combine SPF/DKIM to provide a unified anti-fraud policy, and track through rua/ruf reports. • MTA-STS, DANE: Further enforce or verify encryption requirements related to MX records to prevent “downgrade” attacks.

Related Standards #

• RFC 5321 – Simple Mail Transfer Protocol • RFC 974 – Mail routing and the domain system • RFC 2181 – Clarifications to the DNS Specification • RFC 7208 – SPF • RFC 6376 – DKIM • RFC 7489 – DMARC

References #

Postel, J. “MAIL: SMTP – Simple Mail Transfer Protocol,” RFC 821, 1982. Partridge, C. “Mail routing and the domain system,” RFC 974, 1986. Klensin, J. “Simple Mail Transfer Protocol,” RFC 5321, 2008. Crocker, D. “Clarifications to the DNS Specification,” RFC 2181, 1997. Internet Engineering Task Force (IETF) Document Index.