Does Your DMARC Record Actually Protect You? The p=none Problem

If you publish a DMARC record with p=none, your domain is not protected. p=none is a monitoring policy. It tells receiving mail servers to do nothing when an email fails DMARC checks. The only thing p=none gives you is reports.

That is the misconception this article addresses. Organizations across the internet have published v=DMARC1; p=none; rua=mailto:reports@example.com and believe they have implemented email security. They have not.

What Does DMARC p=none Actually Do?

DMARC has three policy tags that control what happens when an email fails DMARC alignment:

• p=none: No action taken. The receiving server delivers the message regardless. You receive aggregate reports only.
• p=quarantine: The receiving server marks suspicious mail as junk. It goes to the spam folder, not the inbox.
• p=reject: The receiving server refuses the message outright. It never reaches the recipient.

A record with p=none sits at the bottom of that list. It is purely observational. Think of it as installing a security camera that records everything but never sends an alert and cannot lock the door.

The record tells receiving servers who to send aggregate reports to. Those reports show you which IPs are sending email that appears to come from your domain, whether they are passing or failing DMARC, and which sources are not aligned. But the emails still arrive.

Why p=none Does Not Stop Email Spoofing

Here is the flow when an attacker sends a spoofed email:

1. An attacker sends an email that appears to come from your domain, such as billing@yourcompany.com.
2. The receiving server checks SPF. The attacker's mail server IP is not in your SPF record, so SPF fails.
3. The receiving server checks DKIM. The attacker did not sign the message with your DKIM key, so DKIM fails.
4. The receiving server checks DMARC alignment. Neither SPF nor DKIM is aligned, so DMARC fails.
5. The receiving server reads your DMARC policy: p=none. It delivers the message anyway.

The attacker did not beat your security. Your policy told the receiver to ignore the failure. Every check worked correctly and the spoofed email still arrived because p=none allows it.

A concrete example: you run a small business. You publish p=none to monitor your email sources before going to full enforcement. An attacker sends a fake invoice to one of your vendors, appearing to come from your domain. Your vendor's mail server checks DMARC, sees the failure, reads your p=none policy, and delivers the fake invoice to accounts payable. Your reports will show the failure. You will not stop it.

The Decoration Problem

The email security community has a term for this: a DMARC record that does not enforce is decor. It looks like security. It is not.

The counterintuitive risk: publishing an explicit p=none record tells the world your domain sends legitimate email and has an email security policy. Attackers can use this to their advantage.

When you publish p=none, your aggregate reports confirm which IPs are legitimate senders for your domain. That report data is valuable to someone mapping your infrastructure. A determined attacker can:

• Confirm your domain is active for email
• Identify senders that may not have strict alignment
• Craft convincing spoofed emails using what they learn from your report data
• Target your vendors or customers with impersonation attacks

This does not mean p=none is useless. It means p=none without a plan to move to enforcement is a half-measure that can create a false sense of security. The record announces your domain to the world without actually protecting it.

How to Move from p=none to Actual Protection

The path from decoration to enforcement has five steps. Each step takes time and attention.

Step 1: Review your aggregate reports.

Before changing anything, understand what is currently sending mail using your domain. Your rua reports show every source that appears to come from you, aligned or not. Identify your legitimate senders: your mail server, any third-party email services you use, any marketing or transactional email platforms.

Step 2: Fix SPF and DKIM alignment for every legitimate sender.

If a legitimate sender is failing DMARC alignment, fix it before moving to enforcement. The most common causes are:

• SPF alignment issues where the HELO/EHLO domain does not match the From domain
• DKIM signing by a selector domain that does not match your From domain
• Third-party senders that have not been configured for DMARC alignment

Step 3: Set your policy to p=quarantine as a trial.

Change your DMARC record from p=none to p=quarantine. This tells receiving servers to move suspicious mail to the junk folder instead of delivering it to the inbox. It is a gentler first step than reject.

Step 4: Monitor for 2 to 4 weeks using aggregate reports.

During this period, watch your reports for legitimate mail that starts landing in quarantine. If a vendor or platform you use starts failing DMARC, fix it now, while the consequences are manageable. This is where most organizations discover hidden mail sources they forgot about.

Step 5: Switch to p=reject when the reports are clean.

When you see zero legitimate failures for two consecutive weeks, change p=quarantine to p=reject. Your domain now has full DMARC enforcement.

How DMARCFlow Helps During the Transition

During the p=none to p=quarantine transition, you need to know immediately when legitimate mail starts failing. Waiting for weekly aggregate reports means discovering problems days after they start.

DMARCFlow monitors your aggregate reports in real time and alerts you when authentication failures occur. When a legitimate sender starts failing DMARC during the transition, you find out within minutes, not days. That speed matters: the faster you catch a failing legitimate source, the faster you can fix it before switching to p=reject.

If you are moving from p=none to enforcement, real-time monitoring turns a risky guess into a controlled rollout. DMARCFlow delivers alerts on DMARC failures within minutes of them occurring, so you catch alignment problems before they affect recipients when you switch to p=reject.

Frequently Asked Questions

Does p=none protect against spoofing?

No. p=none enforces nothing. It only requests aggregate reports. Spoofed emails that fail DMARC are still delivered when your policy is p=none.

Can I use p=none permanently?

You can, but it gives you no actual protection. p=none is useful as a monitoring phase before enforcement. Staying at p=none permanently means you are tracking a problem without solving it.

What happens when I change from p=none to p=quarantine?

Receiving servers will start placing suspicious mail in the junk folder instead of delivering it to the inbox. Some legitimate mail may also be quarantined if it is not properly aligned. This is why monitoring during the trial period is critical.

How long should I stay at p=quarantine before moving to p=reject?

A minimum of two to four weeks is a reasonable starting point. Extend it if you are still seeing legitimate failures. Do not move to p=reject until your aggregate reports show no legitimate sources failing DMARC.

Will p=reject block all spoofed emails?

p=reject gives receiving servers instruction to refuse messages that fail DMARC alignment. It is the strongest available protection. No email security measure is 100 percent, but p=reject stops the vast majority of spoofing attempts that rely on domain impersonation.