Mail Exchange Record (MX)

Defined in RFC 1035. Specifies the name and relative preference of mail servers (mail exchangers in the DNS jargon) for the zone. The MX RR is used by external SMTP (Mail) Agents to route incoming mail for the domain.

Format

owner-name           ttl  class   rr  pref name
example.com.         3w   IN      MX  10   mail.example.com.

The pref (Preference) field is relative to any other MX record for the zone (value 0 to 65535). Low values are more preferred. The pref value 10 you see everywhere is just a convention you can use any number(s) you wish. The pref field is used by the SMTP (Mail) Agent to select the most preferred (lowest pref value) mail server. If this mail server is unavailable (down or too busy) then if a lower preference mail server is defined (has a higher pref value) it is tried. When all defined mail servers have been tried the mail agent will then fall back to its error recovery strategy - typically an increasing time back-off algorithm over a period of 24 to 48 hours.

Any number of MX records may be defined. If the mail server lies within the domain (in-zone) it requires an A record. MX records do not need to point to a host in this zone - they may point to an out-of-zone server in which case an A/AAAA RR must not be defined. MX records should not point to CNAME RRs (but frequently do, see the discussion on this topic). Defining MX records for subdomains is covered separately.

The sending SMTP Agent, for example sendmail or postfix, will query the DNS for an MX RR based on the format of the mail address. Thus, if the mail address is user@example.com the mail agent will issue an MX query for example.com whereas if the mail address is user@subdomain.example.com it will issue an MX query for subdomain.example.com.

Notes:

Mail is normally obtained by users (using POP3 or IMAP) only from the primary (lowest pref) mail server. Back-up mail servers (higher pref values) are usually configured to simply forward mail over a prolonged period (multiple days or even weeks) to the primary mail server.
The MX RR is defined at the zone apex (has the same owner-name as the domain) and is one of the so-called domain (or zone) infrastructure records (SOA and NS are the others). Infrastructure RRs are unique in that they return another name value which requires at least one more DNS transaction to obtain an IP address (assuming an in-zone server). In most cases infrastructure records are stable (though the mail server IP address may change, perhaps even frequently) and consequently consideration should be given to running infrastructure RRs with very long TTL times such as the 3 weeks or more shown in the Format example above to reduce unnecessary DNS loads.
If the domain does not receive email then it seems obvious that it should not define an MX RR. However, SMTP agents which follow the procedures defined in RFC 5321 (section 5), having failed to find an MX RR for the domain may still end up issuing unwanted A/AAAA queries to the domain's DNS. Instead, RFC 7505 recommends that to prevent this unwanted traffic a NULL MX RR be published in the domain's DNS as shown in the following fragment:
```
# zone file fragment for example.com
# which will not accept any incoming email
# Attempts to send mail to this domain will result in:
#  - a reply code 556
#  - enhance status code 5.1.10
...
$ORIGIN example.com.
...
# NULL MX RR 
# the single dot (.) signifies a null name
# and indicates definitively this domain cannot receive email
# use of zero in pref field indicates the highest preference
# This MUST be the only MX RR for this domain
    MX  0 .
...
```
Note: If the domain sends email then some SMTP agents, to verify their incoming email, will use an MX lookup on the originating email domain name. Consequently, a NULL MX RR may result in email rejection and therefore should NOT be published. The only remedy in this situation is to grin and bear the unwanted A/AAAA lookup traffic load on unwanted incoming email (if you get the drift).

Examples & Variations

