A “no DMARC record found” warning is a starting point for diagnosis. It can reflect a genuinely missing policy, a query for the wrong name, an edit in an inactive DNS account, an older cached answer or a resolution failure.
Before publishing another record, establish what the tool queried and which authoritative servers control that answer. Preserve the DNS response code as well as any returned TXT data. This separates an absent record from a record that exists but cannot be retrieved through a particular lookup path.
Capture the exact failed lookup
Record the tool, queried domain, timestamp, resolver and full DNS response where available. Save the current policy record and DNS configuration before editing.
These illustrative BIND dig commands are not executed here. Replace documentation names with the approved target and actual delegated server. The BIND dig manual defines the server, name, type and query options. The authority section helps retain negative-answer context; comments retain header status and flags. A simple query for the visible From domain example.com starts here:
dig _dmarc.example.com. TXT +noall +answer +authority +commentsKeep the response status as well as the answer section. A short-only display can hide the distinction between a name with no relevant TXT data and a resolution error.
Identify who controls the public DNS answer
This problem often becomes an ownership problem. A company may have bought the domain from one provider, moved its website elsewhere and delegated DNS to a third account. A record added in the wrong panel can look complete while having no effect on public email checks.
Ask the operator to identify the current authoritative DNS host and show its answer for the intended name. Avoid paying for repeated fixes without a demonstrated publishing path. Also ask whether the warning concerns your main domain, a sending subdomain or a different identity used by an application.
Check the name and publishing account
Check the authoritative delegation for the zone, including a separately delegated child zone if one exists. Query a relevant authoritative server directly, using its actual name:
dig @ns1.example.net _dmarc.example.com. TXT +norecurse +noall +answer +authority +commentsIf the DNS editor automatically appends the zone, entering _dmarc.example.com may accidentally publish _dmarc.example.com.example.com. In another editor, entering only _dmarc may be wrong. Check the final published owner name rather than prescribing the same input format for every provider.
Other frequent mistakes include a TXT record at the domain root, an edit to an inactive DNS account, an unsaved change or a lookup for the wrong sending domain.
Distinguish absence from lookup failure
- Observation: NXDOMAIN; What to investigate: The queried name is reported as non-existent
- Observation: NOERROR with no relevant TXT data; What to investigate: The queried name has no applicable TXT answer in that response
- Observation: SERVFAIL; What to investigate: Resolution failed; inspect authority, delegation, validation and dependencies
- Observation: Authoritative answer exists but recursive answer differs; What to investigate: Cache state, resolver view, delegation path and timing
- Observation: Several candidate policy records; What to investigate: A record-set problem, not a simple missing-record condition
The DNS statuses and negative-answer distinction are described in RFC 1035 §4.1.1, RFC 2308 §2.1 and RFC 2308 §2.2. Do not treat SERVFAIL as permission to publish another record. The record may exist but be unavailable through the failing resolution path. Likewise, a missing record at a child name does not settle whether a receiver can discover an applicable policy elsewhere under RFC 9989 §4.10.1.
Worked example: the record is in an inactive zone
Consider this illustrative investigation. An administrator adds _dmarc to the registrar's DNS panel. Public delegation, however, points to a separate DNS host used during a previous website migration.
The registrar's panel shows the intended value. A direct query to the currently delegated authority does not return it. Waiting longer cannot make an inactive zone authoritative.
The correction is to publish through the actual authority, with the appropriate approval. Afterwards, retain the authoritative answer and compare the recursive observation. Changing name servers just to make the earlier panel effective could disrupt unrelated web and mail records, so that is a separate, much broader change.
Compare authoritative and cached answers
Under RFC 2308 §5, a resolver can cache an earlier negative answer. A new authoritative record can therefore coexist temporarily with a recursive missing-answer observation. Flushing a laptop's cache does not clear an external receiver's resolver state.
Compare the authority and relevant recursive observations with timestamps. If authoritative servers disagree, investigate their published state. If internal and public DNS differ, establish which view the external mail receiver uses.
Avoid promising that all answers will converge after one fixed number of minutes. Diagnose the actual path and cache evidence.
Correct the publishing process
Treat the finding as a control-ownership issue when it reveals unclear DNS responsibility, abandoned accounts or unmanaged delegation. Record who can make changes, which zone is active and how a second reviewer verifies the result.
A missing-policy observation is a configuration finding. It does not establish that a phishing campaign succeeded, that every subdomain lacks a policy or that every received message fails DMARC. Keep those conclusions separate and gather the evidence each requires.
Verify the policy and a real message
After the intended correction, confirm the applicable policy lookup and test a real legitimate message through the relevant service. Verify its trusted authentication result and alignment.
Use the record creation workflow when a new policy is actually required. If the policy is visible but the mail fails, move to alignment diagnosis. If an old guide and a new receiver differ on discovery, include DMARCbis readiness in the investigation.
The practical takeaway
Close the finding with the corrected publishing path and the resulting authoritative answer. Then verify the applicable policy and a real legitimate message. This leaves a reproducible diagnosis instead of an unexplained checker result.
Keep the decision and evidence separate
For the inactive-zone fixture, choose the active authority as the proposed publication target; do not change delegation merely to make an obsolete panel relevant. Inspect the authoritative-answer flag and full response context, not only returned text. RFC 8767 §4 permits qualifying stale-answer use beyond TTL expiry, so a TTL is not a universal convergence deadline. No lookup or configuration change was executed.