Start with a name and a record type
The dig command lets you ask DNS a precise question: “What records of this type exist for this name?” Its basic form is dig name type. For example, dig example.com A requests A records for example.com. An A record supplies an IPv4 address. To request IPv6 addresses instead, use dig example.com AAAA. The record type is not a filter applied after a general lookup; it is part of the DNS question dig sends.
Replace example.com with the domain or hostname you want to check. A hostname such as www.example.com is a different name from example.com, so querying one does not necessarily tell you what is configured for the other. By default, dig asks the DNS resolver configured on your device. You do not need to know the domain’s authoritative nameserver to make a basic query.
Choose the type that matches your question
Different record types serve different purposes. Use dig example.com MX to request the mail-exchange records for a domain, or dig example.com TXT to inspect its text records. Email-related settings are often stored in TXT records, but asking for TXT does not single out a particular email policy: read the returned values to identify the one you need. Use dig example.com NS to request nameserver records and dig example.com SOA to request the start-of-authority record.
For an alias, try dig www.example.com CNAME. A CNAME belongs to a particular name, so a CNAME at www.example.com says nothing by itself about example.com. Also, not every hostname uses a CNAME; it may have address records instead. If you are unsure which name to test, check the exact hostname used by the website, email setting or service you are troubleshooting.
Avoid treating dig example.com ANY as a shortcut for “show me everything.” DNS servers may limit or handle ANY queries in ways that do not provide a complete list of records. Separate queries for the types you care about are easier to interpret.
Read the response, not just the answer line
Run dig example.com MX without extra options when you are diagnosing a problem. The QUESTION SECTION shows the name and type you asked for. The header shows a response status, and the ANSWER SECTION lists records returned for that question. An MX answer typically includes a preference number and a mail-server hostname. The server and query-time lines describe how this particular lookup was answered; they do not prove that every resolver sees the same response.
For a compact view, add +short, as in dig example.com MX +short. This is useful when you only need the returned values, but it hides context such as the response status. Another option, dig example.com MX +noall +answer, displays the answer section while omitting much of the other output. If either shortened command prints nothing, rerun the plain command before deciding what happened.
A successful DNS response can have an empty ANSWER SECTION: the name may exist without the record type you requested. By contrast, an NXDOMAIN status indicates that the queried name was not found by that lookup. A timeout indicates that dig did not receive an answer in time; it is not evidence that the record is absent.
Compare answers carefully when troubleshooting
DNS changes may not appear to every resolver at once because resolvers can cache earlier answers for a period set by DNS time-to-live values. If an answer seems unexpected, first confirm the spelling of the name and the requested type. Then consider whether you are asking about the domain itself, such as example.com, or a hostname beneath it, such as mail.example.com. These are separate queries.
You can direct dig to a particular DNS server by putting its address after @: dig @<server-address> example.com MX. Substitute the address of a DNS server you intend to query; the angle-bracketed text is only a placeholder. Comparing your usual resolver’s reply with a known authoritative server’s reply can help distinguish a cached response from the server’s currently published data. Make sure the server you choose is authoritative for the name being checked before interpreting that comparison.
For routine checks, the simplest habit is to name both the hostname and the type explicitly, then inspect the full response if the result is surprising. That keeps the question narrow and makes an absent answer easier to investigate without guessing what dig searched for.
