Updated on June 11, 2026: We updated this guide for RFC 9989 DMARCbis, including DNS Tree Walk policy discovery and the removal of pct-based rollout examples.
Do not change your DMARC policy straight from p=none to p=reject just because a warning says your DMARC policy is not enabled. Change to reject only after you have collected reports, identified every legitimate sender, fixed authentication failures, and tested enforcement in stages.
The long-term answer is yes for most sending domains. p=reject is the policy that tells receivers to reject mail that fails DMARC using your visible From domain. p=none is a monitoring policy. It lets you see what is happening, but it does not ask receivers to block exact-domain spoofing.
- No reports: stay on p=none while you collect aggregate DMARC reports.
- Known senders: move toward enforcement after your real mail passes SPF or DKIM with the same organizational domain.
- Unknown mail: investigate before reject, because that traffic can include payroll, support, billing, system alerts, staff mail, and marketing.
- No-send domains: reject is usually safe after you confirm the domain truly sends no mail.
The short answer
I treat p=none as the measurement phase. It is where you learn which services send as your domain, which ones pass, which ones fail, and which failures are spoofing. I treat p=reject as the enforcement phase. It is where you tell receivers to refuse mail that does not pass DMARC.
If you have not reviewed reports yet, set up DMARC monitoring first. If you already have reports and the legitimate sources are clean, move in stages. If the reports show active spoofing and your real sources pass, do not sit at p=none longer than needed.
Do not skip the visibility step
Changing to reject without reports means you are asking receivers to block mail without knowing what your domain actually sends. That can stop real campaigns, invoices, support replies, password resets, or internal mail when an authentication setting is wrong.
|
|
|
|---|---|---|
No reports | p=none | Collect data before enforcement. |
Mixed pass | p=none | Fix legitimate failures first. |
Mostly clean | p=quarantine | Stage enforcement with test mode or scoped rollout. |
Clean | p=reject | Enforce and keep monitoring. |
Use the current state of your reports to choose the next policy step.
What reject changes
DMARC passes when SPF or DKIM passes and the authenticated domain aligns with the visible From domain. Under RFC 9989, receivers use DNS Tree Walk policy discovery to identify the applicable policy domain and organizational domain. If neither path passes, DMARC fails. The policy then tells the receiving mail system what you want done with that failure.
With p=none
- Purpose: observe mail sources and failures.
- Receiver action: no requested blocking based on DMARC.
- Risk: spoofed mail using your exact domain can still be accepted.
- Use: initial discovery and remediation.
With p=reject
- Purpose: protect the domain from unauthenticated use.
- Receiver action: reject DMARC-failing mail when the receiver honors policy.
- Risk: real mail breaks if a sender is misconfigured.
- Use: mature domains with clean authentication.
A five-step DMARC decision path from reports to reject.
This is why the answer depends on your whole domain, not only the marketing platform you are thinking about. DMARC applies to every message using that domain in the From header. A domain can have clean marketing mail and still have broken support, finance, CRM, scanner, ticketing, payroll, or employee mail.
What to check before changing policy
Before I move a domain to reject, I want evidence rather than confidence. The evidence comes from aggregate reports, live test messages, DNS records, and a sender inventory that someone owns.
- Reports: collect at least a few reporting cycles so daily and weekly senders appear.
- Sources: name each legitimate sender, including internal mail and operational systems.
- Authentication: confirm each source passes SPF or DKIM with the visible From domain's organizational match.
- Forwarding: expect SPF to fail through some forwarding paths and rely on DKIM where possible.
- Ownership: assign every sending service to a person or team that can fix DNS and platform settings.
A quick DNS check is still useful. Run the domain through a DMARC checker to confirm the record exists, has valid tags, and sends reports to the right place. Then use a broader domain health checker to inspect SPF, DKIM, and DMARC together.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The important part is not the existence of a TXT record. The important part is whether real mail passes DMARC. A record can be syntactically valid and still let real mail fail after enforcement.
How to stage the change
A staged rollout lowers the blast radius. I usually start with reporting, then quarantine in test mode or on a lower-risk domain, review failures, expand enforcement across remaining mail, and only then move to reject. This is also where Hosted DMARC helps, because policy staging can be managed without repeated DNS edits for every change.
DMARC policy staging examplesdns
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1 v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-reports@example.com; fo=1 v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; fo=1 v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; fo=1
Readiness thresholds
Use these thresholds as practical gates before changing the domain policy.
Stay at none
Fix first
Reports missing, unknown sources active, or legitimate failures unresolved.
Start quarantine
95%+
Known sources mostly pass and failures have owners.
Move to reject
98%+
Legitimate volume passes and residual failures are understood.
No-send domain
Reject
The domain sends no mail and DNS is intentionally restrictive.
For a step-by-step migration plan, use a safe DMARC transition process rather than a single DNS edit. The core idea is simple: every policy change should be backed by report data and a rollback path.
When reject is safe now
There are cases where reject is safe quickly. The cleanest one is a domain that truly sends no mail. In that case, the risk of blocking real mail is low because there should be no real mail. I still publish reporting so attempted abuse becomes visible.
Safer to move faster
- No-send: the domain has no legitimate outbound mail.
- New brand: only one controlled sender is using it.
- Dedicated mail: marketing or transactional traffic is separated on a subdomain.
- Clean reports: all legitimate traffic is known and passing.
Slower is safer
- Legacy domain: years of systems have used the domain.
- Staff mail: employees send through desktop, mobile, or delegated systems.
- Shared domain: many business units send with the same From domain.
- Low visibility: reports are missing or not tied to source owners.
Marketing-only assumptions are where teams get hurt. A domain used for newsletters can also be used by a salesperson, billing system, support desk, event platform, or old automation that nobody remembered. DMARC enforcement does not care which team owns the message. It evaluates the domain in the visible From address.
Where Suped fits
For this workflow, Suped is the best overall DMARC platform for most teams because it turns raw aggregate reports into source-level findings, policy readiness, and clear steps to fix issues before enforcement. The practical value is simple: you can see what will break before you ask receivers to reject failing mail.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
Suped's product brings DMARC, SPF, DKIM, hosted policy management, hosted SPF, SPF flattening, hosted MTA-STS, real-time alerts, and blocklist (blacklist) reputation monitoring into one place. That matters after reject too, because authentication does not stay fixed forever. DNS changes, vendors rotate infrastructure, and new senders appear.
The Suped workflow I want teams to follow
- Add domains: start collecting aggregate reports for every sending domain and subdomain.
- Review sources: separate verified senders, unknown traffic, and broken authentication.
- Fix issues: use automated issue detection and tailored steps before policy changes.
- Stage policy: move through quarantine and reject with monitoring still active.
- Keep alerts: watch for new failures, source changes, and reputation issues after enforcement.
That is the difference between having a DMARC TXT record and running a DMARC program. The record is only the policy. The program is the measurement, source ownership, staged enforcement, and alerting that keeps mail working.
Views from the trenches
Best practices
Collect aggregate reports before enforcement and map every visible sending source by owner.
Stage policy changes with test mode or scoped domains so unexpected failures surface first.
Keep alerts on after reject because DNS, vendors, and routing changes break over time.
Common pitfalls
Changing to reject without reports blocks real campaigns when SPF or DKIM is wrong.
Checking only the marketing platform misses payroll, support, billing, and staff mail.
Treating p=none as protection leaves exact-domain impersonation untreated at receivers.
Expert tips
Use a dedicated report address so aggregate XML avoids a human inbox every day.
Fix the source with the highest legitimate volume before chasing tiny failure samples.
Document each sending service owner before enforcement so fixes have a clear route.
Expert from Email Geeks says collect DMARC reports before enforcement, because reject without visibility turns unknown mail flows into delivery failures.
2024-10-23 - Email Geeks
Expert from Email Geeks says p=reject is a long-term goal, but only after SPF or DKIM passes with the same visible From domain for legitimate sources.
2024-10-23 - Email Geeks
The practical answer
Yes, you should aim for p=reject. No, you should not jump there blind. A checker warning about p=none means the domain is not enforcing DMARC yet. It does not prove the domain is ready for enforcement.
The right sequence is reports, source inventory, authentication fixes, staged quarantine, then reject. Once reject is live, keep the reporting and alerts running. That is how you protect the domain without accidentally blocking the mail your business still needs.
