The short answer: The DMARC p= tag tells receiving servers what to do with mail that fails DMARC. p=none delivers it normally and only sends you reports. p=quarantine sends it to spam. p=reject blocks it during the SMTP conversation. Start at none, fix every legitimate sender, then move to quarantine and reject, using the pct tag to phase each step.
What a DMARC Policy Actually Controls
DMARC passes when at least one of two checks passes and is aligned with the domain in the visible From address: SPF (the sending IP is authorised and the Return-Path domain matches) or DKIM (a valid signature whose d= domain matches). If neither does, the message fails DMARC and the receiver applies your policy.
A minimal record, published as a TXT record at _dmarc.yourdomain.com:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
The policy only matters for mail that fails. Mail that passes is delivered as usual under every policy. That is why the real question is never "is reject dangerous?" but "do all my legitimate senders pass?" Aggregate reports answer it, which is why rua= belongs in the record from day one (see how to read DMARC aggregate reports).
The Three Policies Side by Side
p=none |
p=quarantine |
p=reject |
|
|---|---|---|---|
| Failing mail is... | Delivered normally | Delivered to spam or junk (receiver's discretion) | Refused at SMTP; never delivered |
| Spoofing protection | None | Partial | Strong |
| Risk if a real sender fails | None | Lands in spam | Bounces or is dropped |
| You receive reports | Yes | Yes | Yes |
| Eligible for BIMI | No | Yes (at pct=100) |
Yes (at pct=100) |
| Typical stay | 2–4 weeks minimum | 2–4 weeks | Permanent |
p=none: monitor only
With none, receivers evaluate DMARC and report the results but change nothing about delivery. This is how you discover every system sending as your domain, including ones nobody remembers setting up. It gives no protection: anyone can still spoof you. Leaving a domain at none indefinitely is the most common DMARC mistake, because it looks like progress but blocks nothing.
p=quarantine: soft enforcement
Receivers treat failing mail as suspicious. In practice that usually means the spam or junk folder, but the RFC leaves the exact handling to the receiver, so some will apply extra scrutiny rather than a straight spam-folder placement. It is a safety net: a misconfigured legitimate sender is recoverable because recipients and admins can still find the message.
p=reject: full enforcement
Receivers refuse failing mail during the SMTP transaction, so the sender gets a bounce and the recipient never sees it. Typical rejection text looks like this (wording varies by provider):
550 5.7.1 Unauthenticated email from yourdomain.com is not accepted due to domain's DMARC policy.
This is the only policy that actually stops spoofed mail from reaching inboxes, and it is the level required for BIMI and expected by most security frameworks.
Stage the Rollout With pct
The pct tag applies your policy to only a percentage of failing mail. The remainder is handled one level below (quarantine falls back to none; reject falls back to quarantine). It lets you test enforcement on a slice of traffic before committing.
| Stage | Record | Watch for |
|---|---|---|
| 1 | p=none; rua=... |
Discover all senders; fix SPF and DKIM |
| 2 | p=quarantine; pct=10 |
Legitimate mail reaching spam |
| 3 | p=quarantine; pct=50, then pct=100 |
Same, at higher volume |
| 4 | p=reject; pct=10 |
Bounces from known senders |
| 5 | p=reject; pct=50, then pct=100 |
Full enforcement |
Hold each stage for at least a week so weekly and monthly sends (newsletters, invoices, payroll) appear in your reports. Some receivers do not honour pct precisely, so treat it as a damping control, not a guarantee. Full example:
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com
If BIMI is a goal, remember that mailbox providers require pct=100 before the logo displays.
Subdomains and the sp Tag
By default a subdomain inherits the parent domain's policy. The sp= tag sets a different policy for subdomains:
v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@yourdomain.com
Two useful patterns:
- Domains you never send from (parked domains, old brands): publish
p=rejectstraight away along with a null SPF record (v=spf1 -all). There is no legitimate mail to break. - Enforcing the main domain while a subdomain is still being cleaned up: publish
p=rejecton the parent and a separate_dmarc.news.yourdomain.comrecord atp=nonefor the subdomain that still needs work. A subdomain with its own DMARC record uses that record instead of the parent's.
Attackers often spoof non-existent subdomains, so setting sp= explicitly is worth doing even if you never plan to use subdomains.
Why Legitimate Mail Fails DMARC
Before enforcing, look for these in your reports. They account for most surprises.
| Symptom in reports | Likely cause | Fix |
|---|---|---|
| Known service: SPF pass, DMARC fail | SPF passes for the vendor's bounce domain, which is not aligned with your From | Enable custom return-path or domain authentication at the vendor |
| Known service: DKIM pass, DMARC fail | Signing with the vendor's domain, not yours | Publish the vendor's DKIM CNAME records so it signs as your domain |
| Source IP unknown, both fail | Forgotten tool or spoofing | Identify the owner with a WHOIS lookup; authenticate or leave it to be blocked |
| Mailing-list or forwarded mail fails | Forwarding breaks SPF; lists often modify the message and break DKIM | Expect a small residual failure rate; DKIM-signed mail survives most forwarding |
| Sudden DKIM failures from one sender | Key rotated or removed | Re-publish the selector record; check with the DKIM checker |
SPF permerror |
Over 10 DNS lookups | Flatten or trim; see SPF too many DNS lookups |
Alignment is the usual trap. A message can show spf=pass and still fail DMARC because the passing domain is not your From domain. Most marketing and CRM platforms need DKIM or custom-domain setup to align. The third-party sender SPF guide covers the SPF side.
When Is It Safe to Move Up?
From none to quarantine:
- Every legitimate sender you know about appears in reports with aligned DKIM or SPF passing.
- Any unknown source has been identified, fixed, or consciously left to fail.
- You have at least 2–4 weeks of reports, covering one full monthly cycle.
From quarantine to reject:
- No users or vendors report real mail in spam.
- Reports show your legitimate volume passing DMARC consistently (aim for as close to 100% as you can; small residual forwarding failures are normal).
- Someone owns the process for onboarding new senders, so a new tool is authenticated before it sends. Otherwise the first email from a new platform will bounce.
What If Something Breaks After You Enforce?
Rolling back is just a DNS edit. If a legitimate sender starts bouncing:
- Change
p=rejecttop=quarantine(or lowerpct) at_dmarc.yourdomain.com. - Find the failing source in your aggregate reports or in the bounce message.
- Fix its SPF or DKIM alignment.
- Re-tighten after a clean week.
Resolvers cache records for the TTL, so a 3600-second TTL means up to an hour before the change is seen everywhere. Consider lowering TTL to 300 before each policy change and raising it afterwards.
Common Policy Mistakes
- Moving to reject without reports. If
rua=was never set, you have no evidence of what is sending. Add reporting first and wait. - Judging readiness from one report. A single day misses the weekly payroll run, the monthly invoice batch and the quarterly newsletter. Review at least one full month.
- Forgetting transactional systems. Password-reset mail, website contact forms, CRMs, helpdesks, and scanners that email PDFs often send as your domain and sit outside the main mail platform.
- Publishing two records. Editing a DMARC record by adding a new TXT value instead of replacing the old one invalidates both.
- Enforcing the apex and ignoring subdomains. Without
sp=, a subdomain inherits your policy, which may be stricter than a vendor-owned subdomain can handle. - Treating quarantine as the finish line. It is a staging post. Spoofed mail can still reach some inboxes, so plan the final move to
reject.
How to Verify Each Change
After every edit to your record:
- Query the record with the DMARC checker and confirm the new
p=andpctvalues are live. - Send a test message from each sender you rely on to a Gmail account, open Show original, and look for
dmarc=passin the Authentication-Results header. The email header analyzer lays this out clearly. - Watch the next two or three daily reports for new failing sources.
Updating Your Policy
Edit the TXT record at _dmarc.yourdomain.com and change the p= value. Keep exactly one DMARC record: two records at the same name makes DMARC invalid. The DMARC record generator builds a correct record, and the DMARC checker confirms what is live.
Platform-specific walkthroughs: Google Workspace DMARC setup and Microsoft 365 authentication. Once you reach enforcement, the next step is BIMI. If you send more than 5,000 messages a day to Gmail or Yahoo addresses, see the bulk sender requirements, which mandate at least a published DMARC record.
Frequently Asked Questions
Will p=reject break my email?
Not if every legitimate sender passes DMARC first. Reject only affects mail that fails authentication, so the work is identifying those senders in reports and fixing them before you tighten the policy.
Is p=none enough protection?
No. It collects data but takes no action on spoofed mail, so your domain can still be impersonated. Treat none as a temporary monitoring stage.
How long should I stay on each policy?
Two to four weeks at none and the same at quarantine is a sensible minimum, longer if you send monthly or quarterly campaigns. Move only when reports are clean, not when a calendar date arrives.
What does pct do in DMARC?
It applies the policy to only that percentage of failing messages, and the rest are handled at the next-lower policy. Use it to phase in quarantine and reject. Remember that BIMI requires pct=100.
Does DMARC affect email I receive?
No. DMARC is checked by the receiving server for mail claiming to be from your domain. Your DMARC record only governs how others treat mail using your domain name.
Can I set a different policy for subdomains?
Yes, with sp= in the parent record or by publishing a separate _dmarc record on the subdomain. A subdomain without its own record inherits the parent's policy.
Next step: Run the free DMARC checker to see your current policy, or request a free email audit. If you would rather have the enforcement rollout handled for you, see the email security setup service.