DMARC p=none: Why You Should Move to Quarantine or Reject

What This Error Means

A DMARC policy of p=none means your domain publishes a DMARC record but does not enforce it. Receiving servers report authentication failures to you but still deliver unauthenticated email — including spoofed messages. Your domain is not protected. The fix: verify that all legitimate sending sources pass DMARC, then move to p=quarantine and eventually p=reject.

Use the mxio DMARC Checker on your domain to see your current policy.

The p=none policy collects valuable data. Aggregate reports (rua=, defined in RFC 7489 Section 7) show every IP address sending email as your domain, whether authentication passes or fails, and how much traffic each source generates. This data is essential during the initial DMARC deployment phase.

But monitoring is not protection. While you are watching, attackers can still send email as your domain, and receiving servers deliver it.

Why p=none Does Not Protect You

The purpose of DMARC (RFC 7489) is to tell receiving servers what to do with unauthenticated email. With p=none, the answer is "do nothing."

Spoofing still works. An attacker sends email with a From: address of ceo@yourdomain.com, and receiving servers deliver it to the recipient's inbox. The message fails SPF and DKIM (assuming the attacker does not control your DNS), but the p=none policy instructs the receiver not to act on that failure.

Phishing campaigns succeed. Business email compromise (BEC) attacks rely on spoofing executive email addresses. If your domain is on p=none, an attacker impersonates your CEO, CFO, or HR department with no technical barrier. The recipient's mail server knows the email is unauthenticated but has been told to deliver it anyway.

Reports are forensic, not preventive. DMARC aggregate reports show that spoofing is happening, but by the time you read the report (typically 24-48 hours later), the phishing campaign has already run.

Business Risks of Staying on p=none

Organizations that remain on p=none indefinitely face concrete risks:

The bulk sender requirements from Gmail, Yahoo, and Microsoft require at minimum p=none, but providers increasingly favor domains with enforcement policies. Moving to p=quarantine or p=reject improves spoof protection; deliverability gains depend on correct SPF/DKIM/alignment across all legitimate senders.

What to Check Before Moving to DMARC Enforcement

Moving to enforcement without preparation breaks legitimate email delivery. Before changing your DMARC policy, verify these items:

1. All Legitimate Sources Pass DMARC

Review your DMARC aggregate reports for at least 2-4 weeks. Every legitimate sending source should show consistent DMARC pass results. Use the mxio SPF Checker and mxio DKIM Checker to verify each source.

Common sources that are often missed:

• Marketing platforms (Mailchimp, HubSpot, Constant Contact)
• Transactional email (SendGrid, Amazon SES, Postmark)
• CRM systems (Salesforce, Zendesk, Freshdesk)
• Email security / filtering services (MailRoute, Mimecast, Proofpoint) that relay outbound mail
• Internal applications sending notifications
• HR and payroll systems (password resets, onboarding emails)
• Development and staging environments using production From: addresses

2. DKIM Is Configured for All Third-Party Senders

SPF alignment breaks when email is forwarded. DKIM alignment survives forwarding (as long as the body is not modified). Every third-party service that sends email as your domain should have custom DKIM (RFC 6376) signing configured with your domain in the d= tag. See DMARC Alignment Failure for detailed configuration steps.

3. SPF Record Is Valid

Use the mxio SPF Checker to verify your record against RFC 7208 and confirm:

• No PermError from too many lookups
• No multiple SPF records
• All sending IPs and services are included

If your SPF record is at or near the 10-lookup limit, consider SPF flattening or mxio's Managed SPF to keep the record under the limit automatically as you add new services.

4. Reporting Is Active

Confirm that rua= is configured and you are receiving and reviewing aggregate reports. You need this visibility during the enforcement rollout to catch problems quickly.

The DMARC Enforcement Progression Path

Moving from p=none to p=reject should be a gradual, controlled process. The pct= tag (defined in RFC 7489 Section 6.3) is your safety valve — it tells receivers to apply your enforcement policy to only a percentage of failing messages, treating the rest as p=none. See the DMARC Deployment Guide for the full process.

Phase 1: Quarantine at 25%

"v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com"

This applies quarantine (route to spam) to 25% of messages that fail DMARC. The other 75% are treated as if the policy were still p=none. Run this for 2-4 weeks and monitor:

• Are any legitimate emails being quarantined?
• Do aggregate reports show any new failing sources?
• Have users reported missing emails?

Phase 2: Quarantine at 100%

"v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com"

Remove the pct= tag (or set pct=100) to apply quarantine to all failing messages. Monitor for another 2-4 weeks.

Phase 3: Reject at 25%

"v=DMARC1; p=reject; pct=25; rua=mailto:dmarc-reports@yourdomain.com"

Reject is the final goal. At pct=25, only a quarter of failing messages are outright rejected. This catches serious spoofing while limiting blast radius if a legitimate source is misconfigured.

Phase 4: Reject at 100%

"v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com"

Full enforcement. All email that fails DMARC authentication is rejected. This is the end state that provides maximum protection against domain spoofing.

Monitoring During DMARC Enforcement

Each phase transition requires active monitoring:

Watch aggregate reports closely. When you move from p=none to p=quarantine, you see dmarc=pass counts stay the same but dmarc=fail messages now show a disposition of quarantine instead of none. If legitimate sources suddenly show failures, fix their authentication before proceeding.

Set up alerts. Domain health monitoring catches DMARC failures that indicate a misconfigured legitimate source rather than a spoofing attempt.

Communicate with stakeholders. Notify teams that send email as your domain (marketing, sales, support, engineering) before each policy change. They should report any delivery issues immediately.

Keep rollback easy. If problems arise, step back by changing the DMARC record to a lower enforcement level. DNS changes propagate quickly (minutes to hours depending on TTL).

When p=none Is Temporarily Acceptable

There are legitimate reasons to stay on p=none, but they should all be temporary:

• Initial DMARC deployment (2-4 weeks): You need time to discover all sending sources and fix authentication. See No DMARC Record Found for the initial setup guide.
• Major email infrastructure migration: If you are moving email providers or restructuring your sending infrastructure, stay on p=none until the migration is complete and verified.
• Onboarding many third-party senders: If you are configuring DKIM and SPF for many services simultaneously, p=none gives you time to get them all right.

In all these cases, set a deadline. Write it down. Put it on a calendar. Organizations that do not set deadlines tend to stay on p=none indefinitely, leaving their domain unprotected.

Prevention and Ongoing Monitoring

DMARC enforcement is not a set-and-forget configuration. New sending services get added, DKIM keys expire, and SPF records change. Continuous monitoring catches problems before they affect delivery or protection.

Use the mxio DMARC Checker to verify your current DMARC policy and get specific recommendations. If your record shows p=none and you have been monitoring for more than a month, it is time to begin the enforcement progression.

Set up domain health monitoring to monitor your DMARC configuration continuously. mxio alerts you the moment a legitimate sending source starts failing authentication — so you can fix it before it causes delivery problems during enforcement.

Related Issues

• No DMARC Record Found — Setting up DMARC from scratch
• Why Is DMARC Failing? — Troubleshooting authentication failures before enforcing
• DMARC Alignment Failure — When SPF/DKIM pass but DMARC fails
• Gmail Error 550 5.7.26 — What happens when enforcement blocks legitimate email
• Bulk Sender Requirements — Provider requirements that push toward enforcement