Thinking a Short DMARC p=none Phase Is Enough Before Switching to p=reject

A common plan goes like this: publish p=none, wait a week or two, see that nobody complains, then switch to p=reject. The logic feels sound because nothing broke during monitoring. The problem is that nothing could break during monitoring. At p=none, receivers deliver failing mail anyway, so silence tells you almost nothing about what will happen once enforcement starts. The real signal sits in the DMARC aggregate reports, and many domain owners either never set up a place to receive them or never open them. Then the switch to reject happens, and the first evidence of a missed sender is a 550 bounce on an invoice run, a ticketing reply, or a password reset.

Why a quiet p=none phase proves very little

DMARC (Domain-based Message Authentication, Reporting and Conformance) asks receivers one question per message: did SPF or DKIM pass for a domain that aligns with the visible From address? With p=none, the answer only goes into a report. The message itself is handled as if no policy existed. So during monitoring, a misconfigured CRM or HR platform sending as your domain keeps landing in inboxes. No user notices. No support ticket appears. The only place that failure shows up is in the aggregate data, if you collect it. There is a second gap: time coverage. A short window only captures mail that happened to be sent during that window. Plenty of legitimate traffic is periodic. Monthly invoices, quarterly statements, payroll notices, annual renewal reminders, and alerts that only fire when something goes wrong may simply not appear in a two-week sample. Those streams look fine because they are absent, not because they are aligned. This is why industry guidance usually frames the monitoring phase as at least 2 to 4 weeks, and longer for larger organizations with many departments and vendors. Treat that as a minimum, not a target. The better rule of thumb is to cover at least one full business cycle, including a month-end.

What an aggregate report actually tells you

Aggregate reports are XML files that receivers send to the address in your rua tag. Each one summarizes the mail they saw claiming to be from your domain, grouped by sending IP and authentication result. To get them at all, your record needs a reporting address:

TEXT

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

If the reporting mailbox is on a different domain than the one being reported on, the receiving domain has to publish an authorization record, otherwise many receivers will not send reports there. Hosted report processors usually document what they need. Inside a report, each record block is one group of messages. This is the part people misread most often:

XML

<!-- Illustrative output format -->
<record>
  <row>
    <source_ip>203.0.113.25</source_ip>
    <count>40</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>vendor-mail.example.net</domain>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounces.vendor-mail.example.net</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Look at the two halves. Under auth_results, both DKIM and SPF passed. Under policy_evaluated, both failed. That is not a contradiction. The raw checks passed for the vendor's own domains, but neither domain aligns with example.com in the From header. DMARC only counts a pass when the authenticated domain matches the From domain (exactly in strict mode, or at the organizational level in relaxed mode, which is the default). This exact pattern is the classic third-party sender. Its own dashboard says "authenticated", its test emails arrive fine, and at p=none everything is delivered. At p=reject, those 40 messages bounce. The disposition field shows what the receiver did, and under monitoring it will say none regardless of the result, which is why you read the policy_evaluated results, not the disposition.

Reading the reports yourself

You do not need a paid dashboard to start. Reports usually arrive as .xml.gz or .zip attachments. Save a few and pull out the fields that matter:

BASH

# Confirm the published DMARC record and the rua address
dig +short TXT _dmarc.example.com

# Extract the useful fields from a gzip report
zcat report.xml.gz | grep -E '<(source_ip|count|header_from|disposition|dkim|spf|domain|result)>'

# Same for a zip report
unzip -p report.zip | grep -E '<(source_ip|count|header_from|disposition|dkim|spf|domain|result)>'

This gets noisy fast once volume grows, and at that point a report parser saves real time. But reading a handful of raw files first is worth it, because it teaches you what the dashboards are summarizing. For each source IP that shows failures, find out who owns it. A reverse DNS lookup on the IP and the DKIM domain value usually point to the platform. From the support desk, this step is where most confusion comes from: a customer sees an unfamiliar IP and assumes spoofing, when it is actually the newsletter tool the marketing team signed up for and never mentioned.

Building a sender inventory from the data

The goal of the monitoring phase is a list where every source sending as your domain sits in one of a few buckets. Something like this:

Source type	What it looks like in reports	Action before enforcing
Your main mail platform	Aligned DKIM and SPF pass	None, keep monitoring
Third-party SaaS (CRM, ticketing, marketing, HR)	Raw pass on the vendor's domain, DMARC fail	Set up custom DKIM signing with your domain, or a custom return-path for SPF alignment
Your own web or app servers	SPF or DKIM fail, often from a hosting IP	Route through an authenticated relay or add DKIM signing
Forwarders and mailing lists	SPF fail, DKIM sometimes broken by modified content	Usually accept some loss; aligned DKIM survives plain forwarding better than SPF
Unknown IPs with no relationship to you	Fail on everything	This is the spoofing enforcement is meant to stop

The research guidance specifically warns against auditing only the corporate mailbox provider and forgetting SaaS platforms, marketing tools, CRM systems, ticketing software, and HR systems. Those are exactly the senders that end up in the second row. Ask each department what sends mail on their behalf, and then confirm against the reports rather than trusting the answer. A practical point: aim for aligned DKIM on every legitimate source, not only SPF. SPF breaks on forwarding because the forwarding server's IP is not in your record. DKIM signatures usually survive plain forwarding, so a source with aligned DKIM keeps passing in more situations. For a fuller pre-enforcement checklist, see What to Audit Before Switching DMARC Policy from None to Reject.

Using quarantine as a rehearsal, then reject

p=quarantine tells receivers to treat failing mail as suspicious, which typically means the spam folder. That makes it a safer test than going straight to reject. A missed sender now shows up as "our emails are going to junk", which is recoverable, instead of a hard bounce where the message is gone. Common guidance is to stay at quarantine for at least two weeks. During that time, keep reading reports and watch for complaints that match the pattern: one specific type of email landing in spam while normal mail is fine. That usually means one stream is unaligned. Some teams ramp quarantine gradually with the pct tag, applying the policy to only a share of failing mail. It can help, but it also produces confusing mixed results where the same email sometimes reaches the inbox and sometimes does not, and receivers do not all handle sampling the same way. Why Only Some Password Resets Went to Spam After Setting DMARC pct=25 covers what that looks like in practice. The move to p=reject makes sense when the reports show every legitimate source aligned. A reasonable set of exit criteria:

No legitimate source has appeared with DMARC failures for the full quarantine period.
The reporting window included at least one month-end and any known periodic sends.
Every failing source left in the reports is either unknown spoofing or forwarding you have decided to accept.
There is a process so new vendors get DKIM and alignment set up before they start sending, not after.

That last one matters more than it looks. Enforcement is not a finish line. Once you are at reject, a new tool that starts sending as your domain without alignment will bounce from day one. Keep the rua address in place and keep reading the reports after enforcement too. If you take one thing from this: a quiet p=none phase is not evidence. Evidence is a set of aggregate reports, read by someone, covering a full business cycle, where every source you recognize passes in policy_evaluated and not just in auth_results. Get there first, rehearse with quarantine, and the switch to reject becomes a small, boring change instead of a bounce storm.