DNS issues are invisible until they aren't. You push a deployment, update a record, flip a nameserver, and then spend the next 20 minutes wondering why nothing is resolving the way it should. Or you're setting up email on a new domain and you have no idea whether your SPF record is malformed, whether your DKIM selector is even being read, or whether your MX records are pointing at the right mail server. These are the moments where having the right diagnostic tools in your workflow saves real time.
The dig command is the standard answer for DNS queries in any Linux or macOS terminal, and it's the right tool for many situations. But browser-based tools fill a gap that command-line tools don't: they're shareable. When you're coordinating a deployment with a client, a non-technical project manager, or a support team, sending someone a URL they can open in their browser beats walking them through a terminal command. Browser tools also tend to annotate records in plain English, which matters when you're staring at a TXT record and trying to remember which part is the DKIM public key and which part is the selector.
This list covers five tools that belong in a web developer's DNS debugging workflow. They aren't all browser-based -- dig and the Cloudflare DNS-over-HTTPS API are not -- but together they cover the full range of situations you'll run into: quick manual lookups, email deliverability debugging, post-deployment propagation checking, and programmatic DNS querying from scripts or CI pipelines.
1. dig (Command Line)
dig (Domain Information Groper) is the command-line tool you'll reach for when you need precise, unambiguous DNS output. It ships with most Linux distributions and macOS, and it gives you the raw DNS response with full control over which record type you're querying, which resolver you're using, and how much detail you want in the output.
For a quick MX lookup, the +short flag strips the verbose metadata and gives you just the data:
dig +short mx example.com
Output looks something like:
10 mail.example.com.
20 mail2.example.com.
You can also query a specific resolver directly, which is useful for testing whether a new record has reached a particular upstream nameserver:
dig @8.8.8.8 +short txt example.com
The dig man page covers every available flag and query type: https://linux.die.net/man/1/dig. For a reference on what record types actually mean -- A, AAAA, CNAME, MX, TXT, CAA, NS -- Cloudflare's DNS learning center is one of the clearer explainers available: https://www.cloudflare.com/learning/dns/dns-records/.
dig is the right tool when you need scriptable, repeatable output or when you're verifying a specific resolver's behavior. It's less useful when you want to hand a result to someone who doesn't have a terminal open.
2. DNS Lookup at EvvyTools
EvvyTools has a DNS lookup that annotates each record type in plain English -- useful when you're looking at a TXT record and can't remember which part is the DKIM selector or when you want to quickly check whether a CAA record is scoped correctly before requesting a TLS certificate.
The tool queries A, AAAA, CNAME, MX, TXT, NS, SOA, and CAA records. What makes it useful day-to-day is that it explains what each record does in context, so when you're reviewing a domain's full DNS health, you don't need to keep a separate reference tab open. It's particularly helpful for email diagnostics: checking MX priority values, reading SPF TXT records to verify allowed senders, or confirming that a DMARC policy is set correctly before enabling enforcement.
Photo by Markus Spiske on Pexels
Browser-based lookups like this also bypass any local DNS caching that might skew your results in a terminal query, which matters right after a record update when you want to see what external resolvers are returning rather than what your machine has cached.
3. MXToolbox SuperTool
MXToolbox's SuperTool (https://mxtoolbox.com/supertool.aspx) is purpose-built for email infrastructure. When you're working on email deliverability -- setting up a new sending domain, troubleshooting delivery failures, or hardening a domain against spoofing -- this is the first place to look.
The SuperTool checks SPF records and validates their syntax, verifies DKIM public keys, and checks whether a DMARC policy is present and correctly structured. It also runs blacklist checks, which tells you whether your sending IP or domain has ended up on any common mail reputation lists -- something that's easy to miss until your outbound email starts bouncing or landing in spam folders.
The interface is straightforward: type a domain, choose a lookup type, and get annotated results with a pass/fail status for each check. For developers who are setting up transactional email, configuring a third-party ESP (email service provider), or migrating email infrastructure between providers, MXToolbox surfaces the same checks that receiving mail servers are likely running against your domain.
"DNS debugging during a deployment usually starts with 'why isn't this resolving' and ends up in a two-hour detour through MX records and DKIM configuration. Having the right tools handy -- especially ones you can share with whoever else is on the call -- cuts that time significantly." -- Dennis Traina, 137Foundry
4. DNS Checker
DNS Checker (https://dnschecker.org/) solves a specific problem: you've updated a DNS record, but you can't tell whether it's actually propagated or whether you're seeing a cached result. DNS propagation isn't instantaneous, and it doesn't happen uniformly -- different geographic regions and different upstream resolvers will pick up changes at different times, usually within minutes to a few hours depending on the TTL of the original record.
DNS Checker queries your domain from multiple geographic locations simultaneously and shows you a map of which regions are returning your updated record and which ones are still returning the old value. This is useful after any record change -- A record updates during a server migration, CNAME changes when moving subdomains between services, or MX record updates when switching mail providers.
Photo by Brett Sayles on Pexels
It supports most common record types (A, AAAA, CNAME, MX, TXT, NS, PTR) and is fast enough to use repeatedly every few minutes while you're waiting for propagation to complete. If you're working across multiple time zones and want to confirm that users in a specific region are getting your updated records, the geographic breakdown is more useful than running dig against a single resolver.
5. Cloudflare 1.1.1.1 DNS-over-HTTPS API
For developers who need to query DNS from scripts, CI pipelines, or application code, Cloudflare's DNS-over-HTTPS API provides a clean HTTP interface to their 1.1.1.1 resolver. The full documentation is at https://developers.cloudflare.com/1.1.1.1/encryption/dns-over-HTTPS/make-api-requests/.
A basic MX lookup with curl looks like this:
curl "https://cloudflare-dns.com/dns-query?name=example.com&type=MX" \
-H "Accept: application/dns-json"
The response is JSON, which makes it easy to parse in any language without needing to call out to dig as a subprocess or install a DNS library. This is particularly useful in deployment scripts where you want to verify that a record has propagated before proceeding, or in monitoring scripts that need to check DNS health on a schedule.
The API supports all standard record types and returns structured data with TTL values, record data, and response codes. Since it runs over HTTPS, it works from environments where raw DNS traffic (UDP port 53) might be blocked or logged -- including some corporate networks and containerized build environments.
When to Use Which Tool
The right tool depends on what you're trying to do:
- dig: Use for scripting, automation, querying specific resolvers, or when you need precise raw output. The standard for any terminal-based DNS workflow.
- Browser-based lookup tools: Use for quick manual checks during development or deployment, or when you need to share results with teammates who don't have a terminal. Annotations help when you're not sure what a record value means.
- MXToolbox: Use when the problem is specifically email -- deliverability, SPF/DKIM/DMARC validation, or blacklist checks. Not a general-purpose DNS tool, but the best option for its specific use case.
- DNS Checker: Use after a record update to verify propagation across regions. Not useful for general DNS queries, but essential when you need geographic confirmation.
- Cloudflare DoH API: Use for programmatic DNS queries in scripts or applications. The right choice when you need DNS resolution as part of a build or monitoring pipeline rather than a manual check.
DNS Is One Layer of Web Infrastructure
DNS configuration is one layer of web infrastructure security. For the HTTP response layer, this guide on HTTP security headers covers what most web teams are missing at the server configuration level -- things like Strict-Transport-Security, Content-Security-Policy, and X-Frame-Options that aren't set by default on most hosting configurations but make a real difference for application security.
Wrapping Up
DNS debugging doesn't have to be a black box. The five tools covered here -- dig, EvvyTools DNS Lookup, MXToolbox, DNS Checker, and the Cloudflare DoH API -- cover the full range of situations you'll hit in a real deployment workflow. Use them in combination: dig for precise queries, a browser tool when you want annotations or need to share results, MXToolbox when email is the problem, DNS Checker when propagation is the question, and the DoH API when you're building something automated.
If you're working on web tooling more broadly, evvytools.com has a range of utilities in the dev-tech category -- DNS lookup, HTTP header inspection, JSON formatters, and similar tools that are useful to have accessible from a browser tab during development without needing to install anything locally.
Top comments (0)