The MX record

Copy article link Updated March 28, 2023

The MX or “mail exchange” DNS record type is critical to the delivery of email via the Simple Mail Transfer Protocol (SMTP). MX records are used to specify a list of mail servers for a domain. If MX records are not created and maintained correctly, email for the domain will not be delivered reliably or perhaps at all.

The MX record type was introduced in the original DNS specifications (RFC 1034 and 1035) in 1987.

A mailman checking MX records. By NsLookup.io. Licensed under CC By 4.0.

The MX record has two data fields besides the usual DNS TTL field: a preference value and the host name of a mail server. Each MX record specifies a single mail exchanger that provides mail delivery services for the domain.

Preference: A 16-bit unsigned integer value. Lower values indicate higher preference. It is legal to have a preference value zero. This indicates the highest possible preference.
Mail exchange: The fully qualified DNS name of a mail exchange for the domain.

We will discuss both fields in more detail later.

The MX record type is an example of a record type that exists in the DNS to support another protocol. Some record types such as SOA and NS are fundamental to the operation of the DNS itself. These record types are primarily used by DNS resolvers. Other record types such as MX and SRV are stored in the DNS, but are primarily used by applications to service other protocols.

As with all things on the Internet, redundancy is important. A mail server might be offline for maintenance or due to hardware failure or some other reason. Every domain that accepts mail should have at least two MX records.

How email works

The Simple Mail Transfer Protocol (SMTP) delivers email. SMTP servers implement the SMTP protocol and allow for email to be sent. There will usually be at least two SMTP servers involved in sending an email: the SMTP server for the sender's domain and the SMTP server for the recipient's domain. If the sender and recipient are in the same domain, the email will be placed directly into the inbox of the recipient.

When sending email to a recipient in another domain, email delivery generally involves these steps:

When you click send, the email client (which might be a web application) contacts the SMTP server for your domain. The SMTP server name is usually part of the email client configuration, but this might be hidden from the end user.
Using SMTP, the email client communicates the recipient's email address, subject, message body, and attachments to your SMTP server.
Your SMTP server performs a DNS MX record lookup for the recipient's domain. If no MX records are found, it would send a bounce message to the sender. The MX records are ordered according to the preference rules.
Your SMTP server, now acting as the SMTP client, contacts the SMTP servers for the recipient's domain in preference order. Once a server accepts the connection, another SMTP session is used to communicate your email address, the recipient's email address, subject, message body, and attachments.
The email has now been delivered to the recipient, although the recipient may need to use the Post Office Protocol (POP3) or Internet Message Access Protocol (IMAP) to download a copy of the email into their email client.

MX records at the zone root

Below is a simple example DNS zone showing the zone root with SOA and NS records and two MX records, along with one address record for each mail exchanger host name.

example.org. 86400 SOA  ns1.example.org. admin.example.org. (...)
example.org. 86400 NS   ns1.example.org.
example.org. 86400 NS   ns2.example.org.
example.org. 86400 NS   ns3.example.org.
example.org. 86400 NS   ns4.example.org.

example.org. 3600  MX   10 mailserver1.example.org.
example.org. 3600  MX   20 mailserver2.example.org.

mailserver1.example.org. 3600 A 10.0.0.1
mailserver2.example.org. 3600 A 10.0.0.2

This is a very typical zone pattern. These MX records state that mailserver1.example.org and mailserver2.example.org are mail servers for the example.org zone, and that they should be used by SMTP clients, or Mail Transfer Agent (MTA) software, in that order.

MX records below the zone root

MX records often exist at the root of a zone because an organization's DNS boundary and web presence usually share the same DNS name as the organization's email addresses. In our example above, the zone begins at example.org and the organization's email addresses would look like [email protected].

However, this is not required. MX records can exist at any name in the DNS, either at the root of a zone or at some child name inside a zone. The number of labels in the domain name where MX records reside is not required to be two, or any other particular value. Any DNS zone may contain multiple sets of MX records.

This might be useful for a mail hosting provider or in a large organization where different departments run their own mail services. If our example zone had different mail services (and therefore also different email addresses) for finance, legal, and shipping, then the zone might contain MX records such as:

