If you have set up DMARC on your domain, you have probably seen the p= tag and wondered what each value actually does. The difference matters a lot. The wrong policy can mean your legitimate emails get rejected, or that spoofed emails from your domain land in inboxes without any consequence.

Here is what each policy does and how to decide which one to use.

What DMARC does

DMARC tells receiving mail servers what to do when an email claiming to be from your domain fails authentication. An email fails DMARC when it fails both SPF and DKIM alignment checks.

The p= tag sets the policy for those failures.

p=none

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

This is the monitoring policy. When a message fails DMARC, nothing happens to it — it gets delivered normally. But you receive aggregate reports (via rua=) showing you who is sending email from your domain and what is passing or failing.

Use p=none when:

• You are setting up DMARC for the first time
• You want to understand your email traffic before enforcing anything
• You have third-party senders (CRMs, ESPs, support tools) that you need to authenticate first

p=none does not protect your domain from spoofing. Anyone can spoof your domain and the email will be delivered. The only benefit is visibility.

p=quarantine

v=DMARC1; p=reject; rua=mailto:

Emails that fail DMARC are rejected outright. They do not arrive. The sending server gets a bounce.

Use p=reject when:

• You have reviewed your DMARC reports and confirmed all legitimate email is passing
• You want the strongest protection against domain spoofing and phishing
• You understand that any misconfigured sender will start bouncing

p=reject is the goal. It is what Google, Microsoft, and most large domains use. It is what blocks phishers from impersonating your brand.

The right progression

The standard path is:

1. Start with p=none and add an rua= address to receive reports
2. Review reports over 2-4 weeks and identify all services sending as your domain
3. Make sure each service has SPF or DKIM configured correctly
4. Move to p=quarantine once you are confident in your legitimate traffic
5. Move to p=reject once you see no failures from legitimate senders

Skipping straight to p=reject without monitoring first is how organizations accidentally block their own transactional email.

Check your current DMARC record

You can look up your current DMARC record and see exactly what policy you are running with InboxGreen's free DMARC checker. It will also flag any syntax issues and show you whether SPF and DKIM are passing alongside it.

No login required.