DNS Lookup Command Generator - dig, nslookup, PowerShell

What a DNS lookup actually does

DNS turns names into data. When you type mavistools.co, your computer asks a recursive resolver (your ISP's, your router's, or a public one like 1.1.1.1) for the A record. If the resolver has a fresh cached answer, it replies immediately. If not, it walks the hierarchy: a root server points to the .co servers, which point to the domain's authoritative nameservers, which hold the real answer. The resolver caches that answer for as long as its TTL (time to live) says, then asks again.

The commands on this page ask that same question from your terminal, and show you the raw answer without a browser, cache extension, or CDN in the way. That is the fastest way to confirm what the world actually sees for your domain.

Which command to use

dig is the standard on macOS and Linux. dig example.com MX +short prints just the answers; +noall +answer adds the TTL and record type, which is what you want when debugging caching. Add @1.1.1.1 to ask a specific resolver.

nslookup is built into Windows, macOS, and Linux. The syntax is nslookup -type=MX example.com, with an optional server at the end. It is older and chattier but always available.

Resolve-DnsName is the modern Windows option in PowerShell, and returns structured objects you can pipe into other commands. host is a compact alternative to dig on Unix systems.

Worked example: verifying a new email setup

You just moved a domain's email to Google Workspace. Four checks confirm it. First, MX: dig example.com MX +short should list smtp.google.com (or the older aspmx.l.google.com set). Second, SPF: dig example.com TXT +short should include a line starting v=spf1 with include:_spf.google.com. Third, DKIM: dig google._domainkey.example.com TXT +short should return a long v=DKIM1 key. Fourth, DMARC: dig _dmarc.example.com TXT +short should return v=DMARC1 with a policy.

Since February 2024, Google and Yahoo require SPF or DKIM for all senders and DMARC for anyone sending more than 5,000 messages a day to their users. If any of these lookups returns nothing, that is why mail is bouncing or landing in spam.

Checking propagation the right way

"Propagation" is really cache expiry. When you change a record, the authoritative nameserver updates in seconds. Resolvers that cached the old answer keep serving it until the old TTL runs out. If your old A record had a TTL of 3,600, some users may see the old IP for up to an hour.

To check, run the same command against several public resolvers using the DNS server menu: Cloudflare (1.1.1.1), Google (8.8.8.8), and Quad9 (9.9.9.9). If all three return the new value, the change is effectively live. Pro tip: lower the TTL to 300 a day before a planned migration, then raise it again afterward.

Common mistakes

Pasting a full URL. DNS knows nothing about https:// or /path. The helper strips those automatically, but in your own scripts query the bare hostname.

A CNAME at the root domain. The DNS spec does not allow a CNAME on example.com itself alongside the SOA and NS records. Providers work around this with ALIAS, ANAME, or CNAME flattening. If a host tells you to add a CNAME for the apex, use your provider's flattening feature instead.

Two SPF records. A domain must have exactly one TXT record starting v=spf1. Two records make SPF fail outright. Merge the include: entries into a single record.

Trusting only your local machine. Your laptop and router cache aggressively. Always confirm with a public resolver before deciding a change did not work.

Reverse lookups and SRV records

Enter an IP address and the helper switches to reverse (PTR) lookups: dig -x 8.8.8.8 returns dns.google. Mail providers compare a sending server's PTR record against its hostname, so self-hosted mail servers need one set by whoever owns the IP, usually your hosting company.

SRV records locate services and use names like _sip._tcp.example.com or _minecraft._tcp.example.com. Query the full underscore name, not the bare domain.