DMARC Deployment: How to Move from p=none to p=reject Without Breaking Email

Most domains have DMARC. Most of those DMARC records do nothing.

A DMARC record at p=none is a monitoring record — it collects data but doesn't protect anyone. Spoofed emails still land in inboxes. Phishing campaigns impersonating your domain still succeed. The record exists; the protection doesn't.

In February 2024, Google and Yahoo made DMARC enforcement a requirement for bulk senders (more than 5,000 emails per day to Gmail). The industry pressure to move from p=none to actual enforcement is real. This is how to do it safely.

What the three DMARC policies actually do

p=none Monitoring mode. Receiving mail servers check DMARC alignment but take no action on failures. The rua= tag (if present) causes aggregate reports to be sent to your specified address, showing authentication results for email from your domain.

Emails that fail DMARC are delivered normally. Nothing is blocked. Spoofing protection: zero.

When to use it: when you first add a DMARC record and need to inventory your sending sources before enforcing policy.

p=quarantine Failing emails go to spam/junk rather than inbox. Better than nothing — most recipients don't check spam. Phishing attempts impersonating your domain are degraded but not eliminated.

When to use it: transitional phase after you've identified and authenticated your legitimate sending sources, before confirming everything is working correctly.

p=reject Receiving mail servers are instructed to reject emails that fail DMARC — they don't deliver them at all. This is full spoofing protection. Emails impersonating your domain that lack valid DKIM or SPF alignment are dropped before reaching the inbox.

When to use it: after thorough audit of all sending sources and confirmed DKIM alignment for all legitimate senders.

The safe deployment path

Phase 1: Audit (p=none, 4–6 weeks)

Add a DMARC record with p=none and rua= pointing to an address you monitor:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; fo=1"

Tags explained:

• p=none — monitor only, no action
• rua= — aggregate report destination (daily XML reports from receiving servers)
• ruf= — forensic/failure report destination (individual failure reports; many ISPs don't send these for privacy reasons)
• fo=1 — send forensic reports on any DKIM or SPF failure (rather than only when both fail)

Read the aggregate reports for 4–6 weeks. They show every source sending email with your domain's From: address, and whether each source is passing SPF and DKIM alignment.

Phase 2: Identify and authenticate all sending sources

From the DMARC aggregate reports, create a list of all legitimate sending sources:

• Your primary mail server / email host
• Google Workspace or Microsoft 365 (if used for company email)
• Transactional email provider (Mailgun, Postmark, SendGrid, SES)
• Marketing automation (Mailchimp, HubSpot, ActiveCampaign)
• CRM with email sending (Salesforce, etc.)
• Any third-party service that sends on your behalf

For each source:

• Ensure it's included in your SPF record (or will DKIM-align)
• Ensure it has DKIM configured using your domain (not the provider's domain)

Phase 3: Move to p=quarantine

Once you're confident all legitimate sources are authenticating correctly:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com"

The pct= tag applies the policy to only the specified percentage of failing messages. pct=25 means 25% of DMARC-failing emails go to spam; 75% are still delivered. This lets you catch any authentication problems affecting real mail before full enforcement.

Monitor for 1–2 weeks. If no legitimate emails are being quarantined, increase to pct=100:

"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

Phase 4: Move to p=reject

After a clean period at p=quarantine:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

This is the complete configuration. Spoofed emails using your domain are rejected.

Reading DMARC aggregate reports

Aggregate reports arrive as XML files (usually gzipped). They contain, for each sending source:

• Source IP address
• Count of messages from that source
• Whether SPF passed/failed and aligned
• Whether DKIM passed/failed and aligned
• The DMARC disposition (none/quarantine/reject)

Tools for reading DMARC reports (rather than parsing XML manually):

• DMARC Analyzer (dmarcanalyzer.com) — free tier available
• Postmark's DMARC Digests — free digest service
• Google Postmaster Tools — Gmail-specific but valuable
• Valimail Monitor — free dashboard

The key things to look for in reports:

1. Sources sending email claiming to be from your domain that you don't recognise (potential spoofing or forgotten third-party services)
2. Legitimate sources that are failing DKIM or SPF alignment (need fixing before enforcement)
3. Legitimate sources with dkim=pass and spf=fail (or vice versa) — one passing is sufficient for DMARC, but fixing both is better

Subdomain policy

DMARC has a separate sp= tag for subdomain policy. If you want email from mail.example.com to be treated differently from example.com:

"v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@example.com"

By default, the subdomain policy inherits from p=. An explicit sp= overrides this for subdomains.

The February 2024 Google/Yahoo requirements

Google and Yahoo now require bulk senders (5,000+ emails/day to Gmail) to have:

1. SPF or DKIM authentication (both is better)
2. DMARC at any policy (including p=none)
3. One-click unsubscribe in marketing email
4. Spam rate below 0.3% (target below 0.1%)

This mandate moved DMARC from a best-practice recommendation to a delivery requirement for significant senders. p=none satisfies the requirement technically — but p=reject is the security goal.

How to use the DMARC Lookup on sadiqbd.com

1. Enter the domain
2. Check — the tool queries _dmarc.<domain> and shows:
   • The raw DMARC record
   • Policy in plain English (none/quarantine/reject)
   • Whether rua= is configured for report collection
   • The pct= value (enforcement percentage)
   • Any syntax errors or missing fields

Frequently Asked Questions

What if I move to p=reject and some legitimate emails stop being delivered? Revert to p=quarantine, check your DMARC aggregate reports to identify the failing source, authenticate it properly (add DKIM, fix SPF), then move back to reject. The phased approach (starting with pct=25) minimises this risk.

Does DMARC protect against all phishing? Only phishing that uses your exact domain in the From: header. Lookalike domains (examp1e.com, example-support.com) bypass DMARC because they're different domains. DMARC protects your domain from being spoofed; it can't stop lookalike abuse.

Should I set p=reject for non-email domains? Yes — if you have domains that never send email, set them to p=reject without any SPF or DKIM. This prevents them from being used for phishing:

_dmarc.parking-domain.com.  IN  TXT  "v=DMARC1; p=reject;"

Is the DMARC Lookup free? Yes — completely free, no sign-up required.

The path from p=none to p=reject takes 6–10 weeks done carefully. The endpoint is a domain that can't be impersonated in email — a meaningful security improvement for your organisation and your customers.

Try the DMARC Lookup free at sadiqbd.com — check any domain's DMARC policy, enforcement level, and report configuration instantly.