Turn a lookup into a precise question
Use dig to ask a named DNS server about an exact owner and record type, then retain enough context to interpret the reply. For email authentication, the central question is rarely whether a domain has any TXT records. It is whether the dependency used by the sender or verifier exists at the correct name and can be resolved through the relevant path.
Examples in this guide target the documented syntax of ISC BIND 9.20.13 dig. That is a pinned documentation scope, not a claim that every installed dig has that version or that it is the newest release. All commands are proposed read-only DNS queries or a local version check. None has been executed here. The example.com names and 192.0.2.0/24 addresses are documentation placeholders, not a working resolver setup.
Start with the identity that email actually uses
For SPF, identify the domain used in the relevant SMTP identity rather than automatically using the visible From domain. For DKIM, take the signing domain and selector from the message's signature. The key lookup owner combines the selector, _domainkey and signing domain. Do not guess a selector from a vendor's name. RFC 7208 RFC 6376
A lookup of _dmarc.example.com. can inspect a policy record at that owner. It is not by itself a complete implementation of policy discovery or an alignment evaluation. Preserve the message identity and applicable policy-discovery context when handing results to a mail specialist. DNS visibility and authentication outcome belong in related but separate evidence fields. RFC 9989
Write a question sheet with owner, type, reason for the query and expected authority. This small preparation prevents an attractive-looking answer for the wrong domain from being accepted as a fix. A trailing period makes the examples' names explicit absolute DNS names.
Make the initial query reproducible
The proposed local command dig -v records the tool version. For a controlled query shape, use dig -r @192.0.2.53 _dmarc.example.com. TXT. The -r option avoids per-user dig defaults, while the server argument identifies the DNS server. Replace both placeholders only for a separately authorized lookup. Retain the complete output before making a compact extract. ISC dig manual
Record UTC time, source network context and the server actually reported in the result. Avoid beginning with a command that hides everything except answers. A short answer-only view may be convenient later, but the initial evidence should preserve the question, status, flags, answer and authority sections, plus transport-related messages. Those details distinguish absence, a referral and failure.
Suggested companion questions are dig -r @192.0.2.53 example.com. TXT and dig -r @192.0.2.53 selector1._domainkey.example.com. TXT. These are syntax examples, not a claim that either name has an authentication record. Select the actual names from the approved investigation, and never treat an ANY query as a guaranteed inventory of everything in a zone.
Compare recursive and authoritative observations
First establish which server you queried. A recursive resolver can return cached data; an authoritative server answers for zones it serves. To compare with a separately verified authority, the proposed form is dig -r @192.0.2.54 _dmarc.example.com. TXT +norecurse. Disabling recursion does not make an arbitrary server authoritative. Check the response and the delegation evidence rather than trusting the chosen IP address alone. RFC 1034
If the recursive and authoritative results disagree, keep both. Compare names, types, values, response status and timestamps before blaming propagation. A decreasing cached TTL is informative but is not a universal expiry deadline for every observer. A negative cache entry also follows its own rules. RFC 2308
Read the answer structurally. Several quoted character strings can belong to one TXT resource record; several TXT resource records are a different condition. Do not flatten both forms into one space-separated string. Preserve record boundaries before the mail specialist evaluates SPF or DKIM syntax. A CNAME introduces another name to investigate rather than proving that the final key or policy text is available. RFC 1035
Trace delegation only when that is the question
The proposed query dig -r +trace example.com. NS follows referrals from the root. It sends multiple network queries, so approve the diagnostic scope accordingly. Adding a server argument does not keep the whole trace confined to that resolver. A trace investigates delegation from the operator's network; it does not reproduce every decision made by a remote email receiver. ISC dig manual
When reviewing a trace, identify the last successful referral, the contacted servers and where resolution stopped. A timeout at one stage is not permission to edit nameservers. Compare the finding with the registrar and DNS owner's inventory, then assign the next investigation to the appropriate owner. Avoid turning one incomplete trace into a migration recommendation.
Keep failure and validation claims narrow
NXDOMAIN, a successful response without the requested data, and SERVFAIL need different next steps. Do not translate all three into missing authentication records. If transport is suspected, a proposed +tcp comparison can help separate paths, but success over one transport does not prove that every receiver can resolve the record. RFC 1035 RFC 7766
The dig +dnssec option requests DNSSEC material; its presence is not a standalone cryptographic validation result. Keep validation conclusions tied to appropriate resolver behavior and trusted evidence. Finish the investigation with a concise statement of which server answered which question, when, and what remains uncertain. The timestamped authoritative and recursive transcripts required for this article are still missing; these proposed commands are not substitutes for them.