; zone fragment example.com
; mail servers in the same zone
; will support incoming email with addresses of the format 
; user@example.com
$TTL 2d ; zone default = 2 days or 172800 seconds
$ORIGIN example.com.
; SOA using @ substitution
@              IN       SOA   ns1.example.com. hostmaster.example.com. (
; this is functionally the same as the line below
; example.com. IN       SOA   ns1.example.com. hostmaster.example.com. (
               2003080800 ; serial number
               3h         ; refresh =  3 hours 
               15M        ; update retry = 15 minutes
               3W12h      ; expiry = 3 weeks + 12 hours
               2h20M      ; nxttl = 2 hours + 20 minutes
               )
              IN      MX     10  mail  ; short form
; the line above is functionally the same as the line below
; example.com. IN     MX     10  mail.example.com.
; any number of mail servers may be defined
              IN      MX     20  mail2.example.com.
; use an external (out-of-zone) back-up
              IN      MX     30  mail.example.net.
; the local (in-zone) mail server(s) need an A record   
mail          IN      A      192.168.0.3
mail2         IN      A      192.168.0.3

No mail servers in-zone:

; zone fragment for example.com
; mail servers not in the zone (out-of-zone)
; will support incoming email with addresses of the format 
; user@example.com
$TTL 2d ; zone default = 2 days or 172800 seconds
$ORIGIN example.com.
example.com. IN       SOA   ns1.example.com. root.example.com. (
               2003080800 ; serial number
               3h         ; refresh =  3 hours 
               15M        ; update retry = 15 minutes
               3W12h      ; expiry = 3 weeks + 12 hours
               2h20M      ; nxttl = 2 hours + 20 minutes
               )
; mail servers not in zone - no A records required
               IN     MX     10  mail.foo.com.
               IN     MX     20  mail2.foo.com.

Subdomain MX records

You can define subdomains (aka subzones) as being fully delegated (uses a separate zone file) or as what this guide terms virtual (or pseudo) sub-domains (uses a single zone file). The following example uses a virtual subdomain (all the definitions are contained in a single zone file).

; zone fragment for example.com
; name servers in the same zone (in-zone)
$TTL 2d ; zone default = 2 days or 172800 seconds
$ORIGIN example.com.
example.com. IN     SOA   ns1.example.com. hostmaster.example.com. (
               2003080800 ; serial number
               2h         ; refresh =  2 hours 
               15M        ; update retry = 15 minutes
               3W12h      ; expiry = 3 weeks + 12 hours
               2h20M      ; nxttl = 2 hours + 20 minutes
               )
; mail server for main domain
; will support email with addresses of the format 
; user@example.com
              IN      MX 10  mail.example.com.
; A Record for mail server above using $ORIGIN subsitution
mail          IN      A      192.168.0.5
; other domain level hosts and services
....
; sub-domain definitions
; will support email with addresses of the format 
; user@us.example.com
$ORIGIN us.example.com.
              IN      MX 10  mail
; record above could have been written as
; us.example.com.   IN  MX 10 mail.us.example.com.
; optional - define the main mail server as backup
              IN      MX 20 mail.example.com.
; A record for subdomain mail server using $ORIGIN subsitution
mail          IN      A      10.10.0.29
; the record above could have been written as 
; mail.us.example.com. A 10.10.0.29 if it's less confusing
....
; other subdomain definitions as required

An alternate way of defining the above (which we think is confusing) is shown below:

; zone fragment for example.com
; name servers in the same zone
$TTL 2d ; zone default = 2 days or 172800 seconds
$ORIGIN example.com.
example.com. IN     SOA   ns1.example.com. hostmaster.example.com. (
               2003080800 ; serial number
               2h         ; refresh =  2 hours 
               15M        ; update retry = 15 minutes
               3W12h      ; expiry = 3 weeks + 12 hours
               2h20M      ; nxttl = 2 hours + 20 minutes
               )
; mail server for main domain
; will support email with addresses of the format 
; user@example.com
              IN      MX 10  mail.example.com.
; mail server for subdomain 'us'
; will support email with addresses of the format 
; user@us.example.com
us            IN      MX 10  mail.us.example.com.
us            IN      MX 20  mail.example.com.
; A record for main mail server above 
mail          IN      A      192.168.0.5
; other domain level hosts and services
....
; sub-domain definitions
$ORIGIN us.example.com.
; A record for subdomain mail server
mail          IN      A      10.10.0.29
; the record above could have been written as 
; mail.us.example.com. A 10.10.0.29 if it's less confusing
....
; other subdomain definitions as required

Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.