What SERVFAIL tells you
When a DNS query returns SERVFAIL, a DNS server is saying it could not complete the request successfully. It is not the same as NXDOMAIN, which says the requested name does not exist. Nor does SERVFAIL, by itself, tell you whether the domain’s website, mail service or DNS records are misconfigured. The failure may have occurred at the resolver you asked, at an authoritative nameserver for the domain, or somewhere along the path between them.
A resolver normally follows the domain’s delegation to find authoritative nameservers, asks them for an answer, and may validate that answer using DNSSEC. A failure at any of those stages can prevent it from returning a usable result. SERVFAIL is therefore a symptom to investigate, not a diagnosis. Start by recording the exact name and record type that failed, such as an A record for www.example.net or an MX record for example.net. Different queries can produce different results.
Establish the scope of the failure
First, repeat the query and note whether the problem is consistent. A command such as dig example.net A shows both the response status and the server that answered. If you do not have dig, nslookup example.net can provide a basic comparison. Avoid relying only on a browser error: browsers and operating systems may cache results, and a web connection can fail even when DNS is working.
Next, compare results using another network or resolver you trust. If only one device or network sees SERVFAIL, investigate its configured resolver, connectivity, filtering settings and cached results. If several independent resolvers fail for the same name, a problem with the domain’s delegation, authoritative DNS or DNSSEC becomes more plausible. A comparison is a clue rather than proof: resolvers can hold different cached data, and some apply their own filtering policies. If you use a third-party resolver for testing, remember that it will receive the name you query.
Check whether the failure follows a record or a domain
Try a few relevant record types without changing any settings. For a website issue, compare the A and AAAA results for the affected hostname. For a mail issue, check the domain’s MX result and then the address records for the mail hostnames it names. If one query fails while others succeed, focus on the affected name, record type or DNSSEC proof needed for that answer. If many names and record types under the same domain fail, look higher up the DNS path.
Also check the exact spelling of each hostname, including its subdomain. A working result for example.net does not guarantee that www.example.net works. Likewise, a SERVFAIL response to one name should not be taken as evidence that every service on the domain is unavailable. Keeping a short list of the queries and responses you tested makes comparisons easier and helps when you contact a DNS provider.
Look at delegation and authoritative DNS
A domain depends on nameserver information published by its parent zone. If that delegation points to nameservers that cannot be reached or do not answer properly for the domain, recursive resolvers may return SERVFAIL. A trace command, such as dig +trace example.net A, can help show where the lookup stops. A trace follows delegation directly, however, and does not reproduce every check made by a validating resolver; treat it as one diagnostic view.
If you manage the domain, compare the nameservers listed at the registrar with the nameservers intended by your DNS provider. Check that each authoritative server is reachable and serves the expected zone. DNS changes can take time to appear consistently because resolvers cache information, but a persistent mismatch or an unreachable server calls for closer attention. If you do not manage these settings, pass the failing name, record type and query results to the person or provider who does.
Consider DNSSEC and choose the next action
DNSSEC lets validating resolvers check that DNS answers are authentic. If validation fails, a resolver may return SERVFAIL rather than pass along an answer it cannot verify. Possible causes include a mismatch between the parent zone’s DS record and the domain’s current keys, or invalid or expired signatures. DNSSEC becomes a stronger suspect when validating resolvers fail but the authoritative servers appear to answer. That pattern still needs confirmation; not every SERVFAIL is a DNSSEC problem.
If a recent nameserver or DNSSEC change preceded the failure, review the change with your DNS provider or domain administrator. Do not disable DNSSEC simply to make a test pass: changing DS records or keys without a coordinated plan can create or prolong an outage. If instead the failure occurs only on one network, start with that network’s resolver and settings. Work from the narrowest confirmed symptom toward the shared dependency, changing one thing at a time so you can tell what helped.
