The road has three stops: p=none, p=quarantine, p=reject. You move on when your reports show that your real senders pass. On Basic and up, MonitorBase suggests each step only after 500 or more messages over at least 14 days of reports, with 98% passing to leave p=none and 99% for the later steps.
The three policies in one table
| Policy | What receivers do with mail that fails | What it's for |
|---|---|---|
p=none | Nothing changes. They send you reports | Learning who sends as you |
p=quarantine | Treat it as suspicious, usually the spam folder | A safe middle step |
p=reject | Refuse it | The goal: forged mail from your domain fails |
p=none on its own protects nothing. In May 2024 the FBI and NSA described spoofed mail that failed DMARC and still reached its target, because the domain was at p=none. It's where you start, and you leave it once you know your senders.
Stage 1: p=none, find every sender
v=DMARC1; p=none; rua=mailto:[the report address MonitorBase shows you]
Let the reports come in and watch the sending sources fill up. Then fix in this order:
- Your mailbox provider. Microsoft 365 or Google Workspace sends most of your mail. Turn on DKIM signing for your own domain in its admin centre, and make sure SPF includes it.
- Your newsletter tool. Mailchimp, Brevo and the like sign with their own domain until you set up DKIM for yours. Follow their domain authentication steps.
- The systems that send for you. Invoicing (such as e-conomic), the webshop, booking and CRM tools. Each must pass SPF or DKIM with your domain.
- Unknown senders. Find out who uses them. Approve them in the sender register, set them up, or reject them.
include: you add costs DNS lookups, and SPF stops working past 10. The SPF surveyor counts them, and this guide shows how to get under the limit.When 98% of 500+ messages over 14+ days pass, the next policy step card (Basic and up) suggests quarantine: first with pct=25, so it applies to a quarter of failing mail, then to all of it.
Stage 2: p=quarantine
v=DMARC1; p=quarantine; rua=mailto:[the report address MonitorBase shows you]
Change the policy in your DNS, or in the app if you use managed DMARC, and keep the rua= part. Mail that fails now goes to spam at most receivers, so a sender you missed shows up quickly: in the reports, and on Basic as an alert about falling compliance or a new sending source.
Fix stragglers as they appear. Rare senders matter here: a quarterly newsletter or a yearly reminder from your accounting system may only show up now.
When 99% pass over the same volume, the card suggests reject.
Stage 3: p=reject
v=DMARC1; p=reject; rua=mailto:[the report address MonitorBase shows you]
Receivers now refuse mail that fails DMARC for your domain. Keep the reports coming: a new tool, a DNS move or a web agency's edit can break a sender later. After p=reject covers what to watch.
How forwarding and mailing lists show up
Some failing mail in your reports is your own, sent on by someone else:
- Forwarding. A customer forwards your mail from their work address to a private one. The forwarding server isn't in your SPF record, so SPF fails. DKIM often survives, because the message itself is unchanged.
- Mailing lists. A list re-sends your message to its members and may add a footer or change the subject. That can break DKIM too.
In MonitorBase these show up as small sources with mixed results, often under the forwarder's name or as unknown. They are usually fine to leave alone. The 98% and 99% thresholds leave room for them.
If something breaks
Step back. Set the policy to the previous stop in your DNS, fix the sender, and move forward again when the card says so. Changes take effect as fast as your DNS updates.
For the use of pct= and a staged rollout plan in more detail, read Moving DMARC from p=none to p=reject.
Sources
- FBI, NSA and US Department of State, "North Korean Actors Exploit Weak DMARC Security Policies", 2 May 2024, ic3.gov/CSA/2024/240502.pdf.
- MonitorBase next policy step: thresholds as in the app (13 Nov 2026).