# Should You Make Your DMARC Policy Stricter Over Time?

> Yes — tighten DMARC gradually: start at p=none, move to quarantine, then reject. Here is the safe timeline, with pct rollout and report monitoring.

Yes — you should absolutely make your DMARC policy stricter over time. A DMARC record set to `p=none` forever gives you visibility but zero protection: spoofed mail using your domain still lands in inboxes. The goal is enforcement (`p=quarantine` or `p=reject`), reached gradually so legitimate email never breaks.


## Quick Takeaways

- `p=none` is a starting point for monitoring, not a destination — it blocks nothing.
- Move in stages: none → quarantine → reject, watching [DMARC reports](/resources-post/how-to-understand-dmarc-reports) at every step.
- Use the `pct` tag to apply stricter policies to a fraction of mail first (e.g. `pct=25`).
- Each stage typically lasts a few weeks to a few months, depending on how many services send mail for your domain.
- Google, Yahoo, and Microsoft now require authentication for bulk senders — enforcement is becoming table stakes, not best practice.

## Why start with p=none at all?

When you first publish a [DMARC record](/tools/dmarc), you usually don't know every service sending mail on your domain's behalf — marketing platforms, CRMs, billing tools, support desks. `p=none` turns on aggregate reporting so you can inventory those senders and fix their SPF and DKIM alignment before any mail is at risk of being quarantined.

## The recommended path to enforcement

1. **Monitor (`p=none`)** — collect reports for 2–6 weeks. Identify every legitimate sending source and align its SPF or DKIM.
2. **Partial quarantine (`p=quarantine; pct=25`)** — a quarter of failing mail goes to spam. Watch for false positives among real senders.
3. **Full quarantine (`p=quarantine`)** — all unauthenticated mail is flagged. Most organizations sit here for several weeks.
4. **Reject (`p=reject`)** — spoofed mail is refused outright. This is full protection and the policy Gmail and Yahoo treat as the strongest trust signal.

Each transition should be driven by what your reports show, not the calendar. If failures are all malicious traffic, move faster. If a legitimate newsletter tool keeps failing alignment, fix it before tightening.

## What happens if you tighten too fast?

Real mail gets quarantined or bounced: invoices, password resets, sales outreach. That's why the `pct` ramp and report monitoring matter — they let you catch a misconfigured sender while the blast radius is small. Remember that DMARC depends on accurate SPF and DKIM setup; validate your records with an [SPF check](/tools/spf) and [DKIM check](/tools/dkim) before each step.

## How long should the whole journey take?

For a small domain with one or two sending services, 4–8 weeks is realistic. For businesses or MSP client portfolios with many SaaS senders, three to six months is common. The timeline matters less than the direction: every month at `p=none` is a month attackers can spoof your domain freely.

Palisade automates this entire progression — inventorying senders from your reports, telling you when each source is aligned, and recommending exactly when it's safe to tighten. Check where your domain stands today with the free [Email Security Score](/tools/email-security-score).

## Related reading

- [SPF Softfail (~all) vs. Hardfail (-all)](/resources-post/spf-softfail-all-vs-hardfail--all-why-softfail-is-the-smarter-choice)
- [What are DMARC, DKIM, and SPF?](/resources-post/what-are-dmarc-dkim-and-spf)
- [What is DMARCbis? The Future of DMARC](/resources-post/what-is-dmarcbis-the-future-of-dmarc)