MX Hosting vs NS Hosting: DNS, Mail Routing, and Safe Nameserver Changes

What Is the Difference Between MX Hosting and NS Hosting?

NS hosting determines who is authoritative for the domain’s DNS zone; MX records inside that zone determine where incoming email should be delivered. They are related through DNS, but they are not the same service.

Consider a domain named example.com. The registrar may delegate it to:

ns1.dns-provider.example.
ns2.dns-provider.example.

Those nameservers answer authoritative queries for example.com. Inside the zone, an administrator might have:

example.com.      3600 IN A   192.0.2.20
www.example.com.  3600 IN A   192.0.2.20

example.com.      3600 IN MX  10 mx1.mail-provider.example.
example.com.      3600 IN MX  20 mx2.mail-provider.example.

The A records send web traffic toward the web server. The MX records advertise the hosts that accept email. The NS delegation tells the Internet which DNS servers are trusted to provide those records.

RFC terminology is more precise than the marketing phrase “MX hosting.” An MX record is a DNS resource record containing a preference value and an exchange hostname. The mail service itself runs on the host named by the MX record; the MX record is merely published by the authoritative DNS zone.

How Do You Find Which Provider Actually Hosts the DNS Zone?

The authoritative DNS provider is determined by the domain’s delegation, not by whichever control panel happens to show a DNS editor. Before changing MX records, verify the nameservers that the parent DNS hierarchy delegates for the domain.

Start with:

dig NS example.com +short

A typical result could be:

ns1.dns-provider.example.
ns2.dns-provider.example.

That is useful, but a normal recursive query may come from cache. When the domain is being migrated, also inspect the delegation path:

dig +trace example.com NS

The trace walks from the DNS root toward the TLD and then the domain. Near the final delegation, look for the nameservers published by the parent zone. Those are the servers recursive resolvers are being directed toward.

Why the Registrar DNS Page Can Be Misleading

A domain may be registered with Registrar A, use DNS Provider B, host its website with Provider C and receive email through Provider D. In that setup, a DNS editor visible at Registrar A may have no effect at all if the registrar is not serving the delegated nameservers.

This is a common support scenario: an administrator adds the correct MX record in a familiar control panel, waits for hours, and dig MX still shows the old value. The record itself is not necessarily wrong. It may simply have been created in a zone that no resolver asks.

Confirm by querying an authoritative server directly:

dig @ns1.dns-provider.example example.com MX

Look for the aa flag in the response header, which indicates an authoritative answer, and inspect the ANSWER section. If the server does not return the record you just created, you are either editing the wrong provider, querying the wrong nameserver, or the provider has not loaded the expected zone.

Parent Delegation and Zone NS Records Are Not the Same Check

NS records can appear both at the parent delegation and inside the child zone. A healthy setup normally keeps them consistent, but only checking the zone apex can hide a broken delegation.

For example, the child zone might claim:

example.com. IN NS ns1.new-dns.example.
example.com. IN NS ns2.new-dns.example.

while the parent still delegates to:

ns1.old-dns.example.
ns2.old-dns.example.

Recursive resolvers reach the domain through the parent delegation, so the parent view is the critical one during a nameserver migration. A self-reported NS record inside a zone does not override the parent delegation.

Where Should MX Records Be Created When Email Is Hosted Elsewhere?

MX records must be created in the currently authoritative DNS zone, even when the mailboxes and SMTP servers are hosted by another company. The mail provider supplies the required MX values, but the DNS provider publishes them.

Suppose the domain uses:

NS:
ns1.dns-company.example.
ns2.dns-company.example.

Web:
203.0.113.50

Mail:
mx1.mail-company.example.
mx2.mail-company.example.

The authoritative DNS zone at the DNS company should contain something similar to:

example.com.      IN A   203.0.113.50
www.example.com.  IN A   203.0.113.50

example.com.      IN MX  10 mx1.mail-company.example.
example.com.      IN MX  20 mx2.mail-company.example.

No nameserver change is required just because the mail provider is different. The existing authoritative DNS provider can publish MX records for any valid mail exchanger hostname.

Do Not Point MX Directly to an IP Address

An MX record points to a hostname, not directly to an IPv4 or IPv6 address. The target hostname must then resolve to address records.

Correct:

example.com. IN MX 10 mail.example.com.
mail.example.com. IN A 192.0.2.25

Incorrect:

example.com. IN MX 10 192.0.2.25

When checking the setup, resolve both layers:

dig example.com MX +short
dig mail.example.com A +short
dig mail.example.com AAAA +short

An MX answer is not enough by itself. The exchanger hostname must also be resolvable to a usable address for SMTP delivery.

Do Not Use a CNAME as the MX Target

The target named by an MX record should be a canonical hostname with address records, not a CNAME alias. DNS specifications explicitly reject MX and NS targets that are aliases.

A risky configuration looks like:

example.com. IN MX 10 mail.example.com.
mail.example.com. IN CNAME server.provider.example.

A better arrangement is:

example.com. IN MX 10 mail.example.com.
mail.example.com. IN A 192.0.2.25

or to use the provider’s canonical mail hostname directly as the MX target if that is what the provider documents:

example.com. IN MX 10 mx1.provider.example.

Verify the target:

dig mail.example.com CNAME +short
dig mail.example.com A +short
dig mail.example.com AAAA +short

If the hostname used in MX returns a CNAME, correct the design rather than relying on resolver behavior that may appear to work in some tests.

How Do MX Priority and Mail Routing Actually Work?

MX preference values determine which mail exchanger a sender should try first: lower numbers are preferred. A record with preference 10 is preferred over one with preference 20.

For example:

example.com. IN MX 10 mx1.example.net.
example.com. IN MX 20 mx2.example.net.

A sending SMTP system normally attempts the lower-preference exchanger first. If that host cannot be used, the sender can try a less-preferred exchanger according to SMTP delivery rules.

Higher Priority Does Not Mean a Higher Number

Control panels often label the field “priority,” which makes administrators assume that 100 is “higher priority” than 10. With MX records, preference works the other way around: the lower number is preferred.

Check exactly what is published:

dig example.com MX +short

Example:

10 mx1.example.net.
20 mx2.example.net.

The numbers should match the mail provider’s documented configuration. Do not invent priorities merely to make the records look ordered.

What Happens If a Domain Has No MX Record?

SMTP has a fallback rule for domains with no MX records: senders may try the domain’s A or AAAA address as an implicit mail exchanger. That behavior is part of SMTP, but it is not a substitute for intentional mail configuration.

Suppose:

example.com. IN A 203.0.113.20

and there is no MX record. A sender may attempt SMTP delivery to 203.0.113.20. If that host is merely a web server and does not accept mail for the domain, delivery attempts will fail or be deferred.

Therefore, “no MX” does not necessarily mean “this domain explicitly does not accept mail.” Domains that intentionally accept no email can use a null MX as defined for that purpose:

example.com. IN MX 0 .

Do not add a null MX to a domain that should receive email. It explicitly signals that the domain does not accept mail.

Can Web Hosting, DNS Hosting and Email Hosting Use Different Providers?

Yes. Web hosting, authoritative DNS and email can be completely independent as long as the authoritative DNS zone contains records that correctly point each service to its provider.

A perfectly valid architecture might look like this:

Registrar:
registrar.example

Authoritative DNS:
ns1.dns-provider.example
ns2.dns-provider.example

Website:
203.0.113.80

Mail:
mx1.mail-provider.example
mx2.mail-provider.example

The DNS zone connects those services:

example.com.      IN A   203.0.113.80
www.example.com.  IN A   203.0.113.80

example.com.      IN MX  10 mx1.mail-provider.example.
example.com.      IN MX  20 mx2.mail-provider.example.

The domain registration does not force the website to use the registrar’s hosting. The nameservers do not have to be on the web server. The MX hosts do not have to share an IP with the website. Separating those functions is routine.

Which Records Usually Stay with the Mail Provider?

When mail is hosted separately, MX records are only one part of the DNS dependency. Outbound authentication and mail-client discovery may use additional records.

A migration inventory should normally include, where applicable:

• MX records for inbound routing;
• SPF TXT records at the relevant sending domain;
• DKIM selector TXT records such as selector._domainkey.example.com;
• DMARC TXT records at _dmarc.example.com;
• autodiscover or autoconfig records;
• provider verification TXT or CNAME records;
• SRV records used by specific mail or collaboration services.

