What’s gone wrong?

Nine times out of ten, the problem isn’t your website. It’s your DNS. DNS, or the Domain Name System, is the internet’s phonebook. It’s the system that translates human-readable domain names (like elementor.com) into computer-readable IP addresses (like 35.190.132.231). When your site doesn’t show up, it’s usually because the phonebook is pointing to the wrong number.

How do you, a web creator, diagnose this? You don’t need to be a network engineer. You just need one tool: dig. This guide will show you how to use the dig command to solve your own DNS problems and launch your websites with confidence.

Key Takeaways

  • dig is Your DNS X-Ray: dig (Domain Information Groper) is a command-line tool that lets you look up any DNS record for any domain. It’s the professional’s choice for troubleshooting.
  • It Solves Real-World Problems: Use dig to confirm your ‘A’ record points to your new host, your ‘www’ CNAME is set up, your ‘MX’ records are ready for your email service, and your ‘TXT’ records are in place for domain verification.
  • Understand the Output: The dig output can be intimidating, but it’s simple once you break it down into the QUESTION (what you asked) and ANSWER (what the server said) sections.
  • Master a Few “Recipes”: You don’t need to learn every option. Commands like dig mydomain.com, dig mydomain.com MX, and dig mydomain.com +short will solve 90% of your problems.
  • Check Different Servers: Querying a public server like Google (@8.8.8.8) or Cloudflare (@1.1.1.1) lets you bypass your local cache and see what the rest of the world sees, helping you check if your DNS changes have “propagated.”

What is dig and Why Should Web Creators Care?

dig is a powerful command-line tool for querying the Domain Name System. It’s the modern, more powerful successor to older tools like nslookup. While you might be familiar with ping, which just checks if a server at an IP address is online, dig does something much more important: it tells you what the DNS system thinks about a domain.

As a web creator, you’re not just a designer. You’re the architect and project manager. When a site launch goes sideways, the client looks to you. Being able to say, “I’ve checked the DNS, and the A record is still pointing to the old server’s IP” is infinitely more professional than “I don’t know, let’s wait a few more hours.”

You should care about dig because it helps you:

  • Verify Your Launch: Instantly confirm that your domain’s A record is pointing to your new hosting provider’s IP address.
  • Troubleshoot Email: Check that your MX records are correctly set up for Google Workspace, Microsoft 365, or a transactional email service like Site Mailer by Elementor. If your contact forms are failing, it could be a DNS issue.
  • Check Subdomains: See if your www CNAME is properly aliased to your main domain or if your shop subdomain is pointing to the right platform.
  • Debug Propagation: See if a DNS change you just made is live by asking different DNS servers around the world.
  • Verify Domain Ownership: Confirm that the TXT record you added for Google Search Console or a new marketing service is correct.

dig gives you the raw data directly from the source, empowering you to solve problems instead of just waiting and guessing.

How to Install and Access dig

The good news is that dig is probably already on your computer.

On macOS

dig comes pre-installed on macOS. Just open your Terminal (you can find it in Applications > Utilities or by searching with Spotlight) and type dig -v. If you see a version number, you’re ready to go.

On Linux

Virtually all Linux distributions (Ubuntu, Debian, Fedora, etc.) come with dig. If for some reason it’s missing, you can install it as part of the dnsutils package. sudo apt-get install dnsutils (for Debian/Ubuntu) sudo yum install bind-utils (for CentOS/Fedora)

On Windows

Windows doesn’t include dig by default. You have two main options:

  1. Use Windows Subsystem for Linux (WSL): This is the best modern solution. If you have WSL installed (you can get it from the Microsoft Store), you can open a Linux terminal (like Ubuntu) and use dig just as you would on Linux.
  2. Download BIND Tools: dig is part of a software suite called BIND. You can download pre-compiled Windows versions from the Internet Systems Consortium (ISC), but this is often more hassle than it’s worth.
  3. Use an Online Tool: If you’re on a locked-down machine or just want a quick check, you can use a web-based dig tool. Google’s Public DNS admin page has a great one. Just search for “Google DNS dig” and you’ll find it. This is a great way to check from a neutral third party.

Understanding the dig Command Syntax

The basic syntax for dig looks like this:

dig [server] [domain] [record_type] [options]

