DMARC p=none is not protecting you. Here is what it actually does

Here's a scenario that plays out often enough to be a pattern, not a one-off: a business checks whether they have a DMARC record, finds they do, and assumes that means their domain is protected from being used to send phishing emails. What they don't check is what the policy on that record is actually set to do. It's set to p=none, which means it monitors and reports, but takes no action. Emails sent from someone impersonating that domain continue to arrive in inboxes unchallenged.

DMARC with p=none is one of the most common findings on a scan of a small business domain. It looks like a pass on a surface-level check. It isn't.

What the p= value in a DMARC record actually controls

A DMARC record has three possible policy settings, set by the p= tag. Each one tells receiving mail servers what to do when an email claims to be from your domain but fails authentication checks.

p=none means do nothing. Log the failure, send a report if reporting is configured, but deliver the email anyway. This is an observation mode, useful when you're first setting up DMARC and want to understand your email flows before enforcing anything. It is not protection.

p=quarantine means move the failing email to the recipient's spam folder. It's a softer enforcement that reduces the chance of a spoofed email being read without blocking it entirely.

p=reject means refuse delivery of any email that fails authentication. This is the setting that actually stops your domain being used to send phishing emails to other people. It's also the setting Cyber Essentials and most serious email security guidance point toward as the end goal.

Why so many businesses are stuck on p=none

p=none is where almost everyone starts, and it's the right place to start. When you first implement DMARC, you don't yet know whether all your legitimate email flows, your CRM, your invoicing tool, your marketing platform, are properly authenticated. Moving straight to p=reject without that picture risks blocking legitimate emails, which is a problem worth taking seriously.

The issue isn't starting at p=none. It's staying there. Moving from p=none to p=quarantine to p=reject requires reviewing the DMARC reports that p=none generates, identifying any legitimate sending sources that need fixing, and then tightening the policy once you're confident everything genuine will pass. That process takes some time and attention, and for most small businesses it never happens because nobody has it on their radar to complete.

How to check where your DMARC policy currently sits

Your DMARC record is a TXT record in your DNS, published at _dmarc.yourdomain.com. You can look it up through any DNS lookup tool, or Olimpio's scan will surface it alongside its current policy setting and flag if you're sitting at p=none rather than p=quarantine or p=reject.

The record itself will look something like v=DMARC1; p=none; rua=mailto:reports@yourdomain.com. The p= value is the thing to focus on. If it says none, you have DMARC set up but not enforced.

Moving from p=none to enforcement

The path from p=none to p=reject runs through your DMARC reports. If you have rua= set in your record pointing to an email address or a reporting service, you'll be receiving aggregate reports showing which sources are sending email claiming to be from your domain and whether they're passing authentication. Reading those reports, or using a tool that interprets them for you, tells you whether there are legitimate sending sources you'd block if you tightened the policy.

Once you're confident your legitimate email flows are all authenticated and would pass, moving to p=quarantine first, then to p=reject after a settling period, is the sensible path. Most businesses that complete this process find it takes a few weeks of attention rather than months.

Frequently asked questions

If I have p=none, can someone send emails pretending to be my business right now? Yes. p=none instructs receiving mail servers to take no action on emails that fail authentication, so a spoofed email from your domain will be delivered exactly as if it were legitimate.

Will moving to p=reject affect my own emails going out? Only if some of your legitimate sending sources aren't properly authenticated. That's why reviewing reports before tightening the policy matters — you want to fix those sources first, not discover them by blocking your own email.

How long should I stay at p=none before moving to p=quarantine? Long enough to understand your email flows from the reports, typically a few weeks, though businesses with simple email setups sometimes move faster once they've confirmed everything legitimate is passing.

Does p=quarantine actually stop spoofed emails, or just move them to spam? It moves them to spam rather than the inbox, which significantly reduces the chance of them being acted on but doesn't prevent delivery entirely; p=reject is the setting that prevents delivery.

Do I need a specialist to do this, or can a non-technical business owner manage it? The report interpretation is the hardest part; for businesses with straightforward email setups using a single provider like Google Workspace or Microsoft 365, the process is often manageable without specialist help.

Run a free scan of your domain and your CE Readiness checklist will show your current DMARC policy setting alongside everything else that needs addressing before an assessor asks: olimpio.io/free-scan