Skip to content
WebsiteHosting.com

concept Domains & DNS

MX record

Understand MX targets and lower-number mail preference, independent of website A/AAAA records and mail authentication TXT.

Sources checked · P0018

What it means

An MX (mail exchanger) record identifies hosts that receive SMTP email for a domain. It contains a numeric preference and an exchange hostname, not a web server address. When several usable MX records exist, a lower preference number is tried before a higher one, subject to SMTP's routing/fallback behavior. The hostname named by an MX record needs usable address records and must not be a CNAME alias. SMTP address resolution MX target restrictions

Try it

Example — compare two MX preferences. These are illustrative DNS entries; they are not real mail services.

example.com.       300 IN MX   10 mail1.example.com.
example.com.       300 IN MX   20 mail2.example.com.
mail1.example.com. 300 IN A    192.0.2.51
mail2.example.com. 300 IN A    192.0.2.52

A sending mail server normally prefers preference 10 over 20, not the reverse. If the preferred destination is unavailable, SMTP's rules can lead it to try other available destinations. Equally preferred MX hosts can be selected among; two records are not a promise of automatic failover with no message delays. The listed IPv4 addresses are reserved TEST-NET examples. Mail routing

Keep mail and web records separate

DNS dataPurposeShould you delete it for a web move?
www A or AAAAWeb address lookupOnly if replacing that exact web record
Apex MXIncoming mail delivery targetNo, unless explicitly migrating mail
SPF / DKIM / DMARC TXT (or related records)Mail authentication and policyNo, preserve during web changes
Apex NS / SOADNS zone operationNo, not for a simple web address update

An MX record pointing at a hostname with A/AAAA records is valid in principle; one pointing at a CNAME is contrary to the DNS clarifications. Mail delivery also depends on SMTP services and policy at that destination. The same domain can host its website and email with entirely different providers. MX records MX/NS alias restrictions

In practice

If you are changing the website, export the zone and explicitly preserve MX records, TXT records used for SPF/DKIM/DMARC, and any associated DKIM selector records and CAA/NS data. Do not change MX merely to make the website visible. If you are intentionally changing mail provider, plan a separate mail migration with verified receiving hosts, authentication changes, inbound/outbound tests and a rollback procedure.

For the overall website change see Connect a domain to a website and Change a DNS record safely. For alias limitations see CNAME record.

Sources & model boundaries

Primary references used for this explanation. The example above is illustrative; it is not a live check.

  1. RFC 1035 — Domain Names: Implementation and Specification

    Sections 3.2, 3.3 and 4. RR formats, TTL, A, NS, SOA, CNAME and MX records.

    Checked .

  2. RFC 5321 — Simple Mail Transfer Protocol

    Section 5, Address Resolution and Mail Handling. MX preference ordering, mail routing and fallback rules.

    Checked .

  3. RFC 2181 — Clarifications to the DNS Specification

    Sections 5 and 10. RRsets, CNAME coexistence, and MX/NS alias restrictions.

    Checked .

  4. RFC 3596 — DNS Extensions to Support IPv6

    Sections 2 and 3. AAAA records and their IPv6 address data.

    Checked .