You set up a DMARC record, saw p=none, and then never touched it again. That is the most common state we find when we audit sending domains - a policy that reports but does not protect. This guide walks you from p=none to p=reject in a controlled way, so you tighten security without waking up to a queue of legitimate mail bouncing.
What is a DMARC policy and why does p=none not protect you?
A DMARC policy tells receiving servers what to do when an email fails authentication - do nothing (none), quarantine it, or reject it. At p=none you get reports but zero enforcement, so spoofed mail using your domain still lands.
DMARC sits on top of SPF and DKIM. Those two verify that a message is actually authorized to send from your domain. DMARC adds two things: alignment (the visible From domain has to match the authenticated domain) and a published instruction for failures. If you have not nailed the SPF and DKIM layer first, read our breakdown of SPF, DKIM and DMARC for cold email before you touch the policy tag.
The none value exists for one reason: to let you watch traffic safely before you enforce. It is a starting line, not a destination. Leaving it there is like installing a smoke detector and never connecting the battery.
A dmarc policy of
p=noneis a diagnostic tool, not a security control - if you never advance it, you are just collecting reports for spoofers.
How do I read DMARC reports before tightening the policy?
Turn on aggregate reporting with a rua address, then wait one to two weeks and read who is actually sending as your domain. You cannot safely enforce a policy until you know every legitimate source.
Add a rua tag to your record so mailbox providers send you daily XML summaries:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com;Those raw XML files are unreadable by hand. Pipe them into any DMARC report parser. What you are hunting for:
- Every IP and service sending "as" your domain (your ESP, CRM, invoicing tool, support desk, cold email infrastructure)
- Which of those sources pass SPF alignment
- Which pass DKIM alignment
- Anything unfamiliar - that is either a forgotten tool or an actual spoofer
The goal of this phase is a clean inventory. If a legitimate service is failing alignment at p=none, it will keep failing when you move to reject - except then its mail disappears. Fix alignment first, enforce second. This is the same discipline we apply across our cold email deliverability checklist: measure, fix, then change one variable at a time.
What is the safe order to move from p=none to p=reject?
Move in three deliberate steps: p=none to p=quarantine with a low percentage, then quarantine at 100%, then p=reject. Never jump straight from none to reject on a domain with real mail flowing through it.
The pct tag is your safety valve. It tells receivers to apply the policy to only a fraction of failing mail, so a misconfiguration hits a small sample instead of your whole volume. Here is the progression:
- Establish
p=nonewith reporting - collect two weeks of aggregate data and inventory every sending source. - Fix alignment on every legitimate source - make sure your ESP, transactional mail, and outbound tooling all pass SPF or DKIM alignment.
- Move to
p=quarantine; pct=25- a quarter of failing mail goes to spam. Watch reports for a week. - Raise to
p=quarantine; pct=100- all failing mail is quarantined. Confirm no legitimate source is caught. - Advance to
p=reject; pct=100- failing mail is now blocked outright.
At each step, the question is the same: is any legitimate source in the "fail" column? If yes, stop and fix it. If no, advance. Rushing this is exactly how teams break their own email - the same reason we never rush warmup. Speed here buys you nothing and risks everything.
How long should each DMARC stage take?
Give each stage at least seven days of clean reports before advancing. Real-world sending has weekly rhythms - a Monday invoice run or a Friday newsletter may surface a source you missed on a quiet Wednesday.
There is no bonus for finishing the progression in a weekend. A realistic timeline for a domain with several sending services is three to six weeks end to end. That includes your initial observation window, alignment fixes, and a stable stretch at each enforcement level.
Two things extend the timeline in a good way:
- Low-frequency senders. A tool that only fires quarterly (renewal reminders, annual reports) will not show up in a two-week window. If you know one exists, wait for it or authorize it proactively.
- Third-party forwarding. Forwarded mail can break SPF alignment. DKIM usually survives forwarding, which is why DKIM alignment matters more than SPF for a clean
rejectpolicy.
If your outbound sending runs on separate infrastructure - which it should - your cold email domains and your corporate domain progress on independent tracks. We cover why that separation matters in subdomain vs root domain sending and in the lookalike sending domains guide.
Does DMARC policy affect cold email deliverability?
Yes - directly. A properly aligned, enforced DMARC policy is now a baseline requirement for bulk senders to Gmail and Yahoo, and a missing or misconfigured policy is a fast track to the spam folder.
Google and Yahoo's bulk sender rules require SPF, DKIM, and a published DMARC policy for anyone sending meaningful volume. You do not need p=reject to satisfy the baseline - p=none technically qualifies - but the trend is unmistakable: mailbox providers reward domains that authenticate cleanly and enforce their own policy. See our full rundown of the Google and Yahoo bulk sender rules for the specifics.
For cold email specifically, DMARC is part of the trust signal stack that keeps you out of spam. It will not fix bad copy or a garbage list - that is a different problem, and one we tackle in why cold emails go to spam. But an unauthenticated or spoofable domain undercuts every other deliverability effort you make. On our own campaigns we hold 98.7% inbox placement with a bounce rate around 0.8%, and clean authentication is one of the non-negotiable inputs to those numbers.
The other input is discipline on volume and hygiene: a per-mailbox cap of about 25 emails a day, verified lists, and a maintained suppression list. DMARC protects the domain; those habits protect the reputation.
What breaks when you rush to p=reject?
The classic failure is a legitimate service you forgot about - a helpdesk, a marketing platform, an accounting tool - that never aligned, and now every message it sends gets rejected. Customers stop getting receipts. Prospects stop getting replies. And you find out from an angry Slack message, not a report.
The second common break is a subdomain policy gap. DMARC applies to subdomains via the sp tag. If you enforce p=reject on the root but leave sp undefined, subdomains inherit the root policy - which can catch a subdomain-based service you did not test. Set sp explicitly so you know exactly what applies where.
The third is forwarding, mentioned above. If a big chunk of your recipients forward mail through systems that break SPF and you have weak DKIM alignment, reject can bounce legitimately-forwarded messages. This is why the report-reading phase is not optional - it surfaces these edge cases before enforcement does.
If your domain reputation is already damaged from a previous mistake, tightening DMARC is part of the cleanup but not a substitute for it. Our domain reputation recovery guide covers the rest of the checklist, and if you are seeing hard bounces, start with the email bounce rate fix.
Who should own DMARC progression - and should you outsource it?
If you run outbound at any real volume, someone needs to own DMARC as an ongoing task, not a one-time setup. Reports need reading, new sending tools need authorizing, and the policy needs to actually advance. If nobody owns it, it stays stuck at p=none forever.
That is exactly the gap Moongie fills for outbound. We run managed cold email infrastructure end to end - authentication, warmup over three to four weeks, and daily deliverability monitoring - never a build-it-and-hand-it-over arrangement. Your domains are set up correctly and maintained correctly, sized to your goals rather than a rigid template. If you are weighing that against doing it internally, the cold email tools vs service comparison lays out the tradeoffs honestly.
DMARC done right is quiet infrastructure. You stop thinking about it, spoofers stop using your domain, and your legitimate mail keeps landing. That is the whole point.
Want your authentication and outbound handled by people who monitor deliverability every day, not once a quarter? Talk to us - we will audit your current DMARC policy and map the safe path to p=reject.
Want this handled for you? Moongie runs managed cold email infrastructure, mixed email + LinkedIn outreach and high-converting landing pages. Book a free 30-minute strategy call - or win our playbook in the Inbox Run game.