Why a “gradual” DMARC rollout matters
DMARC helps receiving mail systems validate whether messages claiming to be from your domain were actually sent by authorized sources. It also tells receivers what to do when authentication fails. Many organizations want to jump straight to a strict enforcement posture, but doing so without a clear picture of every legitimate sending source can cause real business disruptions, including critical messages being delayed, diverted to spam, or rejected outright.
A gradual rollout is about reducing risk while improving security. You start by collecting visibility (p=none), then apply controlled enforcement (p=quarantine), and finally move to stronger blocking (p=reject) once you are confident that legitimate mail is consistently authenticating. The pct (percentage) setting is what makes this approach practical at scale.
DMARC policy levels explained: p=none, p=quarantine, p=reject
p=none: monitoring and discovery
With p=none, you’re asking receivers to send reports but not to apply enforcement actions based on DMARC failures. This phase is for discovery: finding every system that sends mail using your domain. It’s common for companies to overlook sources beyond the core mail server, such as marketing platforms, CRM notifications, invoicing tools, HR portals, website contact forms, helpdesk systems, and even office devices like multi-function printers.
The goal is simple: identify which sources pass SPF and/or DKIM and which sources fail, then determine whether failures are malicious spoofing or misconfigured legitimate traffic.
p=quarantine: controlled enforcement
p=quarantine tells receivers that messages failing DMARC should be treated as suspicious. In practice, this often means the message is more likely to be delivered to spam/junk or receive heightened filtering. It’s a useful intermediate step because it introduces enforcement without the immediate, hard failure mode of rejecting messages at SMTP time.
p=reject: strong protection against spoofing
p=reject requests that receivers reject messages that fail DMARC. This is the strongest signal and provides the most direct reduction in domain spoofing. However, if you move to reject before all legitimate sources authenticate correctly, you risk blocking valid business communications. For most organizations, reject should be the final step after sustained success at quarantine.
What does pct do in DMARC?
The pct tag allows you to apply your DMARC policy to only a percentage of failing messages. For example, if you set p=quarantine and pct=20, roughly 20% of messages that fail DMARC may be quarantined while the remainder are handled as if you were still monitoring. This reduces the “big bang” effect of enforcement and lets you observe impact in production.
Two practical cautions are worth keeping in mind. First, pct behavior can vary by receiver; not every provider implements it identically. Second, the percentage is approximate rather than perfectly deterministic. Even with those caveats, pct remains one of the best tools for safe, staged enforcement.
A practical DMARC rollout plan (step-by-step)
1) Build a complete inventory of sending sources
Start by listing every system that sends email on behalf of your domain. Don’t limit the inventory to employee mailboxes. Include applications and third parties. For each sender, capture:
- Which domain or subdomain it uses in the visible From address
- Sending IP addresses or outbound SMTP service
- Typical message types (invoices, password resets, marketing, alerts)
- Whether SPF authorization is supported
- Whether DKIM signing is supported and how it’s configured
This inventory becomes your operational map throughout the rollout. It also helps you avoid “mystery senders” appearing later when enforcement is already strict.
2) Start with p=none and learn from reporting
In the monitoring phase, your DMARC aggregate reports help you understand authentication outcomes by source. Your task is to classify failures into two buckets:
- Unauthorized spoofing (mail you do not control)
- Legitimate sources that are misconfigured or incomplete (mail you do control)
Common reasons legitimate mail fails DMARC include missing SPF authorization, lack of DKIM signing, using the wrong DKIM domain, or sending patterns that break SPF (such as certain forwarding scenarios).
3) Fix SPF and DKIM, and aim for consistency
A smooth rollout depends on getting your real senders to authenticate reliably. Practical guidance:
- Keep your SPF record focused on actual sending sources; avoid “stuffing” it with unnecessary mechanisms.
- For each third-party sender, implement the provider’s recommended SPF inclusion and DKIM setup.
- Plan DKIM selectors and key lifecycle management so keys can be rotated without disruption.
- Consider separating traffic by subdomain (for example, marketing.example.com) to make reporting, troubleshooting, and risk management easier.
Even though DMARC can pass with either SPF or DKIM, using DKIM wherever possible often improves stability because DKIM is less sensitive to routing changes than SPF.
4) Move to p=quarantine with a low pct
Once reporting shows that the vast majority of legitimate sources authenticate correctly, shift to p=quarantine and start with a conservative pct, such as 10–25. This stage is where you validate the “real-world” behavior across different receiving systems.
During this phase, monitor:
- User and customer reports of missing email
- Critical workflows (billing, order confirmations, password resets, HR communications)
- Ongoing DMARC failure volume and which sources are responsible
As you fix remaining legitimate issues, increase pct in steps (for example 25 → 50 → 75 → 100), allowing time between each change based on your email volume and operational risk tolerance.
5) Transition to p=reject gradually
After p=quarantine at pct=100 has been stable and the remaining DMARC failures are clearly unauthorized, plan your move to p=reject. You can also use pct here: start with a partial percentage and ramp up after confirming no legitimate traffic is being impacted.
A sensible readiness signal for many organizations is: aggregate reports show consistent authentication for all known senders, and helpdesk/support tickets related to missing messages have dropped to near zero during full quarantine.
Common mistakes that break legitimate mail
Assuming “small” senders don’t matter
A low-volume sender can still be business-critical (for example, a branch office device sending scanned documents, or an older application sending approval workflows). Verify business impact before deciding to ignore a failing source.
Over-relying on SPF alone
Trying to solve everything with SPF can create operational complexity and push technical limits. Where feasible, implement DKIM and consider delegating certain mail streams to subdomains to keep authentication manageable and clearer.
Forgetting subdomains and edge cases
DMARC for the organizational domain doesn’t automatically eliminate complexity for every subdomain. If different teams or tools use different subdomains, treat them as part of the rollout plan and confirm how policy inheritance is intended to work in your environment.
An operational checklist for DMARC enforcement
- Have you identified every sending system (including third parties and devices)?
- Is there an owner for SPF/DKIM configuration for each sender?
- Are DMARC reports being reviewed on a schedule, not just once?
- Do you have a target authentication pass rate for legitimate mail?
- Is there a planned cadence for pct increases at quarantine and reject?
- Have you tested business-critical message flows end-to-end?
- Do you have defined “go/no-go” criteria for moving to p=reject?
Conclusion: improve security without sacrificing deliverability
A careful DMARC rollout helps you reduce spoofing risk while protecting legitimate mail delivery. By starting with p=none, fixing authentication for all real senders, then moving through p=quarantine and finally p=reject using pct for gradual enforcement, you can reach a strong posture with fewer surprises.
If you’re managing business email for a growing organization, keeping your sending-source inventory, DNS authentication records, and mailbox administration organized makes DMARC enforcement much easier. In practice, teams often find it simpler to execute and maintain these changes when their day-to-day email operations are managed in a structured business email environment such as MX1Mail.