Copying only the MX records may preserve inbound mail while silently damaging outbound authentication. The domain can still receive messages, yet sent mail begins failing SPF, DKIM or DMARC checks.

Can the Website Move Without Touching Email?

Yes. If DNS remains with the same authoritative provider, a web-only migration may require changing only the website’s A, AAAA or CNAME records.

For example, before:

example.com.      IN A 192.0.2.10
www.example.com.  IN A 192.0.2.10
example.com.      IN MX 10 mx.mail-provider.example.

After the web migration:

example.com.      IN A 203.0.113.60
www.example.com.  IN A 203.0.113.60
example.com.      IN MX 10 mx.mail-provider.example.

The MX record does not need to change merely because the web server changed. This is one of the simplest ways to avoid unnecessary email risk during a hosting migration.

Why Can Changing Nameservers Break Email Even When MX Values Stay the Same?

Changing nameservers replaces the authoritative source of the entire DNS zone. If the new DNS provider does not contain the same MX and mail-related records, resolvers will eventually stop seeing the old data even though the mail servers themselves were never changed.

This is the classic failure pattern:

1. The website is moved to a new hosting provider.
2. The administrator changes NS records at the registrar.
3. The new DNS zone contains the web A record.
4. The MX, SPF, DKIM or DMARC records were not copied.
5. The website works, but email begins failing as resolvers switch to the new authoritative nameservers.

From the administrator’s point of view, “nothing was changed in email.” From DNS’s point of view, the entire zone authority changed.

Why the Failure Can Look Intermittent

During a nameserver transition, recursive resolvers may still have cached delegation or record data from the old DNS provider while others already use the new provider. One user may see the new website and working mail, while another network sees new web records but missing MX data.

Compare multiple resolvers:

dig example.com NS @1.1.1.1
dig example.com NS @8.8.8.8

dig example.com MX @1.1.1.1
dig example.com MX @8.8.8.8

Then query the old and new authoritative nameservers directly:

dig @ns1.old-dns.example example.com MX
dig @ns1.new-dns.example example.com MX

If the old server returns the correct MX and the new server returns no MX or a different value, the problem is not mysterious propagation. The zones are inconsistent.

Why DNSSEC Can Turn an NS Migration into SERVFAIL

A nameserver migration can fail completely when an old DNSSEC DS record remains at the parent while the new authoritative provider uses different signing keys. Validating resolvers then see a broken chain of trust and can return SERVFAIL.

Check whether a DS record exists:

dig example.com DS +short

Then test through a validating resolver:

dig example.com A @1.1.1.1
dig example.com MX @1.1.1.1

If the migration involves DNSSEC, do not treat the DS record as an unrelated registrar setting. Coordinate DNSSEC before or during the nameserver move according to the capabilities of both DNS providers. A stale DS can make the website and mail appear simultaneously broken even when the new zone data itself is correct.

How Do You Move Nameservers Without Interrupting Mail?

A safe nameserver migration is prepared before the delegation changes. Build the new authoritative zone first, copy all production records, query the new nameservers directly, and only then change NS at the registrar.

Step 1: Inventory the Current Authoritative Zone

Do not use screenshots as the only migration record. Query the active DNS and export the zone if the provider supports it.

At minimum, collect:

dig example.com A
dig example.com AAAA
dig www.example.com A
dig example.com MX
dig example.com TXT
dig _dmarc.example.com TXT
dig example.com NS
dig example.com SOA

DKIM selectors are not discoverable by asking DNS for “all DKIM records,” so obtain the active selector names from the mail provider, mail configuration or existing DNS panel.

Also inventory application-specific records such as:

• autodiscover;
• autoconfig;
• mail-provider validation records;
• SRV records;
• subdomain delegations;
• CAA records;
• custom TXT records used by third-party services.

Step 2: Build the New Zone Before Changing NS

Add the domain to the new DNS provider and reproduce the necessary records while the old nameservers are still authoritative. The new zone can be tested directly even before the parent delegation points to it.

dig @ns1.new-dns.example example.com A
dig @ns1.new-dns.example example.com MX
dig @ns1.new-dns.example example.com TXT
dig @ns1.new-dns.example _dmarc.example.com TXT

Do not proceed if the new authoritative nameserver cannot answer correctly for critical records.

