No DMARC Record Found: Trace the Authoritative DNS Failure
Summarize with AI
"No DMARC record found" describes the outcome of a DNS query, not the state of your configuration. A resolver asked a question and received nothing usable back. Six different conditions produce that same result, and publishing a fresh record fixes only one of them. Publish before tracing and you can end up with two records, a record in the wrong zone, or a correct record that resolvers still refuse to see.
The query that produced the result
RFC 7489 specifies that DMARC preferences are "stored as DNS TXT records in subdomains named _dmarc". Checking example.com means a TXT query for _dmarc.example.com. Nothing else counts as the record, which sounds obvious until you watch someone publish a TXT record on the bare domain and wonder why no tool can see it.
There is a second query in the specification worth knowing before you diagnose. Section 6.6.3 tells receivers that when the first lookup yields nothing, they "MUST query the DNS for a DMARC TXT record at the DNS domain matching the Organizational Domain in place of the RFC5322.From domain in the message (if different)".
That fallback means a subdomain with no record of its own is not necessarily unprotected. It also means a checker reporting "found" against your sending subdomain may be reporting the parent's record. Establish which name actually answered before you act on either result.
Six causes, one symptom
Work down this list in order. Each step costs a single query and eliminates a distinct cause.
| Cause | How to confirm it | The actual fix |
|---|---|---|
| Wrong label | Query `_dmarc.domain` explicitly and compare with what your zone contains | Move the record to the `_dmarc` name |
| Delegated subzone | Check for NS records at or above the name you are querying | Publish in the zone that is authoritative for that name |
| Unpublished change | Query the authoritative nameservers directly | Publish or activate the pending zone change |
| Split-horizon DNS | Compare an internal resolver with an external one | Publish the record in the externally visible view |
| Cached negative | Check the TTL and the age of the change | Wait out the TTL rather than republishing |
| True absence | All of the above cleared and the zone has no record | Publish a record, starting at `p=none` with a working `rua` |
Only the last row calls for creating a record. The other five call for finding out where the record you already have is sitting, or waiting.
Query the authoritative servers, not a resolver
This step eliminates the two causes you cannot see from a public checker, cached negatives and partial zone transfers, and it rests on how DNS caching works.
RFC 1034 describes the TTL as "a time limit on how long an RR can be kept in a cache", and notes that "this limit does not apply to authoritative data in zones". Resolvers cache what they receive and serve it until the limit expires. A record you published ten minutes ago is invisible through a resolver that cached a negative answer an hour ago, and the record has nothing wrong with it.
The consequence for troubleshooting is direct. An online DMARC checker queries through recursive infrastructure you do not control, with caching you cannot see. The authoritative nameservers for the zone hold the current answer. Ask them.
Find the nameservers for the zone, then query _dmarc.yourdomain.com for TXT records against each one in turn. If every authoritative server returns the record and a public checker does not, you have a caching or propagation question and the answer is time. If the authoritative servers return nothing, the record is not published where you think it is.
Delegation puts the record in a different zone
The cause that produces the most confident wrong diagnosis is delegation, because the record genuinely exists and the person who published it genuinely has access to a DNS console.
RFC 1034 describes zones as separated by cuts: "After all cuts are made, each group of connected name space is a separate zone. The zone is said to be authoritative for all names in the connected region." Those cuts are marked by NS records, and the spec adds that these NS records "are NOT part of the authoritative data of the zone".
In operational terms, if mail.example.com is delegated to a different set of nameservers, then a record for _dmarc.mail.example.com published in the example.com zone will not be served. The parent zone is no longer authoritative for that branch. Resolvers follow the delegation and ask the child, which knows nothing about your record.
Outbound teams meet this whenever a sending platform or a subsidiary's IT function holds delegated control of a subdomain. Check for NS records at the subdomain before assuming your DNS console is the right place to publish.
Split-horizon and the view that matters
Some organisations serve different answers to internal and external queries. A record published in the internal view resolves correctly from a laptop on the corporate network and does not exist as far as any mailbox provider is concerned.
Test from outside your network. A query run from an office machine, a VPN session, or a jump host inside the perimeter can all be answered by infrastructure that receiving mail servers will never reach. The only view that decides DMARC outcomes is the public one.
Publishing a second record makes things worse
When the first four checks are inconclusive, the tempting move is to publish another record and see whether the checker turns green. Resist it.
RFC 7489 requires that "the v and p tags MUST be present and MUST appear in that order", that the version tag "MUST be the first tag in the list", and that if it is not, "the entire retrieved record MUST be ignored". Multiple TXT records at _dmarc leave receivers with an ambiguity the specification does not ask them to resolve in your favour.
You also lose the diagnosis. Once two records exist, you can no longer tell which condition was causing the original result, and the next person to audit the zone inherits a defect with no history.
LeadHaste practice: we treat a DNS change during an active campaign as a change-controlled event, recording the zone, the exact name, the previous value and the TTL before editing. Lowering the TTL a day ahead of a planned change is how we keep rollback measured in minutes. That is our operating method rather than anything the specifications require.
Once you have confirmed genuine absence
Only after the five other causes are cleared does publishing become the right action. Start at monitoring rather than enforcement, and make sure the aggregate report address is a mailbox somebody owns and reads.
A record published at p=none with a working rua destination begins producing the evidence you need for every later decision. A record published at enforcement without that evidence is a guess about which of your business systems are aligned, and the systems that find out first are usually invoicing and recruiting.
The enforcement decision is a separate piece of work with its own prerequisites. Our DMARC policy audit guide covers what to gather before raising the tag, and how to read a DMARC report covers turning the incoming reports into a sender inventory.
Ready to get your sending domains verified before the next campaign?
We can trace your authentication records and sending domain structure as part of an ICP and campaign-fit discovery call. Book your free discovery call →
Frequently Asked Questions
A strong positive reply rate for B2B cold email is 1.5–3%. Top-performing campaigns with tight targeting and personalized copy can hit 4–5%. If you're below 1%, it usually signals a deliverability or messaging problem, not a volume problem.
The safe range is 30–50 emails per inbox per day for warmed inboxes. That's why outbound systems use multiple inboxes (we use 80) to reach 40,000+ monthly sends while keeping each inbox well within safe limits. Sending more than 50/day from a single inbox risks spam folder placement.
Yes. The CAN-SPAM Act permits unsolicited commercial email as long as you include a physical address, an unsubscribe mechanism, accurate headers, and non-deceptive subject lines. Unlike GDPR in Europe, the US does not require prior opt-in consent for B2B cold outreach.
Domain warm-up typically takes 2–3 weeks. During this period, sending volume gradually increases while the email warm-up tool generates positive engagement signals (opens, replies) to build sender reputation. Skipping or rushing warm-up is the most common cause of deliverability problems.
Cold email is targeted, relevant outreach to a specific person based on their role, industry, or company, with a clear business reason. Spam is untargeted mass messaging with no personalization or relevance. The distinction matters legally (CAN-SPAM compliance) and practically (deliverability depends on relevance signals).
Dimitar Petkov
Co-Founder of LeadHaste. Builds outbound systems that compound. 4x founder, Smartlead Certified Partner, Clay Solutions Partner.