MX RRs
From: https://www.zytrax.com/books/dns/ch8/mx.html
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. | | 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