Step 3: Validate Every MX Target

After confirming the MX set, resolve each target separately:

dig @ns1.new-dns.example example.com MX +short
dig mx1.mail-provider.example A +short
dig mx1.mail-provider.example AAAA +short
dig mx2.mail-provider.example A +short
dig mx2.mail-provider.example AAAA +short

Check that MX targets are hostnames, not IP addresses, and that they are not CNAME aliases.

Step 4: Check Mail Authentication Records

For SPF:

dig @ns1.new-dns.example example.com TXT +short

For DMARC:

dig @ns1.new-dns.example _dmarc.example.com TXT +short

For DKIM, use the selector supplied by the mail system:

dig @ns1.new-dns.example selector._domainkey.example.com TXT +short

Inbound delivery can work while these records are missing, so an SMTP receive test alone is not enough for a full migration check.

Step 5: Check DNSSEC Before the Delegation Change

If the current domain uses DNSSEC, identify the existing DS state before switching nameservers:

dig example.com DS

The exact migration procedure depends on whether both providers support a coordinated DNSSEC transfer or multi-signer arrangement. If they do not, follow a safe disable-and-reenable procedure rather than leaving an old DS tied to the previous provider’s keys.

Step 6: Change Nameservers at the Registrar

Only after the new zone answers correctly should you update the domain’s delegation. Enter exactly the nameservers assigned by the new DNS provider.

After the change:

dig +trace example.com NS
dig example.com NS @1.1.1.1
dig example.com NS @8.8.8.8

Do not remove the old DNS zone immediately if the provider allows you to keep it temporarily. Cached delegation can still send some resolvers to the old nameservers until their cached data expires.

Step 7: Test Web and Mail Separately

Once the new delegation begins appearing, test critical record families independently:

dig example.com A +short
dig www.example.com A +short
dig example.com MX +short
dig example.com TXT +short
dig _dmarc.example.com TXT +short

Then perform real service tests: open the website, send inbound mail from an external system, send outbound mail to an external mailbox, and inspect the received message headers for SPF, DKIM and DMARC results where applicable.

How Do You Diagnose MX and NS Problems with dig?

Diagnosing MX and NS problems is easier when you query the DNS hierarchy in layers instead of repeatedly running the same recursive lookup. Check delegation, authoritative answers, MX targets and recursive cache separately.

Case 1: MX Is Correct in the Panel but dig Shows Something Else

First identify the authoritative nameservers:

dig example.com NS +short

Then query one directly:

dig @ns1.authoritative.example example.com MX

If the direct authoritative response contains the expected MX while a public resolver still returns an older value, caching is plausible. If the authoritative response itself is wrong, waiting will not repair it.

Case 2: One Authoritative Nameserver Has Different MX Records

Query every delegated nameserver:

dig @ns1.authoritative.example example.com MX +short
dig @ns2.authoritative.example example.com MX +short

Both should normally return the same production MX RRset for the zone. If one server returns:

10 mx1.mail.example.
20 mx2.mail.example.

and the other returns:

10 oldmail.example.com.

the problem is authoritative inconsistency, not client-side propagation. Depending on which server a resolver reaches, users can observe different mail routing.

Case 3: MX Exists but Mail Still Cannot Be Delivered

Resolve the exchange hostname:

dig example.com MX +short
dig mx1.mail.example A +short
dig mx1.mail.example AAAA +short

If the MX target has no usable address, publishing the MX record alone is insufficient.

Next, if you administer the mail server, verify that SMTP is actually reachable on the target host. DNS can tell senders where to connect, but DNS does not prove that the SMTP service is listening, the firewall allows traffic, or the server accepts mail for the recipient domain.

Case 4: Some Networks Return SERVFAIL After an NS Change

Check the delegation and DNSSEC state:

dig +trace example.com NS
dig example.com DS
dig example.com DNSKEY

If the parent publishes DS data that no longer matches the zone’s signing keys, validating resolvers can reject responses. Fix the DNSSEC chain instead of changing MX records at random.

Which MX and NS Configuration Errors Cause the Hardest-to-Find Failures?

The most expensive MX and NS incidents usually involve configurations that are partly correct. The website opens, one resolver returns the expected answer, or one mail flow works, so the underlying DNS inconsistency remains hidden.

