Why p=none isn't enough

Publishing a DMARC record with p=none is a good first step — it gets you visibility into who's sending email on behalf of your domain. But it doesn't protect anyone.

Here's what p=none actually means: take no action.

When a message fails your DMARC checks under p=none, receiving mail servers log the failure and include it in their aggregate report to you. The message still gets delivered to the recipient's inbox. No filtering. No blocking. The recipient has no idea anything was wrong.

The spoofing problem

A threat actor who wants to impersonate your domain doesn't care about your DMARC record if it's set to p=none. They know their spoofed message will be delivered regardless. Your DMARC record is visible in public DNS — they can check it before they launch a phishing campaign.

p=none is a monitoring mode. It tells you what's happening. It doesn't stop anything.

The path to protection

The goal is p=reject. At that policy level, any message that fails DMARC authentication is rejected by the receiving server — it never reaches the inbox, never goes to spam, it's simply not delivered.

Getting there requires three things:

1. Know every service sending on your behalf

Before you can enforce, you need to be sure every legitimate service — your email platform, your helpdesk, your marketing tool, your e-commerce platform — is properly authenticated and appearing in your DMARC reports as passing.

If you enforce before you've done this, you'll block your own legitimate mail.

2. Fix authentication failures

Once you know your senders, check that each one is passing SPF and DKIM. Failing known senders need to be fixed — either by updating your SPF record, configuring DKIM signing, or both.

3. Move gradually

The recommended path is:

p=none → p=quarantine (pct=10) → p=quarantine (pct=100) → p=reject

The pct tag lets you apply your policy to a percentage of failing messages. Starting at 10% means only 10% of failing messages get quarantined while you monitor for any unexpected issues. Once you're confident, increase to 100%, then move to p=reject.

Sentura's enforcement readiness score tells you exactly where you are in this journey and what's blocking you from taking the next step.

How long does this take?

For a typical small to mid-sized organisation using Microsoft 365 with a handful of third-party services, the journey from p=none to p=reject typically takes 4-8 weeks:

• Week 1-2: Set up Sentura, add your domain, wait for reports to arrive, classify your senders
• Week 2-3: Fix any SPF or DKIM failures
• Week 3-4: Move to p=quarantine at 10%, monitor for issues
• Week 4-6: Increase to p=quarantine at 100%
• Week 6-8: Move to p=reject

Some organisations get there faster. Complex environments with many sending services take longer.

Further reading

• What is DMARC?
• Moving to enforcement
• Understanding your dashboard