Classify the DNS result before changing authentication
“DKIM record missing” can describe several different situations: the selector name does not exist, the name has no usable TXT record, an alias target is missing, or the resolver could not obtain an answer. Those conditions need different investigations. Treating every unsuccessful lookup as absence can send the ticket to the wrong operator and encourage unnecessary SPF or DMARC changes.
Begin with the exact identity being checked. For a DKIM signature, construct the query from its actual selector and signing domain. A lookup for last month's selector says little about a message signed with this month's selector. Save the full response, not only an empty output box. RFC 6376, sections 3.6.2 and 6.1.2.
The following decision sequence is a proposed diagnostic method. Its examples use fictional names and outcomes; it is not backed by original live query transcripts yet.
Branch one: did a usable DNS response arrive?
A timeout means the client did not receive a response within its waiting period. It is not a DNS response code and does not prove NXDOMAIN. Record the destination address, transport, timing and whether other approved endpoints respond. A refusal is also different from absence: REFUSED says that the server declined the operation. RFC 1035, section 4.1.1.
Check truncation and transport where the evidence points there. A UDP response with the TC flag set can require a TCP retry, and DNS implementations must support TCP. A published key can remain inaccessible through a path that breaks that exchange. Use a proposed comparison such as dig @SERVER_IP amber._domainkey.example.com. TXT +tcp, keeping the same owner and endpoint as the earlier query. No command in this article has been run. RFC 7766, sections 5–6.
Escalate a transport problem with the captured evidence to the network or DNS operator. Changing record content will not repair an unreachable service. Do not disable security controls as an unexplained troubleshooting shortcut.
Branch two: does NXDOMAIN identify the expected name?
NXDOMAIN is the name-error response. With no alias involved, it concerns the queried name. When a CNAME is present, the error can concern the final target rather than the original owner. Read the chain before announcing that the customer's selector was never published. RFC 2308, section 2.1.
In a fictional case, amber._domainkey.example.com exists as a CNAME to amber.keys.example.net, but the target is nonexistent. The customer-side publication and provider-side target have different responsibilities. The proposed next action is to confirm the issued target with its operator and query the appropriate authorities. Deleting the customer alias solely because the recursive answer says NXDOMAIN would discard useful configuration without resolving the actual missing name.
Also compare cache state. An authoritative positive answer alongside an older recursive NXDOMAIN can indicate cached absence. Preserve the negative response's SOA context and timestamp, and investigate disagreement among authorities before attributing everything to caching.
Branch three: does NOERROR really mean NODATA?
NOERROR reports no DNS error, but it does not guarantee that the requested TXT data is present. NODATA is determined from the response contents: no relevant answer, with authority context distinguishing it from a referral. An SOA in the authority section or the absence of referral NS records helps make that distinction; aliases may require further querying. RFC 2308, section 2.2.
A fictional amber._domainkey.example.com might have an A record but no TXT key. That is a different repair from an entirely absent name. Another response might contain NS records referring the client to a delegated child zone; stopping at that referral would mislabel an incomplete lookup as missing data. Keep the exact requested type visible throughout the decision.
When relevant TXT data exists, examine its protocol syntax and record boundaries separately. A DNS success does not guarantee a valid DKIM key or SPF policy. At the SPF record-lookup step, RFC 7208 distinguishes no matching policy from DNS errors such as timeout or server failure. Do not flatten those outcomes into a single authentication failure label. RFC 7208, sections 4.4–4.5.
Branch four: investigate SERVFAIL without assuming absence
SERVFAIL indicates that the server could not process the query successfully. Possible causes include unavailable authority, delegation or alias loops and DNSSEC validation failures. Its meaning is not “publish a new TXT record.” Preserve any extended error information, but do not infer a unique cause from SERVFAIL alone. RFC 9520, section 2.
Compare relevant authoritative servers and the affected recursive resolver. A positive direct-authority response can narrow the problem while leaving validation and reachability differences unresolved. RFC 9520 also requires failure caching, so an immediate repeated failure need not mean the resolver repeated every upstream query. RFC 9520, section 3.2.
Close the branch with evidence
The incident record should identify the message selector or other protocol identity, query owner/type/class, UTC time, server endpoint, flags, response code, complete sections and transport. Attach the original output to the proposed branch decision. State the next responsible operator and the observation that would disprove the current explanation.
After correction, repeat the relevant DNS comparison and test a controlled message through the affected route. Report DNS availability, authentication verification and delivery as separate observations. Original query transcripts, independent technical review and release approval remain open for this documentary candidate; the fictional decision examples cannot substitute for them.