finance.example.org.  3600  MX   10 denali.example.org.
finance.example.org.  3600  MX   20 adams.example.org.
legal.example.org.    3600  MX   10 fuji.example.org.
legal.example.org.    3600  MX   20 logan.example.org.
shipping.example.org. 3600  MX   10 everest.example.org.
shipping.example.org. 3600  MX   20 k2.example.org.

Mail exchanger names

The second element of each MX record is the fully qualified DNS host name of a mail server for the domain. Each MX record specifies exactly one mail server for the domain, so there will be one MX record for each of the domain's mail servers.

RFC 2181 section 10.3 prohibits mail server host names from resolving through CNAME records. This is a historical requirement due to failures caused by the use of CNAMEs and implementations which did not support CNAMEs properly in this context. This requirement has been carried forward and remains in place, and must be obeyed.

Every mail server name must resolve directly to one or more records of type A (IPv4 address) and/or one or more records of type AAAA (IPv6 address). As an illegal example, the pattern below must never be used:

; Example of illegal use of CNAME in conjunction with an MX record
example.org.             3600  MX     10 mailserver1.example.org.
mailserver1.example.org. 3600  CNAME  denali.example.org.
denali.example.org.      3600  A      10.0.0.1

The mail server name does not have to reside in the same zone as the MX record itself. It may be any valid fully-qualified DNS name, either inside the same zone as the MX record or in some entirely different zone. This would be common in cases where mail services are provided by a third party.

Can an MX record be an IP address?

No, MX records cannot point to an IP address. MX records can only point to domains or hostnames. Domains can in turn have A or AAAA records that contain IP addresses. This is how you link an IP address to an MX record, but you cannot directly link an IP address to an MX record.

Mail exchanger preference

The MX preference field allows the mail administrator for the domain to control the order in which mail servers are used by SMTP clients. Preference is an unsigned 16-bit integer value where lower values indicate higher preference, and zero is the highest preference. As the value increases, preference for the mail server in that particular MX record decreases.

SMTP clients are required to contact the lowest preference mail server first. SMTP clients are only permitted to use higher preference mail servers if all the mail servers with lower preference are unreachable or return error.

If two MX records have the same preference value, the SMTP client is required to randomize its requests to load balance equally among all mail servers of the same preference value. Consider this example:

example.org. 3600  MX   10 mailserver1.example.org.
example.org. 3600  MX   10 mailserver2.example.org.
example.org. 3600  MX   20 mailserver3.example.org.

This configuration of MX records would cause 50% of mail requests to go to mailserver1 and 50% to mailserver2. No requests should arrive at mailserver3 unless both of the other mail servers are offline or are returning an error for some reason.

The magnitude of the preference value has no meaning other than how it impacts the sort order. As mentioned before, zero is the highest preference. If a domain has three sets of mail servers to be used in a particular order, the preference values could for example be 0, 1, and 2. They could also be 1000, 2000, and 3000 and exactly the same pattern of mail requests would result, so long as the MX records sort in the same order by preference.

See RFC 5321 section 5 for a full explanation of how SMTP clients are required to consume MX records.

MX record TTLs

MX records do not typically change frequently and so should have relatively long Time-To-Live (TTL) values. This ensures that a brief outage in the DNS is less likely to impact mail delivery for the domain. A good range of TTL values for MX records is between one hour and one day. Shorter TTLs should generally be avoided.

As specified by RFC 2181 section 5.2 all the MX records that exist at a particular name in the DNS must have identical TTL values. This is true of all DNS record types, not just type MX.

For more information on the importance of making good choices for DNS record TTLs see our article What is a good TTL for DNS?

Email security

As time goes, security is becoming more and more important on the Internet. MX records do not provide any form of security at all. SMTP also has minimal security features built-in. Security has been added to Internet email in a number of ways:

