MX record

Last updated

A mail exchanger record (MX record) specifies the mail server responsible for accepting email messages on behalf of a domain name. It is a resource record in the Domain Name System (DNS). It is possible to configure several MX records, typically pointing to an array of mail servers for load balancing and redundancy.

Contents

Overview

Resource records are the basic information element of the Domain Name System (DNS). An MX record is one of these, and a domain may have one or more of these set up, as below:

DomainTTLClassTypePriorityHostexample.com.1936INMX10onemail.example.com.example.com.1936INMX10twomail.example.com.

The characteristic payload information of an MX record [1] is a preference value (above labelled "Priority"), and the domain name of a mailserver ("Host" above).

The priority field identifies which mailserver should be preferred - in this case the values are both 10, so mail would be expected to flow evenly to both onemail.example.com and twomail.example.com - a common configuration. The host name must map directly to one or more address records (A, or AAAA) in the DNS, and must not point to any CNAME records. [2]

When an e-mail message is sent through the Internet, the sending mail transfer agent (MTA) queries the Domain Name System for the MX records of each recipient's domain name. This query returns a list of host names of mail exchange servers accepting incoming mail for that domain and their preferences. The sending agent then attempts to establish an SMTP connection, trying the host with the lowest "Priority" value first. The system allows high-availability clusters of mail gateways to be built for one domain if necessary. [3]

The MX mechanism does not grant the ability to provide mail service on alternative port numbers, nor does it provide the ability to distribute mail delivery across a set of unequal-priority mail servers by assigning a weighting value to each one.

MX preference, distance, and priority

According to RFC 5321, the lowest-numbered records are the most preferred. [4] This phrasing can be confusing, and so the preference number is sometimes referred to as the distance: smaller distances are more preferable. An older RFC, RFC 974, indicates that when the preference numbers are the same for two servers, they have the same priority, hence those two terms are used interchangeably.

The preference number is an unsigned [5] 16-bit [5] [6] field, thus valid values range from 0 to 65535.

The basics

In the simplest case, a domain may have just one mail server. For example, if an MTA looks up the MX records for example.com, and the DNS server replied with only mail.example.com with a preference number of 50, then the MTA will attempt delivery of the mail to the server listed. In this case, the number 50 could have been any integer permitted by the SMTP specification.

When more than one server is returned for an MX query, the server with the smallest preference number must be tried first. If there is more than one MX record with the same preference number, all of those must be tried before moving on to lower-priority entries. An SMTP client must be able to try (and retry) each of the relevant addresses in the list in order, until a delivery attempt succeeds. [4]

Load distribution

The standard approach to distributing a load of incoming mail over an array of servers is to return the same preference number for each server in the set. When determining which server of equal preference to send mail to, "the sender-SMTP MUST randomize them to spread the load across multiple mail exchangers for a specific organization", unless there is a clear reason to favor one. [4]

An alternative approach is to use multihomed servers, where the one host returns several IP addresses. [3] This method places the burden on the DNS rather than the SMTP-sender to perform the load balancing, which in this case will present a list of IP addresses in a specific order to the clients querying the A record of the mail exchanger. Since the RFC requires that the SMTP-sender use the order given in the A record query, the DNS server is free to carefully manipulate its balancing based on any method, including round robin DNS, mail server load, or some undisclosed priority scheme.

"Backup" MX

Some domains will have several MX records, one of which is intended as a "backup" - with a higher preference number so that it would not normally be picked as the target for email delivery.

However, in the case of errors from the lower-numbered hosts, (perhaps due to an outage of some sort), sending email servers will deliver to the "backup" host - queue.example.com in the example below:

DomainTTLClassTypePriorityHostexample.com.1936INMX10onemail.example.com.example.com.1936INMX10twomail.example.com.example.com.1936INMX100queue.example.com.

If the backup server has direct access to user mailboxes, mail will proceed there, but otherwise will likely be queued on queue.example.com until the outage is resolved.

In the absence of this sort of arrangement, when a domain's mail servers are all offline, sending servers are required to queue messages destined for that domain to retry later. However, these sending servers have no way of being notified that a previously offline domain's servers are now available, and so resort to a polling schedule - and will only discover that the domain is available whenever they next attempt delivery. The delay between when a receiving domain's servers come online and when delayed messages are finally delivered can be therefore anywhere from minutes to days, depending on the retry schedule of the sending servers - and the receiving domain has no visibility or control over this.

Spammers

Spammers may deliberately direct mail to one of the backup (high distance) MX servers of a domain first, on the assumption that such a server will have less effective anti-spam filters. An anti-spam technique called nolisting is based on assuming this behaviour.

Handling of delivery failure

The SMTP RFC [4] is ambiguous about exactly what kinds of delivery failure must result in re-attempting delivery via more distant MX records (those with higher preference values).

