DMARC's Final Mile: A Pragmatic 90-Day Playbook for p=reject

One of your executives just reported a phishing email. It's a classic wire transfer request, perfectly spoofed with their display name and email address. You check the headers. SPF failed, DKIM was absent, but the mail still landed in their inbox. Why? Your company’s DMARC record is set to p=none. It told the recipient's mail server to do absolutely nothing.

For years, IT admins have treated a `p=none` policy as a safe, permanent state. It's 'set it and forget it' email security—a checkbox ticked for compliance, providing visibility without risk. But that era is over. A 'monitor only' policy is an open invitation to attackers who can, and do, query your domain's DNS for that exact sign of weakness.

Getting to `p=reject` is the only way to slam the door on direct domain spoofing. It feels risky. The fear of blocking legitimate mail from a forgotten third-party service is real. But the risk of inaction is greater. Here is a battle-tested, 90-day sprint to get your domain fully enforced, moving from a liability to a fortress.

Why p=none Is a Liability, Not a Policy

Let’s be clear: `p=none` doesn't protect you. It is a data collection mechanism, and nothing more. The 'p' stands for policy, and `none` instructs receiving mail servers to take no action against mail that fails DMARC validation. The message is delivered, often without any warning to the end-user. You get a report about the failure, but the threat has already landed.

Threat actors are not amateurs. They automate reconnaissance. Before launching a Business Email Compromise (BEC) campaign targeting your employees or customers, they will perform a simple DNS lookup. `dig txt _dmarc.yourdomain.com`. When they see `v=DMARC1; p=none;`, it’s a green light. They know they can impersonate your domain with a high probability of success.

The stakes are now higher than just blocking phishing. Industry initiatives like Brand Indicators for Message Identification (BIMI) require DMARC enforcement (`p=quarantine` or `p=reject`) to display your company's logo in the recipient’s inbox. Without it, you are ceding control of your brand's presentation and trustworthiness to a system with no security guarantees. A `p=none` policy caps your domain's potential and leaves it vulnerable.

The 90-Day Sprint: From Monitoring to Rejection

A staged rollout is the key to a successful DMARC enforcement project. This isn't a task you rush on a Friday afternoon. It's a deliberate, three-phase process of observing, testing, and finally, enforcing. Each phase builds on the last, minimizing the risk of disruption.

Days 1–30: Ingest and Analyze (p=none)

This is your baseline phase. If you haven't already, publish your DMARC record with `p=none` and a valid `rua` tag pointing to an address you control. The `rua` tag requests aggregate reports from receivers. These XML reports are the ground truth for who is sending email purporting to be you. Your only job in this month is to collect and analyze this data.

You are hunting for two things: legitimate, unauthenticated sources and outright abuse. Legitimate sources are the third-party vendors your teams use to send mail: your marketing automation platform, your HR benefits portal, your accounting software. Their sending IPs or domains need to be added to your SPF record or configured for DKIM signing. The abuse is obvious: mail from suspicious IP ranges with consistent DMARC failures. Ignore the noise and focus on cataloging your legitimate sender inventory.

Days 31–60: The Quarantine Dry Run (p=quarantine)

Once your RUA reports look clean—meaning all your known, legitimate senders are passing DMARC—it's time to escalate. Change your policy from `p=none` to `p=quarantine`. This policy advises receivers to treat failing messages with suspicion, which usually means sending them to the spam folder. It's a crucial intermediate step. You get to see the impact of enforcement without the finality of dropping messages entirely.

During this phase, monitor your helpdesk tickets and work with a DMARC monitoring service to watch for any spikes in quarantined mail from legitimate sources. Did you forget the transactional email service your developers spun up last year? Now is when you’ll find out, and the impact is a trip to the spam folder, not a lost invoice.

Days 61–90: Flipping the Switch (p=reject)

If the quarantine phase passed without major incidents, you are ready for full enforcement. But you don't have to go all-in at once. The DMARC specification (RFC 7489) provides a `pct` (percent) tag. You can start by publishing `p=reject; pct=10;`. This tells receivers to reject only 10% of emails that fail DMARC. The rest will fall back to the quarantine policy. This lets you dip your toe in the water.

Over the next few weeks, ramp up the percentage: 25%, 50%, 75%, and finally 100%. Once you remove the `pct` tag entirely your policy is `p=reject`, and you have effectively blocked unauthorized use of your domain in email. If you did the work in the first 60 days, this final step should be a non-event.

Decoding DMARC's Data Feeds

