How to check TXT records with dig

Domain owners publish text values in DNS for service verification, email authentication, and security policy. Checking TXT records with dig shows the exact strings a resolver can see for a domain, policy name, or selector before a provider token, SPF rule, DKIM key, or DMARC policy is treated as missing.

dig asks the resolver configured on the workstation unless a server is named with @server. A TXT answer row shows the owner name, TTL, class, record type, and quoted text data. The quoted value is the DNS presentation form, not extra shell quoting to remove from a policy string.

Check the exact owner name that the service expects. Root-domain TXT records, _dmarc policy records, and DKIM selector names are different DNS questions. A name can exist with no TXT answer, while a misspelled name returns NXDOMAIN, so read the status and answer count before editing the zone.

1. Query the exact name for TXT records with status and answer rows visible.

   $ dig +noall +comments +answer example.com TXT
   ;; Got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR
   ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
   
   ;; ANSWER SECTION:
   example.com.		377	IN	TXT	"v=spf1 -all"
   example.com.		377	IN	TXT	"_k2n1y4vw3qtb4skdx9e7dxt97qrmmq9"

   NOERROR means the resolver returned a DNS response for the name. The ANSWER count shows how many TXT rows matched the query.

2. Read each TXT answer row from left to right.

   The fields are owner name, TTL in seconds, class, type, and text data. TTL values can differ between repeated checks because recursive resolvers cache answers.

3. Print compact TXT values when the status has already been checked.

   $ dig +short example.com TXT
   "v=spf1 -all"
   "_k2n1y4vw3qtb4skdx9e7dxt97qrmmq9"

   +short removes the DNS status, owner name, TTL, class, and type. Keep the normal output when the response code or answer count matters.
   Related: How to show short DNS answers with dig

4. Query policy-specific owner names instead of assuming all TXT values live at the root domain.

   $ dig +noall +comments +answer _dmarc.google.com TXT
   ;; Got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR
   ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
   
   ;; ANSWER SECTION:
   _dmarc.google.com.	377	IN	TXT	"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"

   DMARC uses the _dmarc owner name. DKIM usually uses a selector below ._domainkey, such as selector1._domainkey.example.com.

5. Treat adjacent quoted strings on one TXT row as one record value.

   Long TXT data can be split into multiple quoted character strings inside one DNS record. For SPF and DKIM checks, join adjacent quoted pieces from the same row without adding spaces; separate answer rows remain separate TXT records.

6. Check the status when the name exists but has no TXT answer.

   $ dig +noall +comments +question +answer www.example.com TXT
   ;; Got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR
   ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
   
   ;; QUESTION SECTION:
   ;www.example.com.		IN	TXT

   NOERROR with ANSWER: 0 means the queried name exists from this resolver's view, but no TXT row matched the query.

7. Check for NXDOMAIN when a TXT owner name may be misspelled.

   $ dig +noall +comments +question +answer missing-txt.example.com TXT
   ;; Got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN
   ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
   
   ;; QUESTION SECTION:
   ;missing-txt.example.com.	IN	TXT

   NXDOMAIN means the queried name does not exist. Recheck the label, selector, or provider-supplied owner name before changing an existing TXT record.