concept Domains & DNS
MX record
Understand MX targets and lower-number mail preference, independent of website A/AAAA records and mail authentication TXT.
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
Simulation — select a mail route without sending a message. Change the two MX preference values and target availability, then rehearse routing. A separate web-A action demonstrates that the web address is not the mail destination in this fixture.
Mail preference and fallback
Change preferences and availability, then compare mail routing with a separate web-address change.
Web A and MX describe different services. A web-address edit here does not change either mail target or its preference.
| Item | State / result | Why it matters |
|---|---|---|
| mail1.example.test | 10 · up | A 192.0.2.40 |
| mail2.example.test | 20 · up | A 192.0.2.50 |
| www.example.test A | 192.0.2.20 | Independent web record; no mail cutover. |
| Routing result | Not attempted | A route is not a delivery receipt. |
No email is sent. Selecting an available target does not prove message delivery, authentication or safety.
About this model
Lower numerical preference is tried first. Equal-preference ordering is not fixed. No explicit MX is different from a Null MX declaration; this scene does not implement Null MX. It illustrates one bounded attempt, not queues, retries, spam filtering, recipient policy or SMTP TLS.
Read the article’s primary sources for protocol rules and implementation-specific limits. This scene has no network access.
With preferences 10 and 20 and both targets available, the lower numerical preference is considered first. Make mail1 unavailable and rehearse again: the bounded attempt can move to mail2. Set equal preferences to inspect the tie. The scene does not pick a guaranteed first target; it lists which targets are available, including the case where neither is available. SMTP destination selection
| Fixture | Routing lesson | Not established |
|---|---|---|
| 10 available, 20 available | Consider 10 before 20 | Final delivery or recipient acceptance |
| 10 unavailable, 20 available | An alternative target can be tried | That every failure is recoverable |
| Equal preferences | No universal deterministic first server | A stable load split for every sender |
| No explicit MX | Applicable implicit-MX rules need consideration | That the domain cannot receive mail |
| Alias target or target without address data | Invalid target in this exercise | A usable SMTP endpoint |
Preference values are bounded whole numbers from 0 to 65535. The targets are fixed hostnames with documentation-address data, not IP literals in the MX field. Changing the web A record leaves both MX targets and preferences unchanged. Reset restores preferences 10/20, both available targets and the original web record.
This is one routing attempt, not SMTP delivery, queuing, authentication, spam handling or a TLS test. Null MX is a separate declaration, not the same as an absent MX RRset; it is outside the scene. Null MX distinction Equal-priority ordering can depend on sender rules and available information, so the example reports possibilities instead of simulating a promised winner.
Keep mail and web records separate
| DNS data | Purpose | Should you delete it for a web move? |
|---|---|---|
www A or AAAA | Web address lookup | Only if replacing that exact web record |
| Apex MX | Incoming mail delivery target | No, unless explicitly migrating mail |
| SPF / DKIM / DMARC TXT (or related records) | Mail authentication and policy | No, preserve during web changes |
| Apex NS / SOA | DNS zone operation | No, 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.
Key takeaways
Read the numerical preference and target hostname together. Distinguish selection of a reachable target from successful delivery, and keep a web migration separate from a mail migration. For absent MX data, inspect the applicable SMTP rules rather than concluding that no mail service exists.
Frequently asked questions
Editorial questions, answered from the sources listed for this article.
Does a larger MX number mean a higher priority?
No. Lower numerical preference is normally considered first. Equal-preference destinations do not have a guaranteed fixed ordering; SMTP selection also depends on the applicable rules and available information.
Can I put an IP address directly in the MX target?
The MX exchange field names a host. Its address records provide connection addresses. The target should not be a CNAME alias, and the presence of MX data alone is not proof that mail will be accepted.
Sources & model boundaries
Primary references used for this explanation. The interactive example is an educational model, not a live check.
- 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 .
- RFC 5321 — Simple Mail Transfer Protocol
Section 5, Address Resolution and Mail Handling. MX preference ordering, mail routing and fallback rules.
Checked .
- RFC 2181 — Clarifications to the DNS Specification
Sections 5 and 10. RRsets, CNAME coexistence, and MX/NS alias restrictions.
Checked .
- RFC 3596 — DNS Extensions to Support IPv6
Sections 2 and 3. AAAA records and their IPv6 address data.
Checked .
- RFC 7505 — A Null MX No Service Resource Record
Sections 1 and 3. An explicit Null MX declaration is different from absence of an MX RRset.
Checked .