Let’s break that down:

  • [server] (Optional): This is the specific DNS server you want to ask. If you leave this out, dig will use your system’s default DNS resolver (usually your router or ISP). To ask a specific server, you use an @ symbol, like @8.8.8.8 (Google’s public DNS).
  • [domain] (Required): This is the domain name you’re investigating, like elementor.com or my-new-client-site.com.
  • [record_type] (Optional): This is the type of DNS record you want to see. If you leave this blank, dig defaults to A (the IP address). Other common types are MX (mail), CNAME (aliases), TXT (text), NS (nameservers), and AAAA (IPv6).
  • [options] (Optional): These are special “flags” that change how dig behaves. The most common one you’ll use is +short, which gives you just the answer and nothing else.

For 90% of your work, your commands will look as simple as:

  • dig mywebsite.com
  • dig mywebsite.com MX
  • dig @1.1.1.1 www.mywebsite.com
  • dig mywebsite.com +short

Reading the Anatomy of dig Output (The “Wall of Text”)

The first time you run dig, you’ll get a block of text that can be intimidating. Don’t worry. It’s logically divided into sections. Let’s run dig elementor.com and break down the response.

; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> elementor.com

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48511

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 65494

;; QUESTION SECTION:

;elementor.com. IN A

;; ANSWER SECTION:

elementor.com. 300 IN A 35.190.132.231

;; Query time: 12 msec

;; SERVER: 127.0.0.53#53(127.0.0.53)

;; WHEN: Thu Oct 30 11:50:00 2025

;; MSG SIZE  rcvd: 58

Here’s what each part means.

The Header

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48511

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

The most important part here is status: NOERROR. This means the DNS server found an answer. If you see status: NXDOMAIN, it means “Non-Existent Domain,” and the server is telling you that domain doesn’t exist.

The flags are also useful:

  • qr: Query Response (this is a response, not a query).
  • rd: Recursion Desired (we asked the server to do a full lookup for us).
  • ra: Recursion Available (the server says it can do recursive lookups).

The Question Section

;; QUESTION SECTION:

;elementor.com. IN A

This is simply dig repeating your question back to you. It’s confirming, “You asked for the A record for elementor.com in the IN (Internet) class.” This is useful if you run a complex query and want to double-check what you actually asked.

The Answer Section

;; ANSWER SECTION:

elementor.com. 300 IN A 35.190.132.231

This is the gold. This is the entire reason you ran the command. Let’s read it from left to right:

  • elementor.com. The domain you asked about.
  • 300: This is the TTL (Time to Live) in seconds. 300 seconds is 5 minutes. This is critical for web creators. It’s the DNS server’s instruction to any other resolver (like your ISP or your browser) telling it how long to cache this answer. If your TTL is 86400 (24 hours), any DNS changes you make could take up to a day to show up for everyone. A low TTL like 300 is great for when you’re making changes.
  • IN: Internet class. You’ll always see this.
  • A: The record type, an A record.
  • 35.190.132.231: The Answer. This is the IPv4 address for elementor.com. When you’re launching a site, this is the IP address you want to see match the one your web host gave you.

The Authority and Additional Sections

(Not in this specific example, but often present)

  • Authority Section: This section tells you who is the authoritative source for this domain’s DNS. It will list the nameservers (NS) for the domain.
  • Additional Section: This section provides extra information, usually the IP addresses of the nameservers listed in the Authority section.

The Stats Section

;; Query time: 12 msec

;; SERVER: 127.0.0.53#53(127.0.0.53)

;; WHEN: Thu Oct 30 11:50:00 2025

;; MSG SIZE  rcvd: 58

This is just metadata about the query itself.

  • Query time: How long it took.
  • SERVER: What server answered you. In this case, 127.0.0.53 is a local resolver on my Linux machine. If you used @8.8.8.8, it would say 8.8.8.8#53 here.
  • WHEN: A timestamp.
  • MSG SIZE: Size of the response.

Practical dig Recipes for Web Creators

This is where the magic happens. Here are the most common, practical commands you’ll use, along with what the output means for you as a web creator.

Recipe 1: The Simple Lookup (Finding the IP Address)

This is your bread and butter. You just bought a new hosting plan, and they gave you an IP address. You went to your domain registrar, updated your ‘A’ record, and now you want to see if it’s working.

Command: dig my-new-site.com

What to look for: Look in the ANSWER SECTION for the A record.

