DMARC Enforcement: From p=none to p=reject

Most organisations start DMARC with p=none — monitoring mode. It's the right first step: you get visibility into who's sending email as your domain without risking delivery. But monitoring is not protection. The goal is to reach p=reject, where unauthenticated email is blocked outright.

The gap between p=none and p=reject is where most organisations get stuck. They publish a monitoring record, maybe review a few reports, and then leave it there — sometimes for months or years. The domain remains fully spoofable the entire time.

This guide walks through the enforcement journey step by step, with the practical detail you need to move forward confidently.

Why Enforcement Matters

A DMARC record with p=none tells receiving servers: "Check authentication, send me reports, but deliver everything regardless." It's useful for data collection, but it provides zero protection. Every phishing email, every spoofed message, every unauthorised sender gets delivered exactly as if you had no DMARC record at all.

The real-world consequences of staying at p=none are tangible:

• Brand damage — Phishing emails impersonating your domain reach your customers' inboxes. Even if your customers don't fall for them, the association erodes trust.
• Deliverability risk — Email providers factor domain reputation into delivery decisions. If your domain is associated with spoofed email (because you're not enforcing), your legitimate email can suffer.
• Compliance gaps — Google, Yahoo, and Microsoft now require DMARC enforcement for bulk senders. Google specifically recommends p=quarantine at minimum for domains sending more than 5,000 messages per day to Gmail users.

Moving to enforcement — p=quarantine or p=reject — is what actually protects your domain and your recipients. The question isn't whether to enforce, but how to get there without breaking legitimate email.

For background on what each policy level does and when to choose one over the other, see DMARC policy explained and quarantine vs reject: which should you choose?.

Before You Start: Audit Your Senders

The single most important step before enforcement is knowing exactly who sends email as your domain. If you move to p=quarantine before a legitimate sender is aligned, their email goes to spam. If you move to p=reject, it bounces entirely.

Review your DMARC aggregate reports to build a complete sender inventory. For each source IP in your reports, determine:

1. Is this a service you authorised? — Marketing platforms (Mailchimp, HubSpot, ActiveCampaign), transactional email (SendGrid, SES, Postmark), CRMs (Salesforce, HubSpot), helpdesks (Zendesk, Freshdesk), and any other tool that sends email on your behalf.
2. Is it aligned? — Does the sender pass SPF or DKIM with a domain that matches your From header? Passing authentication isn't enough — it must align.
3. Is it a forwarding service? — Mailing lists, forwarding rules, and email relays can break SPF. These are harder to fix and usually require DKIM alignment as the fallback.
4. Is it unauthorised? — Spoofing, phishing, or a former employee's tool that was never decommissioned.

The most commonly missed senders are internal systems — automated alerts from servers, monitoring tools that email notifications, legacy applications that send directly via SMTP without proper authentication.

If you find a legitimate sender that isn't aligned, fix it before proceeding. The fix is almost always one of two things: add the sender's IP to your SPF record, or (better) configure the sender to sign with your domain via DKIM. Most modern services provide DKIM setup instructions — it's usually a pair of DNS CNAME records and a toggle in the sender's settings.

The Safe Migration Path

Step 1: Start with p=none

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

This is monitoring mode. No email gets blocked, but you receive aggregate reports from every receiving server that processes email claiming to be from your domain.

Stay here for 2–4 weeks minimum. The goal is to collect enough report data to build a complete picture of your email ecosystem. One week of data might miss senders that only send monthly (invoicing tools, newsletter services with low-frequency campaigns).

During this phase:

• Parse your aggregate reports daily — look for any source with a high message count and a failing DMARC result
• Build a spreadsheet of every sending source: IP, service name, SPF result, DKIM result, alignment status
• Fix alignment issues as you find them — don't wait until you've catalogued everything
• Pay attention to low-volume senders — a service that sends 10 emails per month is easy to miss but will cause complaints if those 10 emails start bouncing

Step 2: Move to p=quarantine with a low pct

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@yourdomain.com

The pct=10 means only 10% of failing messages get quarantined (sent to spam). The remaining 90% are treated as if the policy were still p=none — they're delivered normally, and you still get reports about them.

This is your safety net. If you missed a legitimate sender in your audit, you'll affect 10% of their messages — enough to see the failure in your reports and hear about it from users, but not enough to cause a deliverability crisis.

What to watch for after this change:

• Aggregate reports — Look for any legitimate sender where the disposition changes from "none" to "quarantine." This means they're being affected by your new policy.
• User complaints — If anyone reports missing email, check whether the sender appears in your reports as a failing source.
• Bounce notifications — Some receivers interpret quarantine differently. Most send to spam, but some may reject outright.

If everything looks clean after 1–2 weeks, proceed to ramp up.

For a full explanation of how the percentage tag works and common pitfalls, see the DMARC pct tag explained.

Step 3: Ramp up pct gradually

Increase the percentage in steps, monitoring reports after each change:

The timeline above is a suggestion, not a rule. If your email ecosystem is simple (one domain, one or two ESPs, no mailing lists), you can compress this to 2–3 weeks total. If you have dozens of third-party senders, legacy systems, and complex forwarding rules, you might spend 2 weeks at each stage.

The key principle: don't increase pct until your reports are clean at the current level. If you're seeing legitimate senders fail at pct=25, fix their alignment before moving to pct=50.

If your reports show no legitimate senders failing, you can skip stages. There's no technical benefit to spending 8 weeks at quarantine if everything is aligned after 2.

Step 4: Move to p=reject

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

At p=reject, receiving servers refuse messages that fail DMARC entirely. The email never reaches the inbox or the spam folder — it's rejected at the SMTP level, and the sender receives a bounce notification.

This is full enforcement — the strongest protection against domain spoofing.

You can optionally repeat the pct ramp-up with p=reject if you want extra caution: start with p=reject; pct=10 and work your way up. In practice, most organisations jump straight from p=quarantine; pct=100 to p=reject — if everything is passing at quarantine, it will pass at reject too.

After reaching p=reject, keep monitoring. Your aggregate reports are now your safety net. Services change their sending infrastructure, employees add new tools, configurations drift. A sender that was aligned last month might break their DKIM setup in an update. Your reports will catch it.

DMARC Alignment in Practice

Enforcement only works when your legitimate senders pass DMARC alignment. This trips up many organisations because SPF and DKIM can both pass without alignment.

What alignment means: The domain used in the authentication check must match the domain in the From header that the recipient sees.

• SPF alignment — The domain in the Return-Path (envelope sender) matches the From header domain
• DKIM alignment — The domain in the DKIM d= tag matches the From header domain

Only one needs to align. If DKIM aligns, SPF alignment doesn't matter (and vice versa).

Relaxed vs strict mode: DMARC defaults to relaxed alignment, where the organisational domain must match. This means mail.example.com aligns with example.com. Strict mode requires an exact match — mail.example.com does not align with example.com. Most organisations should use relaxed, and there's rarely a reason to change it.

The most common alignment failure: A third-party service sends email with your domain in the From header, but their DKIM signature uses their own domain (e.g., d=sendgrid.net instead of d=yourdomain.com). SPF might pass, but the envelope sender is also the service's domain. Neither aligns with your From address, so DMARC fails — even though both SPF and DKIM technically passed.

The fix is almost always configuring custom DKIM in the third-party service. This makes them sign with d=yourdomain.com, which aligns with the From header. Most services support this through DNS CNAME records.

Read the full explanation at DMARC alignment explained.

Subdomain Policy

The sp= tag lets you set a different DMARC policy for subdomains than for your main domain. This is useful in several scenarios:

Main domain enforced, subdomains not ready:

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc-reports@yourdomain.com

This protects your main domain with p=reject while giving subdomains a softer landing at p=quarantine. Useful if you have subdomains with third-party senders that aren't fully aligned yet.

Blocking unused subdomains:

If you only send email from your main domain and mail.yourdomain.com, any other subdomain (e.g., test.yourdomain.com, staging.yourdomain.com) is a spoofing risk. Setting sp=reject blocks unauthenticated email from all subdomains, even ones you don't actively use.

When to skip sp=: If your main domain policy applies equally to all subdomains, you don't need sp= — subdomains inherit the p= policy by default.

See DMARC subdomain policy explained for more on when and how to use this tag.

Compliance Requirements

DMARC enforcement is no longer optional for many senders:

• Google requires DMARC with at least p=none for all senders and recommends p=quarantine or p=reject for bulk senders (5,000+ messages per day to Gmail). Domains without DMARC see reduced deliverability.
• Yahoo has aligned with Google's requirements, enforcing the same thresholds.
• Microsoft has announced similar requirements for Outlook.com and Hotmail, with enforcement beginning in 2025.

Even if you're under the bulk sender threshold, enforcement improves your deliverability. Email providers use DMARC as a positive signal — domains with p=reject are treated as more trustworthy than those with p=none.

The trend is clear: DMARC enforcement is becoming baseline. Organisations that move now are ahead of the curve. Those that wait will eventually be forced to move anyway, likely under time pressure when a compliance deadline hits.

See DMARC compliance: what you need to know for the full picture on requirements across all major providers.

Check Your Current Policy

Use our free DMARC record checker to see your current policy level, verify alignment for your sending sources, and get specific recommendations for your next step toward enforcement.