Your DMARC record says p=none. Here is exactly what that does.
You have a DMARC record. A checker confirmed it exists. It reads
v=DMARC1; p=none; ... and you want to know whether that means you are protected.
The short answer is that p=none is a monitoring setting: it asks receiving mail
servers to report forged mail to you and to keep delivering it.
sit at p=none — the single most common finding in our
2026 measurement of 522 agency-built sites, ahead of having no
DMARC record at all (34.1%). In the independent small-business sample it
is 34.9%. It is the most common state on the internet and
the one most often mistaken for being finished.
Free, no signup: what a stranger can already read about your domain
Before you plan the move to quarantine: this reads your live record and tells you which policy is published on your domain today - along with the three other values that carry dates.
Type a domain and get four checks in about ten seconds: whether anyone can send email in your name (SPF, DKIM and DMARC), how long your HTTPS certificate has left, when your domain registration expires, and whether the site answers over HTTPS rather than plain http. No email address, no account, nothing installed. It runs the same code our paid monthly report runs.
Open the free check on its own page → · We measured 604 domains: 72-83% had at least one finding
What p=none does
The p= tag is the policy: the instruction you give every receiving mail
server about messages that claim to be from your domain and fail authentication. There are
three values.
| Policy | What the receiver is asked to do | Effect on a forged invoice sent in your name |
|---|---|---|
p=none | Deliver it. Send an aggregate report to the address in rua. | Arrives in the inbox. You learn about it, in XML, days later. |
p=quarantine | Treat it as suspicious — in practice, the spam folder. | Out of the inbox. Recoverable if it was a false positive. |
p=reject | Refuse it at the door. | Never delivered. The sending server is told no. |
yourcompany.com publishes DMARC, but its policy is p=none — monitor only. It reports forged mail after the fact; it does not ask anyone to stop delivering it.
The sentence above is the wording our own free checker returns for this finding, reproduced here from the running code rather than retyped.
Why it exists, and why it is a stage rather than a setting
p=none is not a mistake, and it is genuinely the right place to start.
Publishing p=reject on day one is how a business breaks its own email: every
system that sends on your behalf and has not been authorised — the invoicing tool, the
booking form, the CRM, the newsletter platform, the accountant’s portal — gets refused
at the far end, and the failures are silent. p=none exists so that you can find
that list before it costs you anything.
The failure is not adopting it. The failure is stopping there. A
record at p=none gives you a green tick on most checkers, satisfies a
questionnaire that asks whether you have DMARC, and stops precisely nothing. Our data says
that is where a third of all domains have come to rest.
How to know when you are ready to move
Read the aggregate reports arriving at your rua address. They are
compressed XML; any free DMARC report reader will render them into a table. You are looking
for one thing: a list of every source sending as your domain, with every legitimate
one passing SPF or DKIM.
- For each sending source you recognise, authorise it — add it to SPF, or set up DKIM signing with that provider, or both. Both is better: DKIM survives forwarding and SPF does not.
- Watch until a full billing cycle has passed, so the monthly senders appear.
- When every source you recognise passes, and the only failures left are sources you do not recognise, you are looking at the forgery. Move the policy.
You do not have to jump. pct= applies the policy to a sample:
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomainThat asks receivers to quarantine a quarter of failing mail and deliver the rest, so a
sender you have missed shows up as a complaint rather than an outage. Raise it to 100, then
change p= to reject.
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain; fo=1Two things that quietly keep people at p=none
A subdomain policy you did not set. If you do not specify
sp=, subdomains inherit the main policy. When you move the main domain to
reject, every subdomain moves with it — including a marketing subdomain you
had forgotten sends mail. Set sp=none during the transition if you are unsure,
then remove it.
Alignment, not just authentication. DMARC does not ask whether SPF passed. It asks whether SPF passed for a domain that matches the one in the From line. A bulk sender can pass its own SPF perfectly and still fail your DMARC, because the envelope domain is theirs. This is the most common reason a source that “passes SPF” shows up as a DMARC failure, and the fix is usually a custom return-path or DKIM signing on your domain, which every serious provider supports.
What the numbers look like across 604 domains
We measured two independent samples from the outside, using only public DNS.
| Sample | Domains | At p=none | No DMARC | Neither enforces anything |
|---|---|---|---|---|
| Sites built by 141 web agencies | 522 | 186 (35.6%) | 178 (34.1%) | 364 (69.7%) |
| Independent small-business sweep | 83 | 29 (34.9%) | 41 (49.4%) | 67 (80.7%) |
Add the two middle columns together and you get the last one: in the agency sample 69.7% of domains, and in the small-business sample 80.7%, publish nothing that asks a receiving server to refuse a forged message. About half of that total is not absence. It is a record that exists, reports, and does nothing.
Neither sample is random, and both are point-in-time readings. Method and full limitations are in the study.
We sell a monthly monitor that watches this value. That is a real interest. It is also why the whole transition is written out above: if your record is one edit away from enforcing, make the edit.
Fix it yourself. Then find out when it breaks again.
Everything on this page is the whole fix, free, with nothing held back. What a DNS change cannot do is tell you when somebody edits it back, when a certificate runs out, or when a registration lapses — all three carry dates and none of them announce themselves. A3E’s perimeter monitor re-runs all four checks every month and emails you only when something moves: CA$99/month per site, cancel any time. A single report with no monitoring is CA$29.
Check a domain free See the monitorQuestions
Does p=none protect my domain from spoofing?
No. p=none asks receiving mail servers to send you aggregate reports and to deliver failing messages as normal. It gives you visibility, not enforcement.
Why would anyone use p=none then?
Because it is the safe first stage. It reveals every system sending as your domain without being authorised, which is the list you need before enforcement can be turned on without breaking your own mail.
How long should I stay at p=none?
Long enough for a full billing cycle to pass so monthly senders appear in the reports, and until every source you recognise passes SPF or DKIM. For most small businesses that is two to four weeks.
What is the difference between p=quarantine and p=reject?
Quarantine asks receivers to treat failing mail as suspicious, which in practice means the spam folder, so a mistake is recoverable. Reject asks them to refuse the message outright, so it is never delivered at all.
Can I apply a policy to only part of my mail?
Yes. The pct= tag applies the policy to a percentage of failing messages, for example p=quarantine; pct=25. It lets a sender you have missed surface as a complaint rather than an outage.
The other five in this set
No DMARC record found: what it means and the record to publish
DMARC record published but invalid: why receivers discard it
No SPF record found: the record to publish, and why SPF alone is not enough
Gmail 550-5.7.26: what it means and the records that fix it
SPF permerror — too many DNS lookups, and how to get back under ten
The measurement behind every number on this page: 604 domains, method and limitations
Every figure on this page is generated from the stored raw measurement files behind our 604-domain study (522 agency-built sites measured 2026-08-20, 83 independent domains measured 2026-08-01), and the quoted finding wording is read out of the running checker at build time. An automated control re-asserts both against this live page on every operating cycle; if either changed and this page did not, it fails. Generated 2026-09-05T23:34:13Z.
← Back to all articles