How to Fix DMARC p=none

A DMARC p=none policy is a common security-scan finding, and it means your domain is watching spoofed email go by without stopping any of it. The p=none setting tells receiving servers to report on messages that fail authentication but to deliver them anyway. It is a useful starting point, but a domain that never moves past it gets no real protection. This guide explains how to fix DMARC p=none and reach an enforcing policy safely.

If you are new to the standard, our explainer on what DMARC is covers the fundamentals first.

Why DMARC p=none is not enough

With p=none in place, an attacker can still send phishing email using your exact domain and it will land in inboxes as normal. The policy generates reports, which is valuable, but reports alone do not block anything. The only settings that actually stop spoofing are p=quarantine and p=reject. Leaving DMARC at p=none is like installing a camera on an unlocked door: you can see the intruder, but nothing keeps them out.

Step 1: Collect and read your reports

Before tightening anything, make sure your record includes a rua address so you receive aggregate reports. Give it a couple of weeks to gather data. These reports list every source sending mail as your domain, which is exactly what you need to avoid blocking your own legitimate email when you enforce.

Step 2: Authenticate every legitimate sender

Work through the reports and confirm that each genuine source, your mail server, marketing platform, invoicing tool and support desk, passes SPF or DKIM with proper alignment. This usually means updating your SPF record and enabling DKIM signing on each service. Alignment is the key: the authenticated domain must match your visible from address. Do not raise the policy until every real sender passes.

Step 3: Move to quarantine, gradually

Once your genuine mail is clean, change the policy from p=none to p=quarantine. You can ease into it using the pct tag, applying the policy to a percentage of mail first, for example twenty-five percent, then increasing it as you gain confidence. Quarantine sends failing mail to spam rather than deleting it, so any surprise is recoverable.

Step 4: Move to reject

When quarantine has run cleanly and your reports show only spoofers failing, raise the policy to p=reject. Now receiving servers refuse forged mail outright, and your domain can no longer be used for convincing impersonation. This is the destination that fixing DMARC p=none is aiming for.

Watch out for these pitfalls

• Email forwarding can break SPF, so lean on DKIM, which survives forwarding, for reliable authentication.
• Forgotten third-party senders are the most common cause of legitimate mail being blocked. The reports exist to catch them.
• Subdomains inherit your policy unless you set a separate sp tag, so make sure they are covered too.

How long does it take to fix DMARC p=none?

For most small and medium sites the whole journey from p=none to p=reject takes a few weeks, and the time is spent gathering data rather than making changes. Plan on roughly one to two weeks of collecting aggregate reports so you can see every service that sends mail as your domain, then a week or two at quarantine to confirm nothing legitimate is caught, before you finally switch to reject. Larger organisations with many marketing tools, regional offices and third-party senders may need a month or two, simply because there are more sources to authenticate and align. The pace is entirely under your control through the pct tag, so there is never a reason to rush the final step and risk blocking real email. The important thing is to keep moving; the danger is not going slowly, it is stopping at p=none and treating the reports as if they were protection.

Confirm the fix with a scan

After you enforce, verify that the change is live and correct. Run a security scan with EzyAudit AI and check that your DMARC policy now reads quarantine or reject and that SPF and DKIM support it. The report explains each result in plain language so you know your domain is genuinely protected. You can review every check on the features page, and the full standard is documented in IETF RFC 7489.

Fixing DMARC p=none is what turns email authentication from a report into real protection. Scan your website now to see your current policy and what to change next.