DMARC Policy Not Enabled: Diagnose Before Editing DNS
Summarize with AI
A "DMARC policy not enabled" warning is a finding about your enforcement state, not a missing record. The checker resolved something at _dmarc.yourdomain.com and read a policy that asks receivers to take no action. The fix is not to raise the policy tag today. It is to establish which senders currently pass alignment, then raise the tag once the evidence says legitimate mail will survive it.
What the warning actually reports
RFC 7489 stores Domain Owner preferences "as DNS TXT records in subdomains named _dmarc". A receiver checking example.com queries _dmarc.example.com. The spec defines three values for the policy tag. Setting it to none means "the Domain Owner requests no specific action be taken regarding delivery of messages", and the spec adds that "discovered policies of p=none SHOULD NOT modify existing mail disposition processing".
A scanner reporting this cannot tell whether monitoring is a deliberate stage in a rollout or a record someone published two years ago and forgot. It reads the tag and reports the tag.
The distinction matters because the remedy differs. A domain three weeks into a planned rollout needs to finish reading reports. A domain that has been sitting at p=none since 2023 needs someone to own the enforcement decision. Both produce identical scanner output.
Five states that produce the same warning
Before editing anything, work out which of these you are in. The record text tells you most of it.
| State | What you will see in the record | What it means |
|---|---|---|
| Deliberate monitoring | `p=none` with a working `rua` address | Rollout stage, reports are being collected |
| Orphaned monitoring | `p=none` with no `rua`, or an `rua` nobody reads | No evidence is being gathered at all |
| Partial application | `p=quarantine` with `pct=10` or similar | Policy set, but applied to a sample |
| Inherited policy | No record on the subdomain you tested | The organizational domain answered instead |
| Malformed record | Tags out of order, or `v=` not first | The record may be ignored entirely |
The orphaned case is worth checking first because it is invisible from the record alone. A record published to satisfy a vendor questionnaire, with an rua pointing at a mailbox that was later deprovisioned, looks identical to a healthy monitoring stage. Raising the policy from that position is a guess dressed as a fix.
LeadHaste practice: before we touch a client's policy tag we confirm the rua destination accepts mail and that someone has read a report from the last fourteen days. This is our own gate, not a requirement written into the spec.
Check the record you think you are checking
Two spec behaviours cause people to audit the wrong record.
The first is organizational domain fallback. RFC 7489 Section 6.6.3 instructs receivers that if no record is found, 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)". Query _dmarc.mail.example.com, get nothing, and the receiver falls back to _dmarc.example.com. Your cold-sending subdomain may have no policy of its own while a scanner reports the parent's.
The second is the subdomain policy tag. The sp tag "applies only to subdomains of the domain queried and not to the domain itself", and if absent, "the policy specified by the p tag MUST be applied for subdomains". So a parent at p=reject with no sp tag silently puts every subdomain at reject too. The spec also warns that sp "will be ignored for DMARC records published on subdomains of Organizational Domains".
For outbound teams running dedicated sending subdomains, that pairing decides whether a parent-domain change can move your live campaign infrastructure to enforcement without anyone editing the subdomain. Check the parent record before assuming your sending subdomain is unprotected, and check it again before assuming it is safe.
Read the tags for quiet failures
RFC 7489 requires that "the v and p tags MUST be present and MUST appear in that order". The version tag "MUST be the first tag in the list" and "MUST have the value of DMARC1". If it does not, "the entire retrieved record MUST be ignored".
A record ignored for a syntax reason behaves like no record at all. Some checkers report that as "not enabled" rather than "invalid", which sends people to edit the policy tag on a record that was never being read.
The percentage tag is the other quiet one. The spec defines pct as the "Percentage of messages from the Domain Owner's mail stream to which the DMARC policy is to be applied", defaulting to 100. A record reading p=quarantine; pct=5 is enforcing against a twentieth of your mail. Treating that as full enforcement overstates your protection by a wide margin.
Google's Workspace DMARC guidance recommends starting at p=none and, when moving to enforcement, to "start with a small percentage of your messages" and raise it as authentication improves. That is a rollout instruction. It becomes a problem only when the percentage never moves.
Build the evidence before raising the tag
Enforcement is safe when you can name every system that sends as your domain and show it aligning. Identifier alignment is the thing being tested. RFC 7489 states that a message passes "if at least one of the supported authentication mechanisms: (1) produces a pass result, and (2) produces that result based on an identifier that is in alignment".
Alignment, not authentication, is the part that surprises people. A message can carry a valid DKIM signature from your ESP's own domain and still fail DMARC, because the signing domain does not match the visible From domain. Relaxed mode requires that the organizational domains match. Strict mode demands an exact match of the fully qualified names.
Work through your aggregate reports and produce a sender inventory: the sending source, the volume, whether SPF aligns, whether DKIM aligns, and who owns the configuration. Places worth checking include billing systems, applicant tracking, helpdesk software, marketing platforms and calendar invitations. Check who administers each one before assuming the outbound team can change its configuration.
Anything in that inventory that you cannot identify is the reason to keep reading reports rather than the reason to enforce. Unknown volume at enforcement becomes either a spoofing source you just blocked correctly or a business system you just broke.
Raise the policy in stages you can reverse
Move when the inventory is complete and the unaligned volume is either fixed or understood. Google's documentation asks administrators to allow 48 hours after setting up SPF or DKIM before configuring DMARC, and to begin with a permissive policy.
A staged sequence that stays reversible: confirm alignment coverage at p=none, move to p=quarantine with a low pct, raise the percentage while watching reports for legitimate mail landing in the quarantine bucket, then move to p=reject once a full percentage at quarantine produces no surprises. Add an explicit sp tag at each step rather than letting subdomains inherit by accident.
Keep the previous record text and the date of every change. When a finance team reports that invoices stopped arriving, the rollback needs to take minutes.
LeadHaste practice: for clients running cold outbound on dedicated subdomains, we set the subdomain policy explicitly instead of relying on inheritance, so a later change to the parent record cannot silently move the sending domain to enforcement mid-campaign. That is how we prefer to operate it, not a spec requirement.
When to leave the warning in place
Sometimes the correct answer is to accept the finding for now. If your aggregate reporting has a gap, if a major sending system is mid-migration, or if nobody owns the DNS zone with enough access to roll back quickly, enforcing against that is how outbound teams lose a week of sends.
Record the decision, name the owner, and set the date you will revisit it. A scanner warning you have chosen to carry with a documented reason is a different thing from one nobody has looked at. Our SPF, DKIM and DMARC guide for cold email covers the underlying record setup, and how to fix DMARC reject covers the incident on the other side of this decision.
Ready to check your authentication before your next campaign?
We can review your sending domains, alignment coverage and enforcement plan 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).
Jacob Martinez
GTM Engineer, LeadHaste
Builds the machinery behind client campaigns: scraping, enrichment, lead scoring and the automations that keep a list clean before anyone gets emailed.