← Back to Guides

DMARC Policy Guide

The path from p=none to p=reject. Learn when and how to tighten your DMARC policy safely.

The Three DMARC Policies

The p= tag in your DMARC record is the most important setting. It tells receiving mail servers what to do with messages that fail both SPF and DKIM alignment. There are three possible values:

p=none — Monitor Only

No enforcement. Messages that fail DMARC are delivered normally. Aggregate reports are still generated and sent to the address in your rua= tag, giving you full visibility into authentication results without any risk of blocking legitimate email.

This is the correct starting policy for every domain. It allows you to discover all sources sending as your domain and fix authentication issues before enforcement begins.

p=quarantine — Soft Enforcement

Messages that fail DMARC are treated as suspicious. In practice, most receiving servers will deliver these messages to the spam or junk folder rather than the inbox. This policy begins protecting your domain while giving you a safety net — if a legitimate sender was missed during the monitoring phase, their messages will still reach recipients (albeit in spam) rather than being discarded entirely.

p=reject — Full Enforcement

Messages that fail DMARC are rejected outright by the receiving server. They are not delivered to any folder. This is the strongest protection against spoofing and is the ultimate goal of any DMARC deployment. Major mailbox providers like Google and Yahoo require bulk senders to have a DMARC policy, and p=reject provides the maximum benefit.

The Recommended Progression Path

Moving directly from no DMARC to p=reject is risky because it can block legitimate email from services you did not know were sending as your domain. The safe approach is a gradual progression:

Phase 1: Monitor (2-4 weeks minimum)

v=DMARC1; p=none; rua=mailto:your-token@agg.dmarcwatch.io; fo=1;

Publish this record and monitor aggregate reports in DMARCWatch. Identify every legitimate source and ensure they pass SPF or DKIM with proper alignment. Common sources to check include your primary email provider, marketing platforms, CRM systems, helpdesk tools, and transactional email services.

Phase 2: Quarantine with Percentage (2-4 weeks)

v=DMARC1; p=quarantine; pct=25; rua=mailto:your-token@agg.dmarcwatch.io; fo=1;

The pct=25 tag tells receivers to apply the quarantine policy to only 25% of failing messages. The remaining 75% are treated as if the policy were none. This limits the blast radius if a legitimate sender is still misconfigured. Gradually increase pct to 50, then 75, then 100 as you confirm there are no issues.

Phase 3: Full Quarantine (2-4 weeks)

v=DMARC1; p=quarantine; rua=mailto:your-token@agg.dmarcwatch.io; fo=1;

With pct omitted (or set to 100), all failing messages are quarantined. Monitor your reports to confirm no legitimate mail is ending up in spam.

Phase 4: Reject with Percentage (2-4 weeks)

v=DMARC1; p=reject; pct=25; rua=mailto:your-token@agg.dmarcwatch.io; fo=1;

Begin rejecting a portion of failing messages. Ramp up the percentage over time.

Phase 5: Full Reject

v=DMARC1; p=reject; rua=mailto:your-token@agg.dmarcwatch.io; fo=1;

Your domain is now fully protected. All messages that fail DMARC alignment will be rejected. Continue monitoring reports in DMARCWatch to catch any new services added to your email infrastructure.

DMARC Record Tags Reference

Here is a complete reference of all DMARC tags:

  • v=DMARC1 — Required. Version identifier. Must be the first tag in the record.
  • p= — Required. Policy for the domain. Values: none, quarantine, reject.
  • sp= — Subdomain policy. Applies to all subdomains that do not have their own DMARC record. If omitted, the p= policy applies to subdomains as well.
  • rua= — Aggregate report destination. A comma-separated list of mailto: URIs where daily aggregate reports should be sent. Example: rua=mailto:dmarc@yourdomain.com.
  • ruf= — Forensic (failure) report destination. Receives detailed reports for individual failing messages. Many providers do not send forensic reports due to privacy concerns, but the tag is still useful where supported.
  • pct= — Percentage of failing messages to which the policy applies. Value from 1 to 100. Default is 100. Use this to gradually roll out enforcement.
  • adkim= — DKIM alignment mode. r for relaxed (default), s for strict. Relaxed allows subdomains to align with the organisational domain.
  • aspf= — SPF alignment mode. r for relaxed (default), s for strict.
  • fo= — Failure reporting options. 0 = report if both SPF and DKIM fail (default). 1 = report if either fails. d = report DKIM failure. s = report SPF failure.
  • ri= — Reporting interval in seconds. Default is 86400 (24 hours). Most providers ignore this and send reports on their own schedule.

Subdomain Policy

The sp= tag deserves special attention. Many organisations focus on protecting their primary domain but forget that subdomains can also be spoofed. If you do not send email from subdomains, you can set a strict subdomain policy immediately:

v=DMARC1; p=none; sp=reject; rua=mailto:your-token@agg.dmarcwatch.io;

This record monitors the main domain while rejecting all email from subdomains that do not have their own DMARC record. This is a quick win — attackers frequently spoof subdomains like billing.yourcompany.com or support.yourcompany.com because they are often unprotected.

If specific subdomains do send email, publish individual DMARC records for them (e.g., _dmarc.marketing.yourcompany.com) with appropriate policies.

Common Pitfalls

  • Moving too fast. Jumping to p=reject before auditing all senders will block legitimate email. Always start with p=none and use DMARCWatch to identify every source.
  • Ignoring the pct tag. The percentage rollout is your safety valve. Use it during every policy transition.
  • Forgetting to update after adding services. Whenever you add a new email-sending service (a new CRM, ticketing system, or newsletter tool), update your SPF and DKIM configuration before the service goes live.
  • Not monitoring after reaching reject. DMARC is not a set-and-forget configuration. Infrastructure changes, new services, and provider updates can break authentication. Continuous monitoring with DMARCWatch ensures you catch issues early.
← Back to Guides