DMARC's power comes from its reporting mechanisms. Without them, you're flying blind. But the raw data can be overwhelming. Understanding what the reports are—and what they aren't—is critical.

Reading Aggregate (RUA) Reports

Aggregate reports are XML-formatted summaries of email authentication results from receivers around the world. You absolutely need a third-party service to parse and visualize these; manually reading thousands of gzipped XML files from Gmail, Microsoft, and others is not a job for a human. These reports show you sending IP addresses, SPF and DKIM authentication results, and DMARC disposition counts. Most importantly, they show you DMARC alignment.

Alignment is where many get tripped up. It's not enough for an email to have a passing SPF or DKIM signature. For DMARC to pass, the domain used for SPF or DKIM authentication must align with the domain in the 'From' header that the user sees. A third-party sender might have a perfectly valid SPF record for their own domain, but if it doesn't align with your domain, DMARC will fail. This is the detail RUA reports expose.

<auth_results>
<dkim>
<domain>third-party-sender.net</domain>
<result>pass</result>
</dkim>
<spf>
<domain>yourdomain.com</domain>
<result>pass</result>
</spf>
</auth_results> — Example auth_results block showing misaligned DKIM

The False Promise of Forensic (RUF) Reports

The `ruf` tag requests forensic reports, which are redacted copies of individual emails that failed DMARC. In theory, this sounds incredibly useful for incident response. In practice, it's a privacy minefield. These messages can contain personally identifiable information (PII) or other sensitive data.

For this reason, almost no major mailbox providers send RUF reports anymore. Requesting them in your DMARC record creates noise and can give a false sense of security. The signal-to-noise ratio is abysmal. Your time is far better spent mastering RUA data, which provides all the information you need to identify sending sources without handling sensitive message content.

Where Enforcement Goes Wrong

Even with a careful rollout, you’ll encounter edge cases that break email authentication. Understanding these common failure modes ahead of time will save you hours of troubleshooting.

Forwarders and the SPF Problem

The classic DMARC problem is the forwarded message. Imagine a calendar invite from a vendor is sent to an employee's work address, who has an auto-forwarding rule to their personal Gmail. The forwarding server is not listed in the original vendor's SPF record (as defined by RFC 7208). When Gmail receives the forwarded message, it checks SPF against the forwarding server's IP, which fails. This breaks SPF authentication.

This is precisely why DMARC requires *either* SPF *or* DKIM to pass and align. A valid DKIM signature (RFC 6376) survives forwarding because it's tied to the message content and headers, not the transport path. If you control the sending infrastructure, ensure you are signing with DKIM.

Mailing Lists and Body Hash Mismatches

Mailing lists and some security gateways are notorious for breaking DKIM signatures. They often append a footer to the message body, like an 'Unsubscribe' link. This modification changes the body of the email, causing the DKIM body hash to no longer match the value stored in the `bh=` tag of the DKIM-Signature header. The signature is invalidated.

The modern solution for this is the Authenticated Received Chain (ARC), specified in RFC 8617. ARC creates a cryptographic chain of custody, preserving the initial authentication results (found in the `Authentication-Results` header) as the email traverses different hops. An ARC-aware receiver can see that the email was valid *before* it was modified by the mailing list, and can choose to trust it despite the broken DKIM signature. Ensure your own inbound gateways are ARC-aware.

Shadow IT and the Third-Party Sprawl

By far, the most time-consuming part of any DMARC project is discovering and onboarding all the legitimate third-party services that send email on your behalf. Marketing buys a new analytics tool, sales signs up for a prospecting service, finance uses a new invoicing platform. None of them tell IT. These services will start failing DMARC checks the moment you move to `p=quarantine`. RUA reports are your only way to discover this 'shadow IT'. This process is less about technology and more about organizational discipline and communication.

The takeaway

Moving to a `dmarc reject policy` is not a hypothetical security exercise; it's a fundamental requirement for operating a domain in 2026. A `p=none` record isn't a safety net; it's a map for attackers. The 90-day plan turns a daunting project into a manageable, phased process that systematically reduces risk.

The goal is simple: make your domain a hardened, unattractive target for impersonation. While DMARC reports provide the aggregate view necessary for policy-making, remember that incident response often requires a deeper dive. When a specific threat does get through, tools like MailSleuth.AI become necessary to dissect the full header chain and SMTP transcript to understand the 'how' and 'why' beyond the DMARC verdict. Get your policy to `reject` first—that's the battle you can win today.