DMARC None Policy

What p=none means

The p=none policy tells receiving mail servers to take no action on emails that fail DMARC authentication. Failing emails are delivered to the recipient's inbox just like any other email. The "none" policy only enables reporting — it does not block, quarantine, or flag any messages.

v=DMARC1; p=none; rua=mailto:[email protected]

This is the starting point of the DMARC deployment journey. It lets you collect data about who is sending email as your domain before you start enforcing a policy. However, staying on p=none indefinitely leaves your domain completely unprotected.

⚠️

p=none provides zero protection. With this policy, an attacker can send emails pretending to be from your domain, and they will be delivered normally to recipients. DMARC reports will show the spoofing activity, but nothing will stop it. Think of it like a security camera with no guards — you can see the break-in, but you can't prevent it.

Why monitoring alone isn't enough

Having p=none is better than having no DMARC record at all, because at least you receive reports. But it has serious limitations:

🚫

No spoofing prevention

Attackers can send phishing emails from your domain with no consequences. Recipients receive and trust these emails because they appear to come from you.

📉

Reputation damage

When spoofed emails are used for phishing or spam, your domain's reputation suffers. Email providers may start flagging legitimate emails from your domain as suspicious.

📧

Deliverability impact

Google, Yahoo, and Microsoft increasingly require enforced DMARC policies for bulk senders. A p=none policy may affect your deliverability as a sender.

⚖️

Compliance gaps

Many industry standards and regulations (PCI DSS, NIST, government mandates) require enforced DMARC policies, not just monitoring. A p=none policy may not meet compliance requirements.

The DMARC deployment journey

DMARC is designed to be deployed gradually. The path from no protection to full enforcement follows a clear progression:

Phase 1: p=none (You are here)

Monitor only. Collect reports to understand your email ecosystem. Identify all legitimate senders and unauthorized sources. Duration: 2–4 weeks minimum.

Phase 2: p=quarantine

Moderate enforcement. Failing emails are sent to spam/junk. Start with a low pct value and increase gradually. Duration: 2–4 weeks.

Phase 3: p=reject (Goal)

Full enforcement. Failing emails are blocked entirely. Maximum protection against domain spoofing. This is where every domain should ultimately be.

💡

Don't stay on p=none forever. The monitoring phase is meant to be temporary — typically 2 to 4 weeks. Set a deadline for yourself to move to p=quarantine. Many organizations deploy p=none and forget about it for months or years, leaving their domain unprotected the entire time.

Setting up DMARC reporting

Before you can progress beyond p=none, you need to understand your email ecosystem. DMARC reporting gives you that visibility through two mechanisms:

Aggregate reports (rua)

Aggregate reports are the most important. They are XML files sent daily by receiving servers, containing summary data about all emails received from your domain. To enable them, include a rua tag in your DMARC record:

v=DMARC1; p=none; rua=mailto:[email protected]

You can specify multiple addresses by separating them with commas:

v=DMARC1; p=none; rua=mailto:[email protected],mailto:[email protected]

Forensic reports (ruf)

Forensic reports provide details about individual emails that fail DMARC. They are less commonly supported by receivers due to privacy concerns, but can be useful for investigating specific failures:

v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1

The fo=1 tag tells receivers to send a forensic report whenever either SPF or DKIM fails (not just when both fail, which is the default).

💡

Use a DMARC reporting service. Raw aggregate reports are compressed XML files that are difficult to read manually. Services like Postmark DMARC (free), dmarcian, Valimail, and EasyDMARC parse these reports into clear dashboards showing which sources are passing and failing.

Step-by-step: upgrade to quarantine

After collecting and analyzing reports for 2–4 weeks, you should have a clear picture of all sources sending email as your domain. Here's how to move to p=quarantine:

1

Audit your sending sources

Review your DMARC reports and create a list of every server that sends email using your domain. Identify which are legitimate (your mail server, marketing platform, CRM, etc.) and which are unauthorized.

2

Fix SPF for all legitimate sources

Make sure every legitimate sending service is included in your SPF record. Add their IP addresses or include: mechanisms as documented by each service.

v=spf1 include:_spf.google.com include:sendgrid.net include:mail.zendesk.com -all

3

Configure DKIM for all legitimate sources

Set up DKIM signing with your domain for every sending service. This is critical because DKIM survives email forwarding while SPF does not.

4

Verify everything passes

Send test emails from each service and check that they pass both SPF and DKIM alignment. Review one more week of DMARC reports to confirm all legitimate sources pass.

5

Update to p=quarantine with a low pct

Start by applying quarantine to only a small percentage of failing emails. This limits the impact if you missed a legitimate source.

v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]

6

Increase pct gradually to 100

Over 2–4 weeks, increase the percentage: 10% → 25% → 50% → 100%. Monitor reports at each level for any legitimate failures.

v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]

Before and after

Stage	DNS record at `_dmarc.example.com`
Current (none)	`v=DMARC1; p=none; rua=mailto:[email protected]`
Transition (partial quarantine)	`v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]`
Full quarantine	`v=DMARC1; p=quarantine; rua=mailto:[email protected]`

Step-by-step: upgrade to reject

Once you're running p=quarantine at 100% with no legitimate email failures, the final step is to move to p=reject for maximum protection.

1

Confirm all sources pass at quarantine

Review at least 2 weeks of DMARC reports while at p=quarantine; pct=100. Verify that no legitimate emails are being quarantined. If any are, fix their SPF/DKIM configuration first.

2

Switch to reject with a low pct

Change the policy to reject but apply it to only a small percentage initially:

v=DMARC1; p=reject; pct=25; rua=mailto:[email protected]

3

Increase to full reject

Gradually increase to 100% over 1–2 weeks. Your final record:

v=DMARC1; p=reject; rua=mailto:[email protected]

💡

The full journey typically takes 6–8 weeks. Plan for approximately 2–4 weeks of monitoring at p=none, 2 weeks of gradual quarantine enforcement, and 1–2 weeks of gradual reject enforcement. Larger organizations with many sending services may need more time.

Start protecting your domain today

Domain Guarddog monitors your DMARC policy progression and guides you from p=none all the way to p=reject.

Get Started Free

On this page