When servers indicate temporary failures, either by explicitly sending a 4xx error or by ending the connection unexpectedly (which must be treated as a 451 error, according to Section 3.8 of the RFC), Section 4.5.4.1 says:

The sender MUST delay retrying a particular destination after one attempt has failed.

However, when the sender retries, the RFC is silent about whether this should be to the same server, or a more "distant" MX record. It does say, in Section 5.1:

When the lookup succeeds, the mapping can result in a list of alternative delivery addresses rather than a single address, because of multiple MX records, multihoming, or both. To provide reliable mail transmission, the SMTP client MUST be able to try (and retry) each of the relevant addresses in this list in order, until a delivery attempt succeeds.

Some servers (such as Sendmail and Postfix 2.1 or later), [7] will attempt the next-furthest MX server after some types of temporary delivery failures, such as greeting failures. [8] Other servers (such as qmail and Postfix 2.0 or earlier) will only use more distant MX records if the servers specified in the shortest-distance MX records could not be contacted at all. Despite the difference, both behaviors are valid - since the RFC is not specific.

Fallback to the address record

In the absence of an MX record, email senders will attempt delivery to the address record - e.g. example.com.

This is based on RFC 5321 sec. 5.1, which states :

Historical background

RFC 821 was published in 1982. It makes only passing references to DNS, because at the time the transition from HOSTS.TXT to the DNS had not yet started. RFC 883, the first description of the DNS, was published over a year later in late 1983. It described the experimental and little used MD and MF records. According to RFC 897 and RFC 921, the transition to DNS started in 1983, but HOSTS.TXT was not scheduled to be phased out until the end of 1985 and was not totally phased out until the late 1990s.

In January 1986, RFC 973 and RFC 974 deprecated the MD and MF records, replaced them with MX, and defined the MX lookup with fallback to A. RFC 974 recommends that clients do a WKS lookup [9] on each MX host to see if it actually supports SMTP and discard the MX entry if not. However, RFC 1123 changed this to say that WKS should not be checked.

This means that SMTP had been in use for at least a year using HOSTS.TXT, and then another couple of years using A, MD, and MF, before MX came along. MD and MF were hard to use, so most people just used the A record. Under the circumstances, MX without fallback to A would not have worked because of the substantial installed base of mail servers using A records. The early use of MX was to identify gateways to other networks, but it did not come into wide use until the DNS was well established in the early 1990s. [10]

Standards documents

Obsoletes:

See also

Related Research Articles

The Domain Name System (DNS) is a hierarchical and distributed naming system for computers, services, and other resources in the Internet or other Internet Protocol (IP) networks. It associates various information with domain names assigned to each of the associated entities. Most prominently, it translates readily memorized domain names to the numerical IP addresses needed for locating and identifying computer services and devices with the underlying network protocols. The Domain Name System has been an essential component of the functionality of the Internet since 1985.

<span class="mw-page-title-main">Email</span> Mail sent using electronic means

Electronic mail is a method of transmitting and receiving messages using electronic devices. It was conceived in the late–20th century as the digital version of, or counterpart to, mail. Email is a ubiquitous and very widely used communication medium; in current use, an email address is often treated as a basic and necessary part of many processes in business, commerce, government, education, entertainment, and other spheres of daily life in most countries.

The Simple Mail Transfer Protocol (SMTP) is an Internet standard communication protocol for electronic mail transmission. Mail servers and other message transfer agents use SMTP to send and receive mail messages. User-level email clients typically use SMTP only for sending messages to a mail server for relaying, and typically submit outgoing email to the mail server on port 587 or 465 per RFC 8314. For retrieving messages, IMAP is standard, but proprietary servers also often implement proprietary protocols, e.g., Exchange ActiveSync.

An email address identifies an email box to which messages are delivered. While early messaging systems used a variety of formats for addressing, today, email addresses follow a set of specific rules originally standardized by the Internet Engineering Task Force (IETF) in the 1980s, and updated by RFC 5322 and 6854. The term email address in this article refers to just the addr-spec in Section 3.4 of RFC 5322. The RFC defines address more broadly as either a mailbox or group. A mailbox value can be either a name-addr, which contains a display-name and addr-spec, or the more common addr-spec alone.

Various anti-spam techniques are used to prevent email spam.

A Service record is a specification of data in the Domain Name System defining the location, i.e., the hostname and port number, of servers for specified services. It is defined in RFC 2782, and its type code is 33. Some Internet protocols such as the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) often require SRV support by network elements.

Sender Policy Framework (SPF) is an email authentication method which ensures the sending mail server is authorized to originate mail from the email sender's domain. This authentication only applies to the email sender listed in the "envelope from" field during the initial SMTP connection. If the email is bounced, a message is sent to this address, and for downstream transmission it typically appears in the "Return-Path" header. To authenticate the email address which is actually visible to recipients on the "From:" line, other technologies such as DMARC must be used. Forgery of this address is known as email spoofing, and is often used in phishing and email spam.