Editing NS Records Inside the Zone Instead of Changing Delegation

Adding new NS records to the zone apex does not necessarily change the registrar or parent-zone delegation. If the goal is to move authoritative DNS providers, verify and update the nameserver delegation through the domain registrar or registry workflow required for the TLD.

Use:

dig +trace example.com NS

If the parent still sends queries to the old provider, changing only the apex NS RRset at the new provider has not completed the migration.

Deleting the Old DNS Zone Too Early

An administrator updates the registrar and immediately removes the domain from the previous DNS provider. Some recursive resolvers still have the old delegation cached and continue querying those old nameservers. If those servers now return NXDOMAIN, REFUSED or no useful zone data, users behind those caches can see a temporary outage.

When possible, keep the old zone answering consistently during the transition. The old and new DNS providers should publish equivalent critical records until the delegation change has aged out of normal caches.

Copying MX but Forgetting the Hostname Behind It

This problem appears when the MX target itself belongs to the domain being migrated:

example.com. IN MX 10 mail.example.com.
mail.example.com. IN A 192.0.2.44

If the administrator copies the MX line but forgets the mail.example.com A or AAAA record, the MX RR remains visible but the exchanger is no longer reachable through DNS.

Always expand the dependency:

dig example.com MX +short
dig mail.example.com A +short
dig mail.example.com AAAA +short

Changing the Website A Record and Accidentally Moving Mail

A particularly subtle configuration uses the bare domain as both the website address and, because no explicit MX exists, the implicit SMTP destination. Changing the site’s A record can then change where senders try to deliver email.

Check:

dig example.com MX +short
dig example.com A +short
dig example.com AAAA +short

If the domain is supposed to receive mail, publish an intentional MX configuration instead of depending accidentally on SMTP’s no-MX fallback behavior.

Using “Propagation” as the Explanation for Every Failure

Waiting is appropriate only when the authoritative data is already correct and older cached data is still legitimately in circulation. If the new nameserver itself returns a wrong answer, the TTL is not the problem.

Use this sequence:

dig @ns1.new-dns.example example.com MX
dig @ns2.new-dns.example example.com MX

dig example.com MX @1.1.1.1
dig example.com MX @8.8.8.8

If the authoritative answers are wrong, fix them now. If authoritative answers are correct but recursive resolvers differ, then cache expiry becomes part of the diagnosis.

What Is a Safe Production Workflow for MX and NS Changes?

A safe production workflow treats DNS delegation and mail routing as separate layers. First establish authority, then validate zone contents, then change delegation, and finally verify both DNS and real mail flow.

A Ten-Minute MX/NS Health Check

If the domain is already experiencing trouble and you need a fast first pass, run:

dig example.com NS +short
dig +trace example.com NS

dig example.com MX +short
dig example.com TXT +short
dig _dmarc.example.com TXT +short

dig mx1.mail-provider.example A +short
dig mx1.mail-provider.example AAAA +short

dig example.com DS +short

Then query at least one authoritative nameserver directly:

dig @ns1.authoritative.example example.com SOA
dig @ns1.authoritative.example example.com MX
dig @ns1.authoritative.example example.com TXT

This small set usually separates four very different incidents: wrong authority, wrong MX data, broken MX target resolution and broken DNSSEC delegation.

What Should Be Verified After the Change?

Do not close the migration when the registrar shows the new nameservers. Close it when DNS and services agree.

Verify the public view:

dig example.com NS @1.1.1.1
dig example.com NS @8.8.8.8
dig example.com MX @1.1.1.1
dig example.com MX @8.8.8.8

Verify the authoritative view:

dig @ns1.authoritative.example example.com A
dig @ns1.authoritative.example example.com MX
dig @ns1.authoritative.example example.com TXT
dig @ns1.authoritative.example _dmarc.example.com TXT

Finally, test what users actually depend on: load the site over HTTPS, send a message from an external mailbox to the domain, send a message from the domain to an external provider, and inspect authentication results in the received headers.

MX and NS problems become much easier to diagnose once the services are separated conceptually. NS delegation decides which DNS zone the Internet trusts; the records in that zone then direct web, mail and other services independently. Most safe migrations come down to preserving that chain: correct parent delegation, correct authoritative data, resolvable MX targets and mail records that survive the move.