DNSSEC SERVFAIL After Changing DNS Provider: How to Fix It
The short answer (what's causing it)
If the registrar still holds a DS record for the old provider's key, validating resolvers can't verify the new zone and return SERVFAIL — the domain appears offline for some users and mail can bounce.
Step-by-step fix
- Confirm with a validating resolver (e.g.
dig @1.1.1.1 yourdomain) and a non-validating check (+cd). - Remove the old DS at the registrar, or
- Enable DNSSEC at the new provider and publish its DS.
- Wait for TTLs, then re-scan.
Record examples (replace example.co.uk with your domain)
dig @1.1.1.1 example.co.uk A # SERVFAIL
dig @1.1.1.1 example.co.uk A +cd # answers -> DNSSEC chain broken
example.co.uk. DS 12345 13 2 <digest-from-new-provider>
Examples are illustrative templates, not values for your domain. Test changes at
p=none/ staging first.
Check yours free in seconds
Run the free 20-check SuperTool on your domain: no signup, no install, public DNS only. Relevant checks: DNSSEC, SOA.
Scan my domain free (20-check SuperTool) →No FaultyPacket pack covers this specific topic, so we only recommend the free scan here.
Frequently Asked Questions
Should I just turn DNSSEC off?
Removing the DS restores service; re-enable properly afterwards.
How do I avoid this next time?
Disable DNSSEC (remove DS) and wait out TTLs before migrating, or do a multi-signer migration.
Related FaultyPacket guides & tools
- Free 20-check SuperTool
- Website hosting & MX records DNS setup 101
- NIS2 & DORA supplier posture auditor
Authorised use: only scan domains you own or are authorised to inspect. Results are point-in-time public DNS observations.