Domain Troubleshooting SOP: DNS, Registration, SSL, and Email

This domain troubleshooting SOP provides a repeatable way to diagnose registration, DNS, website, email, SSL/TLS, and ownership problems. Start at the registration layer, then move through delegation, authoritative DNS, recursive resolution, and finally the application.

1. Identify the Exact Symptom

• Does the domain return NXDOMAIN, SERVFAIL, a timeout, or the wrong IP address?
• Is the failure global, regional, network-specific, or limited to one device?
• Does the website fail while email still works, or do all services fail?
• Did the problem begin after a renewal, nameserver change, DNS migration, DNSSEC change, or hosting move?

Record the domain, affected hostname, error message, time, location, resolver, and recent changes before modifying anything.

2. Check Domain Registration Status

Use an RDAP lookup or the registrar’s control panel to confirm that the domain is registered, not expired, and held in the correct account. Since January 2025, RDAP is the definitive source for generic top-level domain registration data, replacing legacy WHOIS delivery for this purpose.

Review EPP status codes. A status such as clientHold or serverHold can prevent the domain from being published in DNS. Confirm the registrar, expiration date, nameservers, and account contact details. If the domain recently expired, contact the registrar immediately and follow its renewal or redemption process.

3. Verify Nameserver Delegation

The registry delegates the domain to authoritative nameservers. Confirm that the nameservers shown at the registrar match the DNS provider that hosts the current zone.

dig NS example.com
nslookup -type=NS example.com

If the registrar points to old or incorrect nameservers, changes made in the intended DNS dashboard will have no effect. Also verify glue records when a nameserver is inside the same domain it serves, such as ns1.example.com.

4. Query the Authoritative DNS Servers

Query each authoritative nameserver directly. They should return consistent records and a valid Start of Authority (SOA) response.

dig @ns1.provider.example example.com A
dig @ns1.provider.example www.example.com CNAME
dig @ns1.provider.example example.com MX
dig @ns1.provider.example example.com SOA

If one authoritative server returns different data, fix zone synchronization. If all authoritative servers return the wrong value, correct the DNS zone at the provider.

5. Understand Common DNS Results

• NOERROR with an answer: DNS resolved successfully; continue to the application or network layer.
• NOERROR with no answer: the name exists, but the requested record type may not.
• NXDOMAIN: the queried name does not exist according to DNS.
• SERVFAIL: the resolver could not complete the query, often because of authoritative-server failure, delegation problems, or DNSSEC validation.
• Timeout: no response arrived; investigate reachability, firewall rules, or unavailable name servers.

6. Check DNS Records

• A/AAAA: map a hostname to IPv4 or IPv6.
• CNAME: aliases one hostname to another; it should not normally coexist with other data at the same name.
• MX: identifies mail exchangers. Confirm the target host resolves.
• TXT: commonly carries verification, SPF, DKIM, and other policy data.
• CAA: indicates which certificate authorities may issue certificates for the domain.
• SOA: provides zone authority and timing information.

Check for typographical errors, missing records, an old hosting IP, duplicate records, and unintended proxy settings.

7. Account for TTL and Caching

DNS changes are not pushed instantly to every resolver. Cached data remains until its time to live (TTL) expires. Different users may see different results because their resolvers cached records at different times. Negative answers can also be cached, so a newly created hostname may continue returning NXDOMAIN temporarily.

Before a planned migration, lower the relevant TTL in advance. After the migration is stable, return it to the normal value.

8. Troubleshoot DNSSEC

A mismatched DS record at the registrar and DNSSEC keys at the authoritative provider can cause validating resolvers to return SERVFAIL. This commonly occurs when nameservers change but an old DS record remains.

dig example.com A +dnssec
dig example.com A +cd

If the query succeeds with checking disabled but fails normally, investigate DNSSEC validation. Do not delete or replace DS records without confirming the correct key information and migration process with the DNS provider and registrar.

9. Test Recursive Resolvers and Local Caches

Compare the local resolver with multiple reputable public or organizational resolvers. If authoritative answers are correct but one resolver is stale, wait for cache expiry or contact the resolver operator. On an affected device, confirm the configured DNS servers and flush the local cache only after recording useful evidence.

10. Separate DNS from Website and SSL Problems

If DNS returns the intended IP, test the service directly. Confirm that the web server or load balancer accepts the hostname, the virtual host is configured, ports 80 and 443 are reachable, and the certificate covers the requested name.

curl -I https://example.com
curl -Iv https://example.com

A certificate error, HTTP 403/404/500 response, redirect loop, or connection refusal is not necessarily a DNS failure.

11. Troubleshoot Domain Email

Verify MX records, then confirm that each MX target has valid A or AAAA records. Review SPF, DKIM, and DMARC records for syntax and alignment. Check mail-server logs, queue status, reputation, and provider-specific delivery errors. Avoid publishing multiple SPF records at the same hostname.

12. Escalation Checklist

Send the responsible registrar, DNS provider, hosting provider, or mail provider:

• domain and affected hostname;
• registration and EPP status;
• delegated nameservers;
• authoritative and recursive query results;
• exact timestamps and source network;
• screenshots or command output without credentials;
• recent changes and their time;
• expected result versus actual result.

Useful Official Resources

Use ICANN Lookup for registration data, review ICANN EPP status codes, and consult your authoritative DNS provider’s current troubleshooting documentation.

Frequently Asked Questions

How long does DNS propagation take?

There is no single global timer. Cached answers remain according to TTL values, and negative caching or old delegation data can extend the period during which users see different results.

Why does a domain work on one network but not another?

Resolvers may hold different cached data, apply different filtering, or reach authoritative servers through different paths. Compare results from the affected resolver with authoritative answers.

What does SERVFAIL usually mean?

It means the resolver could not complete the query. Common causes include unavailable authoritative servers, delegation errors, and DNSSEC validation failure.