How to fix the MXToolbox error 'primary name server not listed at parent' when using Squarespace?
Published 19 May 2025
Updated 17 Oct 2026
13 min read
Summarize with
Updated on 17 Oct 2026: We clarified Squarespace nameserver checks and added DNSSEC troubleshooting for failures after a DNS move.
Start by deciding whether this is a real delegation mismatch or only an SOA MNAME warning. If the nameservers at the parent zone differ from the authoritative NS records in the child zone, update the registrar delegation or the active DNS zone so those NS sets match. If the NS sets already match and answer consistently, the DNS host might intentionally use an SOA primary that is not public. Do not change MX, SPF, DKIM, or DMARC records merely to clear this warning.
MXToolbox reports "primary name server not listed at parent" when the SOA MNAME for the child zone does not appear in the NS delegation at the parent zone. That can indicate stale nameservers after a migration, but it can also describe a managed DNS design with a hidden or unlisted primary.
This warning is about DNS authority, not the MX record itself. It does not by itself damage email deliverability or prove that email authentication has failed. It is worth investigating because mixed parent and child NS records can cause inconsistent lookups, while an MNAME-only difference can be harmless when the authoritative DNS provider confirms it is intentional.
What the MXToolbox error means
A domain has a delegation at the parent zone, such as the .com zone, and a child zone hosted by the authoritative DNS provider. The parent delegation says which NS records resolvers should query. The child zone has its own NS records and an SOA record. The SOA record contains the primary nameserver field, called MNAME. MXToolbox flags the result when that MNAME is absent from the parent NS set.
The short technical version
The parent NS and child NS sets should name the same authoritative servers, regardless of record order. The SOA MNAME usually names one of those servers, but DNS terminology in RFC 9499 allows a primary to be named by MNAME without requiring an NS record for it. A hidden primary is therefore not automatically a delegation fault.
- Parent NS: The nameservers delegated by the parent zone through the registrar.
- Child NS: The authoritative NS records published inside the child zone.
- SOA MNAME: The zone's primary for updates or transfers, which a managed provider can keep outside the public NS set.
- Email records: MX, SPF, DKIM, and DMARC records live inside the authoritative zone and need checking after any DNS authority change.
MXToolbox primary name server not listed at parent warning for a Squarespace domain.
Check your Squarespace nameserver settings
Squarespace can be the registrar, the DNS host, the website host, or more than one of those at the same time. Buying the domain through Squarespace does not mean every DNS record must remain there. The registrar controls the parent delegation, while the authoritative DNS host controls the child zone records.
Keep Squarespace DNS
Use this path when you only need to point the website somewhere else or add email records. The parent nameservers should remain set to the Squarespace DNS nameservers, and you edit A, CNAME, MX, and TXT records inside Squarespace.
- Best for: Website pointing, email setup, and normal DNS record edits.
- Risk: Deleting default records without replacing required A or CNAME records breaks the website.
Move DNS hosting
Use this path when another DNS provider hosts the authoritative zone. You change the nameservers at the registrar level in Squarespace, then manage every record at the new DNS host.
- Best for: A complete DNS migration to another authoritative provider.
- Risk: Records left only in Squarespace become inactive as resolvers start using the new delegation.
If the domain still uses Squarespace's default nameservers, records in the Squarespace DNS settings panel remain active. A different SOA MNAME alone does not mean those records are broken. When parent and child NS sets already match, ask Squarespace to confirm whether the SOA value is provider-managed instead of moving nameservers solely to silence the warning.
Squarespace's default nameserver hostnames can end in .googledomains.com, .nsone.net, .squarespacedns.com, or .systemdns.com. An unfamiliar suffix alone does not mean the domain uses the wrong provider. Compare the full assigned hostnames with the parent delegation. Squarespace's nameserver instructions list these suffixes and the current controls.
If another provider should host the zone, open the Domains dashboard, select the domain, choose DNS, and open Domain Nameservers. Choose Use Custom Nameservers, complete account verification and the DNSSEC prompt, enter the full nameserver set assigned to your zone, and save. Recreate the website and email records at the new DNS host before the switch. Squarespace advises allowing up to 48 hours for nameserver changes; cached answers can continue using the old zone until their TTLs expire.
Step-by-step fix
Check each DNS layer in sequence to avoid changing the wrong configuration. The first decision is whether Squarespace or another provider should remain the authoritative DNS host.
- Choose authority: Decide whether Squarespace or another provider should host the authoritative DNS zone.
- Check parent NS: Find the nameservers delegated by the parent zone, not only the values shown in an account panel.
- Check child NS: Query the authoritative zone and compare its NS set with the parent set, ignoring record order and hostname letter case.
- Inspect SOA MNAME: Note the primary name and determine whether it signals an old host or an intentional managed primary.
- Fix a real mismatch: Correct a confirmed delegation or authoritative-zone fault. For an MNAME-only warning, ask the DNS host whether the SOA value needs correction.
- Verify service records: Confirm website, MX, SPF, DKIM, and DMARC records resolve from the authoritative zone.
Compare parent delegation and authoritative DNS answersbash
dig +trace NS example.com # For example.com, query a .com parent server directly dig @a.gtld-servers.net example.com NS +norecurse dig @ns1.example-dns.net example.com NS +norecurse dig @ns1.example-dns.net example.com SOA +norecurse dig @ns1.example-dns.net example.com MX +norecurse dig @ns1.example-dns.net example.com TXT +norecurse dig @ns1.example-dns.net _dmarc.example.com TXT +norecurse dig @ns1.example-dns.net selector1._domainkey.example.com TXT +norecurse
Replace example.com and the example authoritative server with your domain and a server returned by its parent delegation. For a domain outside .com, use an immediate parent server identified by the trace instead of a.gtld-servers.net. Repeat the authoritative queries for every delegated server, and replace selector1 with each active DKIM selector. A root-domain TXT query alone does not check DMARC or DKIM.
For child-zone answers, look for the aa flag, which indicates an authoritative response. A delegated server that is not authoritative for the zone is a lame delegation. Matching NS answers and current SOA serials support a consistent setup, but compare the required service records too: identical serials alone do not prove identical zone contents. Investigate repeated timeouts, SERVFAIL responses, or different NS sets.
If Squarespace is staying authoritative, edit the live records in its DNS settings. For a website hosted somewhere else, remove only website default records that conflict with the required A or CNAME records, then add the values supplied by the website host. Keep MX records intact unless the mail provider gives you replacement values.
If another DNS host should be authoritative, change the domain's nameservers in Domain Nameservers and manage the zone at the new host. Copy all required website and email records before the change, and keep the old zone available while cached delegations expire. Once a resolver uses the new nameservers, edits made only in Squarespace's DNS records panel have no effect on its answers.
Do not confuse website pointing with nameserver delegation
Deleting Squarespace Website Defaults and adding Custom Records points the website to a different host while Squarespace still hosts DNS. Changing nameservers moves the whole authoritative zone. Adding an NS record in Custom Records delegates a subdomain; it does not replace the root domain delegation controlled by Domain Nameservers.
Check DNSSEC if lookups fail after a nameserver change
A stale DNSSEC DS record at the parent can cause SERVFAIL even when the new nameservers answer correctly. The DS record must match a DNSKEY used to validate the new zone. This is a separate fault from an SOA MNAME warning. RFC 4035 defines the DNSSEC validation behavior.
Compare validating and checking-disabled DNS responsesbash
# Replace the resolver address with your validating resolver dig @192.0.2.53 example.com MX +dnssec dig @192.0.2.53 example.com MX +dnssec +cdflag dig @a.gtld-servers.net example.com DS +dnssec +norecurse dig @ns1.example-dns.net example.com DNSKEY +dnssec +norecurse
Replace the example resolver address, domain, and authoritative server before running these commands. For other domain endings, use the parent server from your trace instead of a.gtld-servers.net. If the first query fails but the same resolver returns data with +cdflag, investigate DNSSEC validation. The +cdflag option requests checking-disabled data for that query; it does not repair the domain or disable DNSSEC globally. A DS mismatch is one cause, so check signatures and DNSKEY data too.
In Squarespace, select the domain, then open DNS and DNSSEC. Its custom-nameserver workflow prompts you to disable built-in DNSSEC. If an old DS remains, coordinate its removal or replacement with the registrar and DNS host, allowing cached DS records to expire. For a signed replacement zone, publish the DS supplied by the new host once its signing is verified. Follow Squarespace's DNSSEC instructions; do not disable DNSSEC merely to clear an MNAME-only warning.
What to compare before changing anything
Compare the actual DNS layers before editing records. This shows whether MXToolbox found a delegation mismatch, an order-only difference, cached data, or an intentional SOA choice made by the DNS host.
|
|
|
|---|---|---|
Parent NS | Parent zone | Intended authoritative set |
Child NS | Authoritative zone | Same names as parent, in any order |
SOA MNAME | Authoritative zone | Provider's primary, with public NS listing optional |
SOA serial | Each authoritative server | Current zone version; investigate persistent differences |
MX and authentication records | Authoritative zone | Current MX, SPF TXT, DKIM TXT or CNAME, and DMARC TXT values |
DNS fields to compare during a Squarespace nameserver warning.
After checking DNS authority, use Suped's domain health checker to review email authentication and DNS results together instead of treating one warning as the cause of every email problem.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
If email started bouncing after a recent nameserver change, check whether the new zone is missing the old mail records. Missing MX records and an MX host configuration error require different checks. Missing MX alone does not mean NXDOMAIN: SMTP delivery rules include fallback to the domain's A or AAAA records when no MX exists. A mail server reached through incorrect routing can also reject a domain it does not accept mail for.
When the warning can be ignored
Do not change nameservers only to make the MXToolbox warning disappear. An SOA MNAME can identify a provider's hidden or unlisted primary while separate public nameservers answer queries for the zone. Record order also has no effect on whether two NS sets match.
- Parent and child NS match: Both sets contain the same hostnames, even if the displayed order differs.
- Authoritative answers agree: Every delegated server returns the expected NS set and service records, with no persistent unexplained SOA serial differences.
- Services resolve normally: Website, MX, and authentication records return without intermittent failures.
- The DNS host confirms the design: The MNAME belongs to its managed or hidden primary system.
When not to ignore it
Act when parent and child NS hostnames differ, old and new DNS providers are mixed, delegated servers time out, SOA serials disagree for an extended period, or lookups alternate between correct and missing records. Those symptoms require investigation beyond the MNAME warning. Send support the parent NS referral and direct NS, SOA, and failed service-record responses, including timestamps.
How this affects email authentication
The MXToolbox warning does not mean DMARC failed, and it does not prove email is unauthenticated. The email risk appears when a real nameserver change moves the authoritative zone and required records are not copied correctly.
Records to preserve during a DNS movedns
example.com. MX 10 mail.example-mailhost.net. example.com. TXT "v=spf1 include:sender.example -all" _dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com" selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=..."
These are illustrative placeholders. Copy your existing values, including the current DMARC policy and reporting destination, rather than publishing this example. Preserve DKIM CNAME records where your sender uses them, plus records for sending subdomains and custom return-path domains. Do not replace an enforced DMARC policy with p=none as part of a DNS move.
If SPF looks missing after a nameserver change, check the active DNS host first. The record often still exists in the old Squarespace zone but no longer resolves because the parent delegation points elsewhere. Interpret a result from Suped's SPF checker against the current authoritative nameservers, not whichever DNS panel is open.
Suped, our DMARC reporting and email authentication platform, groups mailbox-provider reports so you can compare SPF and DKIM alignment by sending source before and after a DNS move. Use those reports to investigate senders affected by records left in the old zone. Aggregate reports arrive after the reported mail activity, so use direct DNS queries and a live message test for immediate checks.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Once the DNS checks are clean, send a real message and inspect the headers with Suped's email tester. A live test checks authentication for that message and sending path. A DMARC pass needs either a passing SPF result with the required domain match or a passing DKIM signature with that match. It does not require both, and one successful test does not verify every sender or guarantee inbox placement.
Common outcomes and what they mean
The next action depends on the observed DNS state. The same MXToolbox warning can appear in a genuine migration error or a working managed DNS setup.
- Parent points to the old host: The registrar still delegates to the previous DNS provider. Update Domain Nameservers at Squarespace.
- Parent and child NS match: Investigate the SOA MNAME, but do not change delegation if the provider confirms an intentional hidden primary.
- Authoritative answers differ: Ask the DNS host to correct stale zone data or delegation across its nameservers.
- Email records are missing: Add required MX, TXT, or CNAME records to the authoritative zone, not the inactive Squarespace panel.
- Only the website moved: Keep Squarespace DNS and fix the A or CNAME records instead of changing nameservers.
When the issue appears immediately after a nameserver migration, check the same failure pattern described in switching DNS nameservers. Identify the authoritative zone, copy missing records there, query each authoritative server, and wait for caches to expire.
After the domain resolves cleanly, use Suped's DMARC monitoring to review authentication results from participating receivers as reports arrive after the fix. DNS lookups can appear correct while DMARC reports still reveal a forgotten sender.
Practical DNS troubleshooting tips
Best practices
Compare parent and child NS sets, then inspect the SOA MNAME before changing DNS records.
Copy MX and authentication records into the new authoritative zone before changing nameservers.
Recheck the domain after cached delegations expire instead of trusting one cached lookup.
Common pitfalls
Treating website pointing as a nameserver migration can break working email records.
Editing records only in Squarespace after delegation moves leaves the active zone unchanged.
Deleting Website Defaults without replacement A or CNAME records can break the website.
Expert tips
Keep a DNS export before migration so missing MX, SPF, DKIM, and DMARC are easy to restore.
Query every delegated nameserver directly when recursive resolver answers disagree.
Use DMARC reports after a DNS fix to spot senders affected by missing authentication records.