A Canonical Name (CNAME) record is a type of resource record in the Domain Name System (DNS) that maps one domain name to another.

Greylisting is a method of defending e-mail users against spam. A mail transfer agent (MTA) using greylisting will "temporarily reject" any email from a sender it does not recognize. If the mail is legitimate, the originating server will try again after a delay, and if sufficient time has elapsed, the email will be accepted.

A bounce message or just "bounce" is an automated message from an email system, informing the sender of a previous message that the message has not been delivered. The original message is said to have "bounced".

Email authentication, or validation, is a collection of techniques aimed at providing verifiable information about the origin of email messages by validating the domain ownership of any message transfer agents (MTA) who participated in transferring and possibly modifying a message.

<span class="mw-page-title-main">Message submission agent</span>

A message submission agent (MSA), or mail submission agent, is a computer program or software agent that receives electronic mail messages from a mail user agent (MUA) and cooperates with a mail transfer agent (MTA) for delivery of the mail. It uses ESMTP, a variant of the Simple Mail Transfer Protocol (SMTP), as specified in RFC 6409.

Forward-confirmed reverse DNS (FCrDNS), also known as full-circle reverse DNS, double-reverse DNS, or iprev, is a networking parameter configuration in which a given IP address has both forward (name-to-address) and reverse (address-to-name) Domain Name System (DNS) entries that match each other. This is the standard configuration expected by the Internet standards supporting many DNS-reliant protocols. David Barr published an opinion in RFC 1912 (Informational) recommending it as best practice for DNS administrators, but there are no formal requirements for it codified within the DNS standard itself.

The Sender Rewriting Scheme (SRS) is a scheme for bypassing the Sender Policy Framework's (SPF) methods of preventing forged sender addresses. Forging a sender address is also known as email spoofing.

A Domain Name System (DNS) zone file is a text file that describes a DNS zone. A DNS zone is a subset, often a single domain, of the hierarchical domain name structure of the DNS. The zone file contains mappings between domain names and IP addresses and other resources, organized in the form of text representations of resource records (RR). A zone file may be either a DNS master file, authoritatively describing a zone, or it may be used to list the contents of a DNS cache.

Nolisting is the name given to a technique to defend electronic mail domain names against e-mail spam.

<span class="mw-page-title-main">Callback verification</span> Technique used with SMTP to validate e-mail addresses

Callback verification, also known as callout verification or Sender Address Verification, is a technique used by SMTP software in order to validate e-mail addresses. The most common target of verification is the sender address from the message envelope. It is mostly used as an anti-spam measure.

Email forwarding generically refers to the operation of re-sending a previously delivered email to an email address to one or more different email addresses.

International email arises from the combined provision of internationalized domain names (IDN) and email address internationalization (EAI). The result is email that contains international characters, encoded as UTF-8, in the email header and in supporting mail transfer protocols. The most significant aspect of this is the allowance of email addresses in most of the world's writing systems, at both interface and transport levels.

Backscatter is incorrectly automated bounce messages sent by mail servers, typically as a side effect of incoming spam.

References

  1. ↑ In these examples, the domain name concerned is in the first column, the TTL (time-to-live) in the second, and the third is the "record Class" (in this case IN for Internet) - then MX to identify the type of record. The TTL is a validity period, indicating when the information must be refreshed from an authoritative name server.
  2. ↑ RFC 2181, Section 10.3, Clarifications to the DNS Specification, R. Elz, R. Bush (July 1997)
  3. 1 2 HOWTO - Configure Round Robin and Load Balancing, Page modified: February 28 2014., zytrax.com
  4. 1 2 3 4 RFC 5321
  5. 1 2 RFC 974
  6. ↑ RFC 1035 section 3.3.9
  7. ↑ If the primary MX responds, but fails mid-transaction, Postfix 1.2 and 2.0 will not try a backup MX. Archived 2009-06-23 at the Wayback Machine , Re: does not change to mx with lower priority, From: Victor Duchovni (Victor.DuchovniMorganStanley.com) Date: Fri Nov 11 2005
  8. ↑ A greeting failure is an error-code that is sent instead of or in response to the standard SMTP greeting handshake.
  9. ↑ Craig Partridge (January 1986). MAIL ROUTING AND THE DOMAIN SYSTEM. IETF. doi: 10.17487/RFC0974 . RFC 974 . Retrieved 18 November 2011. For each MX, a WKS query should be issued to see if the domain name listed actually supports the mail service desired. MX RRs which list domain names which do not support the service should be discarded. This step is optional, but strongly encouraged.
  10. ↑ This section is adapted from John Levine ietf-smtp message Archived 2008-06-01 at the Wayback Machine


This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.