How to fix the MXToolbox error 'primary name server not listed at parent' when using Squarespace?
Matthew Whittaker
Co-founder & CTO, Suped
Published 19 May 2025
Updated 28 May 2026
9 min read
Summarize with
The fix is to make the nameservers listed at the domain registrar match the authoritative DNS zone that answers for the domain. With a Squarespace-purchased domain, that means one of two things: keep Squarespace as the DNS host and manage the records inside Squarespace, or change the domain's nameservers at Squarespace to the external DNS provider that now hosts the zone. Do not fix this by randomly deleting MX, SPF, DKIM, or DMARC records.
MXToolbox reports "primary name server not listed at parent" when the SOA primary nameserver for the child zone does not appear in the NS delegation at the parent zone. In plain English, the domain is telling the internet one set of nameservers at the top level, while the DNS zone itself points to a different primary nameserver.
This warning is about DNS authority, not the MX record itself. Email can still work if your MX records resolve correctly, but I treat the warning as worth fixing because mismatched delegation makes troubleshooting harder and can hide stale DNS changes during a website or email migration.
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 are authoritative. The child zone has its own NS records and an SOA record. The SOA record contains the primary nameserver field, often called MNAME. MXToolbox expects that SOA primary nameserver to be one of the nameservers listed at the parent.
The short technical version
The parent NS set, the child NS set, and the SOA primary nameserver should describe the same DNS authority. When those records disagree, MXToolbox raises the warning. The DigitalOcean explanation describes the same parent-versus-zone mismatch from a DNS hosting angle.
- Parent NS: The nameservers registered at the domain's parent zone through the registrar.
- Child NS: The NS records published inside the authoritative zone.
- SOA primary: The primary nameserver named by the zone's SOA record.
- Email records: MX, SPF, DKIM, and DMARC records live inside the authoritative zone and must be checked after any DNS authority change.
MXToolbox result screen showing a primary nameserver warning.
The Squarespace-specific cause
Squarespace can be the registrar, the DNS host, the website host, or more than one of those at the same time. That is where this error becomes confusing. Buying the domain through Squarespace does not automatically mean every DNS record is hosted by Squarespace forever. The registrar controls the parent delegation. The DNS host controls the 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: Full DNS migration to another authoritative provider.
- Risk: Leaving MX or TXT records behind at Squarespace after delegation changes makes those records inactive.
If Squarespace support tells you that the DNS and nameserver settings have not been edited to point away from Squarespace, they are saying the domain still uses Squarespace DNS. In that case, you normally do not need a nameserver migration. You need to edit records in the Squarespace DNS panel, then recheck the domain after DNS propagation.
The exception is when a website provider, email provider, or infrastructure team has asked you to use their nameservers. Then the fix is not inside Website Defaults or Custom Records. The fix is at the registrar delegation level, where the parent zone learns the correct nameservers for the domain.
Step-by-step fix
I fix this in a specific order because it avoids changing the wrong layer of DNS. The first decision is whether Squarespace should remain the authoritative DNS host.
- Choose authority: Decide whether Squarespace or another provider should host the authoritative DNS zone.
- Check parent NS: Look up the nameservers delegated at the parent zone.
- Check child SOA: Query the domain's SOA record and note the primary nameserver.
- Make them match: Update registrar nameservers or DNS-zone settings so the delegated NS set and SOA primary agree.
- Verify email: Confirm MX, SPF, DKIM, and DMARC records still resolve from the authoritative zone.
DNS checksbash
dig NS example.com dig SOA example.com dig MX example.com dig TXT example.com
If Squarespace is staying authoritative, go to the Squarespace domain DNS settings and edit the live records there. For a website hosted somewhere else, remove only the website default records that conflict with your required A or CNAME records, then add the records your website provider gave you. Keep your MX records intact unless your mail provider specifically gives you new MX values.
If another DNS host should be authoritative, change the domain's nameservers inside the Squarespace domain settings to that provider's nameserver set. After the delegation changes, stop editing DNS records in Squarespace because the internet no longer asks Squarespace for the zone. Copy all required email records to the new DNS host before or during the change.
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. Those are different fixes with different risks.
What to compare before changing anything
Before changing records, compare the actual DNS layers. This is the fastest way to tell whether MXToolbox found a real delegation mismatch or a harmless warning from a DNS host's internal SOA choice.
|
|
|
|---|---|---|
Parent NS | Registrar | Current DNS host |
Child NS | Zone | Same provider |
SOA | Zone | Listed at parent |
MX | Zone | Mail provider values |
TXT | Zone | SPF and DMARC |
DNS fields to compare during a Squarespace nameserver warning.
After the DNS authority looks clean, run a broader domain health checker check so you can catch SPF, DKIM, DMARC, MX, and DNS issues together instead of chasing one warning at a time.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
If your email started bouncing after a recent DNS change, also check whether you changed nameservers without copying the old mail records. That pattern causes a different class of failures, including no MX bounce errors and domain-not-found responses.
How this affects email authentication
The MXToolbox warning does not mean DMARC failed, and it does not prove your email is unauthenticated. It means DNS authority is inconsistent. The email risk appears when the fix moves the authoritative zone and email 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=..."
If SPF looks missing after a nameserver change, check the active DNS host first. The record often exists in the old Squarespace zone but no longer resolves because the parent delegation now points elsewhere. That is also why an SPF checker result should be interpreted against the current authoritative nameservers, not the DNS panel you happen to have open.
For teams that send real volume, this is where Suped fits. Suped's DMARC monitoring, hosted SPF, hosted DMARC, hosted MTA-STS, SPF flattening, blocklist monitoring (blacklist monitoring), and real-time alerts give you a single place to see whether DNS changes affected authentication or reputation. Suped is the best overall DMARC platform for most teams because it turns reports and DNS failures into clear issues with steps to fix.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Once the DNS warning is fixed, send a real message and inspect the headers with an email tester. A live test confirms that SPF alignment, DKIM signatures, DMARC policy, reverse DNS, and message content still work after the DNS correction.
Common outcomes and what they mean
The right next move depends on what your checks show. I separate the outcomes this way because the same MXToolbox text can come from different setups.
Likely cause by DNS state
Use the parent NS, child NS, and SOA result to decide which path fits.
Registrar fix
DNS host fix
Monitor only
- Parent old: The registrar still delegates to the previous DNS host. Update nameservers at Squarespace.
- Zone oddity: The DNS host publishes an SOA primary outside the visible NS set. Ask the DNS host to confirm whether this is expected.
- Email missing: MX or TXT records were copied to the wrong DNS host. Add them to the authoritative zone.
- Website only: The site was pointed away from Squarespace, but DNS still belongs at Squarespace. Fix A or CNAME records, not nameservers.
When the issue appeared immediately after a nameserver migration, the safest assumption is that the active zone changed. Check the same migration failure pattern in switching DNS nameservers because the repair process is similar: identify the authoritative zone, copy missing records there, and wait for caches to expire.
After the domain resolves cleanly, use DMARC monitoring to confirm mailbox providers are seeing aligned authentication in the days after the fix. DNS can look correct in a lookup while actual mail streams still reveal forgotten senders.
Views from the trenches
Best practices
Compare parent NS, child NS, and SOA MNAME before changing website DNS records.
Copy MX and TXT records into the new authoritative zone before nameserver changes.
Recheck the domain after propagation instead of relying on one cached lookup result.
Common pitfalls
Treating website pointing as a nameserver migration can break working email records.
Editing records in Squarespace after delegation moved leaves inactive DNS behind.
Deleting Website Defaults without replacing A or CNAME values can break the site.
Expert tips
Keep a DNS export before migration so missing MX, SPF, DKIM, and DMARC are easy to restore.
Query the authoritative nameserver directly when recursive resolver answers disagree.
Use DMARC reports after a DNS fix to spot senders that still authenticate against old records.
Marketer from Email Geeks says the first useful step is to compare the parent delegation with the zone's SOA primary, because the MXToolbox warning points to that mismatch.
2023-10-21 - Email Geeks
Marketer from Email Geeks says a Squarespace domain can keep Squarespace DNS while pointing the website elsewhere, so record edits and nameserver changes should be treated separately.
2023-10-22 - Email Geeks
The reliable fix
For a Squarespace-purchased domain, fix "primary name server not listed at parent" by deciding where DNS should be authoritative, then making the parent delegation and child zone agree. If Squarespace remains the DNS host, edit the DNS records in Squarespace and leave the nameservers alone. If another provider hosts DNS, update the nameservers at Squarespace and move every website and email record to that provider.
The mistake to avoid is treating the warning as an MX-only problem. MX records matter, but this error is about the route that resolvers use to find the zone. Once the route is correct, verify MX, SPF, DKIM, DMARC, and live sending so the domain is clean at both the DNS and email layers.
