DNSSEC SERVFAIL after a provider change usually means the chain of trust still points at signing data that no longer matches the authoritative zone. Do not “fix WordPress” or randomly edit A records until you verify the registrar DS record, current nameservers and the zone’s DNSKEY signatures as one chain.
Confirm that failure is DNSSEC-specific
Compare validating and non-validating resolvers and inspect DNSSEC status. If unsigned resolution works but validating resolvers return SERVFAIL, focus on the trust chain.
Read the DS at the parent
The registrar/registry DS is outside the child DNS zone. Record key tag, algorithm and digest and compare with the keys currently signing the authoritative zone.
Check the new provider signing state
Determine whether DNSSEC is enabled at the new provider and which DNSKEY is active. A new zone can be correct while the old DS remains published at the parent.
Choose safe recovery order
Either publish the matching new DS after the new zone is correctly signed, or remove the stale DS and wait for parent TTL before relying on an unsigned zone. Avoid toggling repeatedly.
Respect caches and TTLs
SERVFAIL can persist at validating resolvers after the authoritative fix. Track parent and resolver cache windows instead of making additional changes during propagation.
Validate end to end
Query DS, DNSKEY and signed answers from independent resolvers, then test HTTP/HTTPS. Only after DNS is trustworthy should application debugging resume.
Use the pre-DNS-switch checklist and compare split traffic with the old-server DNS guide.