;; ANSWER SECTION:

my-new-site.com. 3600 IN A 192.0.2.123

What this means: The internet’s phonebook says my-new-site.com is at the IP address 192.0.2.123. If this matches the IP your new host gave you, you’re good to go. If it still shows your old host’s IP, your change hasn’t propagated yet (or you made a mistake). Notice the TTL is 3600 (1 hour). This means even after the change, it could take up to an hour for some resolvers to ask for a new update.

Recipe 2: Getting Just the Answer

You don’t always want the whole “wall of text.” You just want the IP address, fast. The +short option is your best friend.

Command: dig my-new-site.com +short

Output: 192.0.2.123

What this means: This is perfect for quick checks. It gives you only the answer. No header, no question, no stats. Just the data.

Recipe 3: Checking Your “www” Subdomain (CNAME)

You’ve set up my-new-site.com, but what happens when someone types www.my-new-site.com? Usually, you set this up as a CNAME (Canonical Name) record, which is an alias that points to your main domain.

Command: dig www.my-new-site.com

What to look for: Look for a CNAME record in the ANSWER SECTION.

;; ANSWER SECTION:

[www.my-new-site.com](https://www.my-new-site.com). 3600 IN CNAME my-new-site.com.

my-new-site.com. 300 IN A 192.0.2.123

What this means: This output is a two-parter.

  1. The first line says www.my-new-site.com is an alias (CNAME) for my-new-site.com.
  2. dig is smart, so it then does a second lookup for my-new-site.com and gives you its A record as well. This is a perfect, correct setup. If you run this command and get status: NXDOMAIN, it means you forgot to create a record for www, and visitors who type it in will get an error.

Recipe 4: Verifying Your Mail Server (MX Records)

Your client says their contact forms aren’t sending emails. You’re using an Elementor Pro form, and you suspect the email delivery service isn’t set up. You need to check the MX (Mail Exchange) records.

Command: dig my-new-site.com MX

What to look for: The MX records in the ANSWER SECTION.

;; ANSWER SECTION:

my-new-site.com. 14400 IN MX 10 aspmx.l.google.com.

my-new-site.com. 14400 IN MX 20 alt1.aspmx.l.google.com.

What this means: The MX records have two parts: a priority and a server.

  • 10 and 20 are the priorities. The mail server will try the lowest number first (10). If that fails, it will try the next one.
  • aspmx.l.google.com. is the mail server. This output clearly shows the mail for my-new-site.com is handled by Google Workspace.

If you see this, but your client says they’re using Microsoft 365, you’ve found the problem. They have the wrong MX records. If this section is empty, it means no mail server is configured, which is a major issue. This is crucial for ensuring the reliability of transactional emails from your WordPress site.

Recipe 5: Checking Domain Verification (TXT Records)

You’re trying to add a site to Google Search Console, or set up an email security feature like SPF. Both of these services ask you to add a TXT record to your DNS to prove you own the domain.

Command: dig my-new-site.com TXT

What to look for: The TXT records in the ANSWER SECTION.

;; ANSWER SECTION:

my-new-site.com. 3600 IN TXT “google-site-verification=abc123xyz789”

my-new-site.com. 3600 IN TXT “v=spf1 include:_spf.google.com ~all”

What this means: This shows two TXT records.

  1. The first is a Google Search Console verification code. You can now see if it matches what Google gave you.
  2. The second is an SPF record, which authorizes Google’s servers to send email on behalf of my-new-site.com, reducing the chance of your emails being marked as spam.

If you added a TXT record but Google won’t verify it, run this command. You might find a typo, or that you forgot to save the change.

Recipe 6: Checking Your IPv6 Address (AAAA Records)

If your host supports modern IPv6, you’ll have an AAAA record (also called a “quad-A” record).

Command: dig my-new-site.com AAAA

What to look for: An AAAA record with a long, complex hexadecimal address.

;; ANSWER SECTION:

my-new-site.com. 3600 IN AAAA 2606:4700:3031::ac43:821b

What this means: Your site is accessible over IPv6. This is good for future-proofing. If this is empty, it’s not a problem, but it’s good to know.

Recipe 7: Finding the Authoritative Nameservers (NS Records)

You’re about to take over a client’s site, but you’re not sure where their DNS is actually managed. Is it at their registrar (like GoDaddy) or a third-party service (like Cloudflare)? The NS (Nameserver) record tells you.

Command: dig my-new-site.com NS

What to look for: The NS records in the ANSWER SECTION.

;; ANSWER SECTION:

my-new-site.com. 172800 IN NS ara.ns.cloudflare.com.

my-new-site.com. 172800 IN NS ben.ns.cloudflare.com.

What this means: This domain’s DNS is managed by Cloudflare. This tells you that you need to log in to Cloudflare—not GoDaddy—to make any A, CNAME, or MX record changes. This one command can save you hours of confusion.

Recipe 8: Querying a Specific DNS Server (Checking Propagation)

You just changed your ‘A’ record to point to your new Elementor Hosting IP. You run dig my-new-site.com but you still see the old IP. Why?

Your computer is likely using a cached (saved) answer from your local ISP’s DNS resolver. You need to bypass it and ask a big, public server what it sees.

Command: dig @1.1.1.1 my-new-site.com

What this means: The @1.1.1.1 tells dig to only ask Cloudflare’s public DNS server. You can also use @8.8.8.8 (Google) or @208.67.222.222 (OpenDNS).

If dig @1.1.1.1 my-new-site.com shows the new IP, but dig my-new-site.com (without the @) shows the old IP, you’ve just proven the change is live on the internet, but your local resolver is lagging. This is a propagation delay. You are correct, and all you have to do is wait for your local cache to expire. You can now confidently tell your client, “The change is live. It may take an hour or two for it to be visible everywhere.”

Recipe 9: The “ANY” Query (Getting All Records)

This is a great “shotgun” approach to see everything at once.

Command: dig my-new-site.com ANY

What this means: This will return all common records for the domain: A, AAAA, NS, MX, TXT, etc. It’s a fantastic overview of a domain’s entire DNS setup. (Note: Some servers are configured to ignore ANY queries for security, but it works most of the time).

Recipe 10: Tracing the Full DNS Path (Trace)

This is the advanced, pro-level command. This will show you every single step dig takes to find the answer, starting from the internet’s root servers.

Command: dig my-new-site.com +trace

What this means: The output will be long. It will first show dig asking the root servers (the . servers) where to find the .com servers. Then it will ask the .com servers where to find the nameservers for my-new-site.com (e.g., ara.ns.cloudflare.com). Finally, it will ask ara.ns.cloudflare.com for the ‘A’ record for my-new-site.com.

This is the ultimate tool for diagnosing complex problems, like when one specific nameserver is giving a bad answer.

Expert Tips from a Pro

As a web expert who has launched countless sites, I’ve learned a few things. My colleague and fellow expert, Itamar Haim, often emphasizes that “Understanding DNS is the difference between a web designer and a web professional.” Knowing how to use dig is a huge part of that.

Tip 1: Be Patient with TTL

I mentioned it before, but it’s the most important concept. If your dig query shows a TTL of 7200 (2 hours), you must be patient. Hitting refresh in your browser does nothing. Your ISP’s resolver will hold onto that old record for 2 hours. This is why, before a big site migration, it’s a best practice to log in 24 hours ahead and lower the TTL on your main ‘A’ record to something short, like 300 (5 minutes).

Tip 2: Flush Your Local DNS Cache

If dig @1.1.1.1 shows the new IP but your local dig and browser show the old one, your computer itself might have a local cache. You can flush it:

  • On macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
  • On Windows: ipconfig /flushdns
  • In Chrome: Go to chrome://net-internals/#dns and click “Clear host cache.”

Tip 3: dig vs. ping – Know the Difference

This is a classic rookie mistake.

  • ping my-new-site.com tells you: “Am I able to send a packet to the server at the IP I think my-new-site.com is at, and did it respond?”
  • dig my-new-site.com tells you: “What IP does the DNS system say my-new-site.com belongs to?”

Your site can be perfectly online (ping works), but your DNS can be pointed to the wrong server (dig shows the wrong IP). Or, your DNS can be correct (dig shows the right IP), but your server is down (ping fails). They are two different tools for two different problems.

Common DNS Problems You Can Solve with dig

Let’s put it all together.

Problem: “I just launched my site, but I still see my old host.”

  1. Run: dig my-new-site.com +short
  2. Analyze: Does it show the old IP or the new IP?
  3. If Old IP: Run dig @1.1.1.1 my-new-site.com +short.
  4. If @1.1.1.1 shows New IP: The change is live. Your local cache is stale. Wait for the TTL to expire, or flush your cache.
  5. If @1.1.1.1 shows Old IP: The change has not propagated, or you made a mistake at your registrar. Double-check your ‘A’ record settings.

Problem: “My website works, but www.my-new-site.com doesn’t.”

  1. Run: dig www.my-new-site.com
  2. Analyze: Look at the ANSWER SECTION.
  3. If status: NXDOMAIN: You forgot to create a DNS record for www. Go to your DNS manager and add a CNAME record for www that points to my-new-site.com.
  4. If it shows an A record with the wrong IP: You have an old, stale record. Update it to a CNAME.

Problem: “My contact form emails are going to spam or not arriving.”

  1. Run: dig my-new-site.com MX +short
  2. Analyze: Does this list the mail servers you expect? (e.g., Google, Microsoft, SendGrid). If it’s empty, you have no MX records.
  3. Run: dig my-new-site.com TXT
  4. Analyze: Do you see an spf record (e.g., “v=spf1 …”)? If not, unauthorized emails from your domain are more likely to be marked as spam. You need to add SPF, DKIM, and DMARC records.

Problem: “Google Search Console can’t verify my domain.”

  1. Run: dig my-new-site.com TXT
  2. Analyze: Look for the google-site-verification= record in the answer.
  3. Solution: Carefully compare the value with what Google gave you. It’s common to have a typo or to have forgotten the quotes. dig will show you exactly what the world sees.

dig and the Modern Web Creator

In the world of web creation, it’s easy to focus on the visual. Platforms like Elementor have made the design and build process more intuitive and powerful than ever, especially with integrated tools like Elementor AI to help write content and build layouts.

But launching a site is a technical event. dig is the bridge between your creative work and the live, public internet. It’s not some “scary” tool for network engineers. It’s your personal x-ray machine for looking “under the hood” of the internet.

Learning to use these simple dig “recipes” will elevate you from a designer to a true web professional. You’ll be able to diagnose launch-day problems in seconds, communicate with clients and hosts with authority, and take full, end-to-end ownership of your projects.

Frequently Asked Questions (FAQ)

1. What does dig stand for? dig stands for “Domain Information Groper.”

2. What’s the difference between dig and nslookup? nslookup is an older, now-deprecated tool. dig is the modern standard, is more powerful, and provides more detailed, easier-to-read output. While nslookup still works for basic queries, all professionals prefer dig.

3. What is dig +short? It’s an option that tells dig to only output the direct answer to your query (e.g., just the IP address or just the mail server) and skip all the headers and stats.

4. How do I check my mail (MX) records with dig? Use the command dig yourdomain.com MX. The ANSWER SECTION will show you the priority number and the name of your mail servers.

5. What does status: NXDOMAIN mean? NXDOMAIN stands for “Non-Existent Domain.” It’s the DNS system’s way of saying, “I have no record of that domain name.” It means you either have a typo in your command or the domain doesn’t exist (or at least, isn’t known to that server).

6. What is a TTL in DNS? TTL stands for “Time to Live.” It’s a number (in seconds) in a DNS record that tells resolvers how long they should “cache” (store) that answer before asking for a fresh copy. A TTL of 3600 means 3600 seconds, or 1 hour.

7. Why would I query a specific DNS server (like @8.8.8.8)? You do this to bypass your local (ISP or router) DNS cache. It helps you determine if a DNS change you just made is live on the public internet, or if you’re just seeing a stale, cached record locally.

8. How can dig help me with my new WordPress website? When you launch a new WordPress site, you’re pointing a domain to a new host. dig is the tool you use to confirm that your domain’s ‘A’ record is pointing to your new WordPress host’s IP address.

9. Does dig work on Windows? Not natively. The best way to use dig on Windows 10 or 11 is to install Windows Subsystem for Linux (WSL) and run it from a Linux terminal. Alternatively, you can use a web-based dig tool.

10. What does +trace do in a dig command? dig yourdomain.com +trace performs a full trace of the DNS query from the internet’s root servers. It will show you every step: from the root (.) to the TLD (.com) to your domain’s authoritative nameserver, and finally to the answer. It’s an advanced command for deep troubleshooting.