Sender Policy Framework (SPF): SPF is an authentication protocol that lists of IP addresses that are allowed to send email on behalf of a domain. SPF is actually built on DNS and used DNS text (TXT) records to store SPF configuration. SPF attempts to prevent spoofing, spam, and phishing. It is important, but not perfect.
DomainKeys Identified Mail (DKIM): DKIM uses cryptography to validate the domain of the email sender. This more rigorously protects end users against spoofing and phishing.
Domain-based Message Authentication, Reporting, and Conformance (DMARC): DMARC allows the owner of a domain to set policy on how incoming unauthenticated messages should be treated. They may be permitted, placed in quarantine, or rejected. DMARC also includes reporting features so that domain owners can monitor the flow of email. DMARC is intended to further protect end users from spoofing, spam and phishing, and it uses both SPF and DKIM.
Secure/Multipurpose internet Mail Extensions (S/MIME): S/MIME adds encryption and a digital signature to email sent over SMTP. This allows an SMTP server to verify the identity of the sender and ensures that the message has not been tampered with in transit. The SMIMEA DNS record type was proposed in RFC 8162 to allow S/MIME certificates to be published in the DNS but this has not been widely adopted. S/MIME certificates are installed manually in email clients.
Open Pretty Good Privacy (OpenPGP): OpenPGP provides end-to-end encryption and security for email. The OPENPGPKEY DNS record type (RFC 7929) is used to publish the public keys used by OpenPGP.

Nolisting

Nolisting is a technique used to defeat poorly written spam bot software. The DNS administrator simply creates a bogus MX record with the highest priority value that has a mail server name that does not resolve to an IP address. For example:

example.org. 3600  MX   0  some_bogus_name.example.org.
example.org. 3600  MX   10 mailserver1.example.org.
example.org. 3600  MX   20 mailserver2.example.org.

In the early days of spam, it was noticed that at least some spam software would only connect to the highest priority mail server. If unable to send spam using that server, the spam bots would give up. Any SMTP client who properly implemented SMTP though, would continue onto the next highest priority server and would succeed in delivering email even though the first mail server name did not resolve to an IP address. For a while, this was a fairly strong measure against spam, but it did not take long for spammers to catch up and simply do a better job of implementing SMTP.

Nolisting is not often used today because it is almost trivial to defeat, and some legitimate SMTP clients may not actually be smart enough to try mail delivery using the second mail server. SPF, DKIM, and DMARC offer much better security and protection against spam.

Do I need an MX record to send email?

Technically no, you do not need to create MX records to send email from your domain. MX records must be created in order for a domain to receive email, but no MX record are directly used to send email.

When you send an email, say to [email protected], your email client will contact your SMTP server, which will in turn look up the MX records for the example.org domain and contact SMTP servers for example.org in order to send your email to Alice.

Your own domain will have MX records so that you can receive email, but when you send an email to [email protected] only the MX records for example.org are used. If Alice were to reply to your email, then her SMTP server would look up the MX records for your domain to deliver her email reply back to you.

However, even though the process of sending email does not require MX records for the sender's domain, it is still a good idea to have MX records for the zone. Every DNS zone must have an SOA record, and part of the SOA record is the RNAME field which contains an email address for the zone's DNS administrator. Without an MX record, the RNAME email address would not be valid. This may be flagged as suspicious by email filtering software attempting to classify email as spam or malicious, so it is always best to have MX records for a domain.

Implicit MX records

If no MX records exist for a domain, SMTP clients are required to use the address records for the domain itself as mail server target addresses. The preference for each such address is to be treated as zero, so mail requests will be load balanced equally among the available addresses. This is discussed in RFC 5321 section 5.

Very importantly though, this is definitely not recommended. While this should in theory work, it is a far better practice to have explicit MX records. This allows the administrator to control the use of mail servers through different preference values, and also allows web and mail servers to have different IP addresses. Implicit MX records are also somewhat inefficient because they require an extra DNS query.

Finding MX records for a zone

The MX records of a zone can be queried with the dig or nslookup command line tools. To find the mail servers for wikipedia.org, use this command:

dig MX wikipedia.org

On operating systems that support nslookup, you can use the following:

nslookup -type=mx wikipedia.org

You can also check the MX records of any domain name in our MX lookup tool, or by entering it here: