First ask how far the request got
A browser problem can begin before an HTTP response exists. A useful investigation separates name resolution, network connection, TLS setup, and the HTTP exchange. These stages interact, but they produce different evidence. An HTTP status reference cannot explain a DNS failure that prevented any server response.
| Stage | Useful evidence | Next step |
|---|---|---|
| DNS | Resolver response and requested record type | Check authoritative data and resolver behavior |
| Connection | Destination address, transport, port, timeout | Check listener, routing and network policy |
| TLS | Certificate or handshake error | Check name, dates, chain and endpoint |
| HTTP | Status, headers, URL and timing | Trace redirect or application/gateway response |
Worked example: the website opens but mail is failing
A working website usually says little about a domain’s mail configuration. The website can resolve and serve HTTPS while its MX records point elsewhere or outgoing mail fails authentication. Start with the failing mail direction: inbound delivery and outbound authentication require different checks.
For inbound mail, inspect MX routing and the provider’s delivery logs. For outbound mail, inspect a real message’s trusted authentication results and compare them with SPF, DKIM, and DMARC records. Use the email authentication guide for alignment. A good DNS score is not a guarantee of inbox placement.
Record the query, not just “DNS is broken”
Keep the queried name, record type, resolver, response code, and time together. An empty answer for one record type does not necessarily mean the name does not exist. A server failure is also different from a name-error response. Cached answers, delegation problems, and validation issues require different investigations. Google’s Public DNS troubleshooting guidance explains how to narrow resolver problems.
Comparing two resolvers can reveal disagreement, but it does not by itself identify which is correct. Check the authoritative configuration and relevant cache lifetime before repeatedly editing records. Internal split-DNS names may intentionally resolve differently inside an organization.
Capture only the operation you need
- Write down the exact failing action, hostname, and approximate time.
- Open the browser Network panel and reproduce one controlled attempt.
- Identify whether an HTTP response was captured. If so, record its status and any request ID.
- For redirects, preserve the sequence and inspect the final URL.
- If sharing a HAR, sanitize and inspect it for cookies, tokens, query data, and request bodies first.
HAR Viewer reads the recorded browser traffic. It cannot recover omitted requests or inspect server-to-server dependencies. A status of zero in a capture is not an HTTP status issued by a server. Use the gateway-errors guide when the browser received an actual 502, 503, or 504.
Choose a tool with the right scope
Email DNS Checker concentrates on mail records; it is not a general-purpose DNS console. WHOIS Lookup reads registration data, not your current website response. SSL Certificate Checker observes a public endpoint through an external service. Port Checker identifies conventional port uses without testing reachability. These distinctions prevent a reassuring result at one layer from closing an investigation at another.
Finish with a short record of what failed, which evidence changed after the fix, and whether the original action now succeeds. That makes the result reproducible for the next person who encounters the same symptom.
Try the related tools
Continue reading
Sources and review
Examples are illustrative. Reviewed September 29, 2026 against the listed references and the related tool behavior. Methodology · Report a correction.