From p=none to p=reject: The Safe 8-Week Migration Plan

The danger in DMARC enforcement is entirely self-inflicted: p=reject applies to any mail from your domain that fails authentication, and the mail most likely to fail isn't attackers: it's your own forgotten senders. The invoicing tool set up three years ago, the CRM (customer relationship management system) the sales team added, the helpdesk, the scan-to-email copier. Enforce before they're fixed and their mail bounces.

The mistake in the other direction is more common, though: publishing p=none and never moving. At p=none you have reporting and Gmail/Yahoo compliance, but spoofing your domain still works perfectly. The eight-week plan below is deliberately paced so each step is validated by data: most domains with a handful of sending services complete it comfortably; complex organizations stretch the middle weeks, not the method.

Publish (or confirm) a p=none record with a rua reporting address and let the reports accumulate. Your single deliverable for this stage is an inventory: every source sending mail as your domain, classified as a known service, an internal system, a forwarder, or unknown. Aggregate reports give you each source's IP addresses, volumes, and authentication results; the work is mapping IPs to names: this ESP (email service provider, a tool like Mailchimp or SendGrid that sends on your behalf), that office IP, this cloud provider.

Two weeks is the practical minimum because senders are periodic. Weekly digests, monthly invoices, quarterly statements: a shorter window misses them, and what your inventory misses, enforcement will break. Ask around, too: finance, sales, and support teams reliably know about sending tools that IT doesn't.

Now work through every legitimate source that isn't passing with alignment. The fix is almost always the same shape, applied per service: complete that service's domain-authentication setup so it signs with DKIM (DomainKeys Identified Mail) as your domain, and add its include to your SPF (Sender Policy Framework) record where the service uses your domain in the envelope.

Every major ESP has this setup flow (usually named domain authentication, custom DKIM, or verified domain), and it ends with the service giving you two or three CNAME or TXT records to publish in DNS. Prioritize DKIM over SPF for each sender: DKIM alignment survives forwarding, and for many ESPs it's the only alignment you can get, since they use their own bounce domain for SPF. While you're editing SPF, watch the 10-DNS-lookup limit: adding services is exactly how records quietly exceed it and start returning errors.

Once reports show every known sender passing (the readiness bar is above roughly 98% of legitimate volume, held for two full weeks), move to p=quarantine with pct=25. The pct tag asks receivers to apply the policy to only that percentage of failing mail, downgrading the rest, so early mistakes affect a fraction of traffic. Step up 25 → 50 → 100 every few days as reports stay clean.

At this stage, failing legitimate mail lands in spam folders rather than disappearing, which makes problems visible and recoverable. Warn your support team to take 'your email went to my spam' reports seriously for these two weeks: they're your early-warning system. If a legitimate sender surfaces, drop pct (or return to p=none), fix it as in weeks 3-4, and resume the ramp.

After quarantine has run clean at pct=100 for at least a week, publish p=reject. Spoofed mail now bounces at the receiver's front door. This is the destination, and the protection insurers and enterprise security reviews ask about. Keep monitoring: reports keep flowing at reject, and they're how you'll catch the marketing team's next tool before it becomes an incident.

Have rollback criteria written down before you enforce, so the decision under pressure is mechanical, not emotional:

Three traps account for most enforcement incidents. First, forgotten transactional senders: marketing mail is loud in reports, but password resets, receipts, and calendar invites are low-volume and easy to overlook until reject makes them bounce. This is why the two-week observation floor and the readiness criteria exist.

Second, forwarding false alarms: forwarded mail fails SPF by design, shows up in reports as failures from unfamiliar IPs, and panics people into thinking enforcement is breaking things. Check DKIM: if it passes with your domain, DMARC passes and nothing is wrong. Third, subdomains: your policy flows down to subdomains unless sp= says otherwise, so a subdomain that sends mail (mail.yourdomain.com, alerts.yourdomain.com) must be authenticated on the same schedule, or given a temporary explicit sp=none while you finish it. This staged rollout, including the readiness math and the per-sender fix list, is precisely what DMARCPath automates: it tells you when your numbers say you're ready and hands you the next record to paste.