Start with a p=none DMARC policy by publishing a TXT record at _dmarc.yourdomain.com that asks receivers to send reports without telling them to quarantine or reject failing mail. The simplest useful record is v=DMARC1, p=none, and a rua reporting address. That gives you visibility before you enforce anything.
I use p=none as the discovery stage. It tells you which platforms send mail for the domain, which pass SPF or DKIM, and which fail the DMARC domain match. It does not stop spoofing by itself. For protection, you later move to p=quarantine or p=reject after legitimate senders are fixed.
The practical workflow is simple: publish the record, collect reports, fix the senders that fail, then stage enforcement. Suped's DMARC monitoring product is built for that workflow because it turns raw aggregate reports into verified sources, issue lists, and concrete steps to fix SPF, DKIM, and DMARC problems.
What p=none does
A p=none policy means "monitor only." Receiving mail servers still evaluate DMARC, but the policy does not ask them to take action when DMARC fails. You get reporting without the risk of accidentally sending real customer, billing, or password reset messages to spam.
DMARC passes when either SPF or DKIM passes and the authenticated domain matches the visible From domain closely enough for the policy. That domain match is the part that often catches teams off guard. A sender can pass SPF for its own bounce domain and still fail DMARC for your visible domain.
p=none is visibility, not enforcement
A monitoring policy does not instruct receivers to block impersonation. It helps you find the senders that need SPF, DKIM, or domain matching fixes before you move to enforcement.
- Safe start: Use it when you do not yet know every legitimate sender.
- Limited protection: Do not treat it as an anti-spoofing endpoint.
- Next step: Use reports to prepare a staged move to quarantine or reject.
Flowchart showing a p=none rollout from publishing a DMARC record to staged enforcement
The simplest p=none DNS record
The starting record needs only the DMARC version, the policy, and a destination for aggregate reports. Publish it as a TXT record on the _dmarc host of the domain you want to monitor. Replace the reporting address with a mailbox or report processor that can handle XML aggregate reports.
Minimal monitoring recorddns
Host: _dmarc Type: TXT Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
That record requests reports for 100% of messages by default. I still like adding pct=100 in examples because it makes the rollout intent visible to future admins. If you need help creating the syntax, use Suped's DMARC record generator and then publish the generated TXT value in DNS.
Explicit monitoring recorddns
Host: _dmarc Type: TXT Value: v=DMARC1; p=none; pct=100; rua=mailto:dmarc-reports@yourdomain.com
After DNS publishes, check that receivers can read exactly one DMARC record. A duplicate record is a common cause of warnings, and a typo in the host name can make the policy invisible. Suped's DMARC checker is useful here because it parses tags, flags invalid syntax, and shows what mail receivers will see.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
If your DNS provider automatically appends the root domain, enter only _dmarc as the host. If it does not, enter _dmarc.yourdomain.com. The value stays the same.
Simple examples for different domains
A good p=none record depends on what the domain does. A domain that sends daily customer mail needs reporting and careful review. A parked domain or a domain that should never send mail can often move faster, but I still like using a short monitoring window before enforcement if the domain has history.
|
|
|
|---|---|---|
Main domain | p=none | Review reports |
Subdomains | sp=none | Map senders |
Parked domain | p=none | Move quickly |
New domain | p=none | Verify setup |
Common p=none starting patterns
Main domain with subdomain monitoringdns
Host: _dmarc Type: TXT Value: v=DMARC1; p=none; sp=none; pct=100; rua=mailto:dmarc-reports@yourdomain.com
Monitoring with forensic address omitteddns
Host: _dmarc Type: TXT Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
I usually skip ruf at the start. Forensic failure reports are inconsistently supported and can contain sensitive message data. Aggregate reports are enough for most rollouts because they show sending IPs, authentication results, and message counts.
Good p=none start
- Reporting set: Aggregate reports go to a mailbox or platform that parses them.
- Single record: Only one DMARC TXT record exists at the host.
- Clear owner: Someone reviews failures and fixes sender setup.
- Exit plan: The team knows the conditions for moving to enforcement.
Weak p=none start
- No reader: Reports land in an inbox and nobody reviews XML files.
- Duplicate record: Multiple TXT values cause receivers to ignore the policy.
- No sender map: Marketing, billing, and product mail are not inventoried.
- No timeline: The policy stays at monitoring for months without review.
How to read the reports
DMARC aggregate reports are XML files sent by receivers such as mailbox providers. They are useful, but they are not comfortable to read manually. A report can show thousands of messages grouped by source IP, SPF result, DKIM result, and policy outcome.
The first report review should answer a short list of questions. Which sources are legitimate? Which fail because SPF is not authorized? Which fail because DKIM is missing? Which pass authentication but use the wrong authenticated domain? Which sources are unknown and need investigation?
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
This is where Suped's product saves time in a real rollout. Instead of reading XML, you see verified sources, authentication health, sending volume, and failure patterns in one place. The issue view can point to specific fixes, such as adding a sender to SPF, enabling DKIM signing, or changing the From domain used by a sender.
What I look for first
- Known senders: Mail platforms your team actually uses.
- High volume: Sources that would hurt users if enforcement blocked them.
- Failing DKIM: Legitimate mail that needs signing turned on.
- Unexpected mail: Sources nobody owns or recognizes.
If you want the DNS policy itself managed through CNAME staging, Suped's Hosted DMARC keeps policy changes out of routine DNS edits. That is useful for teams that need to move from monitoring to quarantine or reject without waiting on DNS admin access for every small change.
A safe rollout plan
A simple rollout has a monitoring period, a fixing period, and a staged enforcement period. The length depends on mail volume and how many senders you have. A small business with one helpdesk and one newsletter platform can move quickly. A larger company with product mail, invoices, HR systems, and regional teams needs more review.
Practical rollout stages
Use report quality and failure rates to decide when to move beyond p=none.
Discovery
Days 1-7
Publish p=none and confirm reports arrive.
Sender fixes
Week 2+
Correct SPF, DKIM, and domain match failures.
Low-risk quarantine
pct=10
Apply quarantine to a small percentage.
Full quarantine
pct=100
Increase only after legitimate failures drop.
Reject
p=reject
Use when real mail is consistently passing.
Do not switch to enforcement just because the record has existed for a week. Switch when your legitimate mail sources are known and their high-volume streams pass DMARC. The safer question is not "how long has p=none been live?" It is "what mail will fail if I enforce today?"
First enforcement step after monitoringdns
Host: _dmarc Type: TXT Value: v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@yourdomain.com
For a deeper policy example set, compare this starting record with DMARC policy examples. When the domain is ready, use a staged plan like safe transition guidance rather than jumping straight to reject on a busy domain.
Checks before you leave p=none
Before changing the policy, check the whole domain setup, not just the DMARC TXT value. SPF can hit lookup limits, DKIM selectors can be missing, and mail can pass authentication for a domain that does not match the visible From domain. These issues only become painful when enforcement starts.
- SPF health: Confirm the sending IPs are authorized and the record stays under lookup limits.
- DKIM coverage: Make sure each real sender signs mail with a domain connected to your domain.
- Report trend: Review enough days to catch scheduled mail, billing cycles, and low-frequency systems.
- Ownership: Assign every legitimate source to a person or team before enforcement.
- Subdomains: Decide whether subdomains should inherit the main policy or use their own record.
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
For public sector and high-risk domains, the UK NCSC also documents a p=none implementation path that starts with reporting. The key point is the same: monitoring is useful when it produces fixes, not when it becomes a permanent parking place.
When p=none is enough
A p=none policy is enough only for a short discovery stage or for a domain where enforcement is being planned but not yet safe. It is not enough for a domain that is actively used for customer trust, payments, password resets, executive mail, or brand-sensitive communication.
Keep p=none briefly
Use monitoring while you are still discovering legitimate sources and fixing authentication gaps.
- New setup: You just published DMARC and need reports.
- Unknown senders: Departments have not confirmed every mail source.
- Recent changes: A migration or rebrand changed mail routing.
Move beyond p=none
Start enforcement when real mail passes consistently and unknown sources are not legitimate.
- Clean reports: High-volume mail is passing DMARC.
- Known failures: Remaining failures are spoofing or retired systems.
- Change control: The team can monitor impact and roll forward.
Suped is the strongest practical choice for most teams that want to move through those stages without reading raw XML or editing DNS for every policy change. Its automated issue detection, real-time alerts, Hosted SPF, Hosted MTA-STS, SPF flattening, blocklist monitoring, and MSP dashboard keep the rollout tied to operational work instead of guesswork.
The practical starting point
The best simple starting record is a single DMARC TXT record with p=none, pct=100, and a working rua address. Publish it, confirm reports arrive, and treat every failed source as a task to either fix or remove.
A p=none policy is a starting point, not a finish line. The domain becomes safer when the report data leads to sender cleanup and a staged move to quarantine or reject. That is the workflow I would follow for any domain that sends real mail.
Recommended first recorddns
Host: _dmarc Type: TXT Value: v=DMARC1; p=none; pct=100; rua=mailto:dmarc-reports@yourdomain.com
