p=none Is Where Deliverability Programs Stall. Here Is How to Move Past It.

p=none Is Where Deliverability Programs Stall. Here Is How to Move Past It.

DMARC has three policy levels. Many brands that have a DMARC record in place are sitting at the first one, and they have been sitting there for months or years. p=none technically satisfies the Google and Yahoo 2025 bulk sender requirements. You published a record, you pass the compliance check, and your emails continue to deliver. What you have not done is protect your domain from being spoofed by senders you did not authorise.

That gap between "technically compliant" and "actually protected" is where deliverability programs stall. The path from p=none to p=reject requires work, but it is structured work with a clear sequence. This article walks through exactly what each policy level does, why many brands get stuck at the first, and the step-by-step process to move through all three without breaking legitimate mail in transit.

Why This Matters

Domain spoofing is the attack that DMARC exists to block. Without a policy that enforces action on failing mail, anyone can send email that appears to come from your domain. Your customers receive what looks like an email from your brand, except it is a phishing attempt, a scam, or a spam blast from an infrastructure you have no visibility into.

Your domain reputation takes damage from mail you did not send. Your customers lose trust in emails that look like yours. And you have no mechanism to stop it because your DMARC policy instructs receiving servers to do nothing about it except file a report.

The Google Sender Guidelines 2025 and the Yahoo Sender Requirements 2025 both mandate a DMARC record for bulk senders at any policy level. This pushed many brands to publish their first DMARC record in 2024 and early 2025. What the requirements did not mandate is moving past p=none, which is the minimum that satisfies the check. In my audits, brands that implemented DMARC in response to the Google and Yahoo announcement often stopped at p=none and have not reviewed their aggregate reports since.

The Full Breakdown

DMARC builds on top of SPF and DKIM. To understand what each policy level does, you need to understand what a DMARC failure actually means. An email fails DMARC when it fails both SPF alignment and DKIM alignment for the domain in the From: header. SPF alignment means the authenticated sending domain matches the domain in the From: header. DKIM alignment means the domain in the DKIM signature matches the domain in the From: header. A single pass on either SPF or DKIM is sufficient for DMARC to pass. DMARC only fails when both fail.

With p=none, a DMARC-failing email delivers to the inbox without obstruction. The receiving mail server checks DMARC, finds a failure, and then does nothing about it except send an aggregate report to the address specified in your rua tag. Those reports are XML files that tell you which IP addresses are sending mail that claims to be from your domain, how much of that mail is passing or failing authentication, and from which sending sources. p=none is a monitoring tool. It is not a protection mechanism.

p=quarantine changes the outcome for failing mail. Instead of delivering to the inbox, mail that fails DMARC is routed to the spam or junk folder. It still reaches the recipient. It still has the potential to damage your brand and mislead your customers. But the delivery path is degraded, and the probability of someone acting on it drops substantially.

Quarantine is the right intermediate step because it reduces the blast radius of spoofed mail while you continue to verify that all your legitimate sending sources are properly authenticated.

p=reject is the destination. Failing mail is rejected at the server level. It never reaches any folder, inbox or spam. This is complete protection against domain spoofing for properly authenticated rejection. The risk in jumping to p=reject without preparation is that if any legitimate sending source — a transactional email provider, a CRM, a third-party tool sending on behalf of your domain — is not properly authenticated, its mail will be blocked entirely. That is why the path from p=none to p=reject goes through a structured authentication audit rather than a direct flip of the policy tag.

Step-by-Step Implementation

1. Publish your DMARC record at p=none with aggregate report delivery configured.
   
   What: Add a TXT record to your DNS at _dmarc.yourdomain.com with the value v=DMARC1; p=none; rua=mailto:reports@yourdomain.com. The rua tag is where aggregate reports are sent. Use a real inbox that someone monitors. If you do not want to manage raw XML, route reports through a DMARC analysis tool (Postmark's free analyser, Dmarcian, Valimail) that parses them into readable summaries.
   Why: Before you can enforce any policy, you need a complete picture of every source sending mail with your domain in the From: header. p=none gives you that data without risk to legitimate mail delivery.
   Common mistake: Omitting the rua tag. A DMARC record without a report destination is monitoring with no output. You will never know what the reports would have shown because you have nowhere to receive them.

2. Run on p=none for 30 days and read your aggregate reports.
   
   What: Let a full month of sending data accumulate in your aggregate reports. Review the reports to identify every IP address or sending source that is sending mail from your domain. You are looking for three categories: sources you recognise and have authenticated, sources you recognise but have not fully authenticated, and sources you do not recognise at all.
   Why: A 30-day window captures the full range of your sending infrastructure, including tools that may send infrequently — password resets, transactional notifications, quarterly digests. A shorter observation window risks missing a legitimate source and blocking it when you move to enforcement.
   Common mistake: Looking at reports once and declaring the source list complete. Aggregate reports are delivered daily or weekly depending on the receiving mail server. Review them at the end of the 30-day window, not the beginning, and consolidate across the full period.

3. Authenticate every legitimate sending source.
   
   What: For each source identified in your aggregate reports that you authorise to send mail from your domain, verify that SPF and DKIM are correctly configured. For your ESP (Klaviyo, Mailchimp, Braze, or equivalent), this typically means verifying domain authentication inside the platform settings. For transactional mail (SendGrid, Postmark, Amazon SES), check that your sending domain is authenticated with a valid DKIM key and that your SPF record includes the provider's sending IPs or mechanism.
   Why: Moving to p=quarantine or p=reject before authenticating every legitimate source will block or quarantine mail from those sources. The only way to enforce DMARC safely is to ensure that every source you want to pass authentication actually does pass it.
   Common mistake: Assuming that because your ESP sends email successfully, it is DMARC-aligned. Successful delivery and DMARC alignment are not the same thing. Check your aggregate reports specifically for DMARC pass/fail status per source, not just delivery status.

4. Move to p=quarantine, initially with pct=10 or pct=25.
   
   What: Update your DMARC record to v=DMARC1; p=quarantine; pct=10; rua=mailto:reports@yourdomain.com. The pct tag tells receiving mail servers to apply the quarantine policy to only 10 percent of failing mail. The other 90 percent still delivers as if p=none is in effect. Increase pct gradually: 10 to 25 to 50 to 100 over two to four weeks.
   Why: Gradual rollout via the pct tag is a safety mechanism. If there is a legitimate source you missed during the authentication phase, the partial rollout limits the damage from blocking its mail to a fraction of sending volume, giving you time to identify and fix the issue before it affects all delivery.
   Common mistake: Jumping directly to pct=100 on the first quarantine update. The pct tag exists precisely to allow staged enforcement. Use it. The time cost of a staged rollout is two to four weeks. The cost of blocking a critical transactional mail source is customer-facing delivery failures.

5. Verify quarantine-phase reports, then move to p=reject.
   
   What: Monitor aggregate reports through the quarantine phase at each pct increment. Look for any legitimate sources appearing in the failing mail category. Once you reach pct=100 quarantine with no legitimate sources failing, update the record to v=DMARC1; p=reject; pct=100; rua=mailto:reports@yourdomain.com. Use the same gradual pct ramp if you want the additional safety net.
   Why: p=reject at pct=100 is full enforcement. Failing mail is blocked at the server. There is no recovery path for a sender that is blocked by reject policy except fixing their authentication. Confirming a clean quarantine phase before stepping to reject gives you confidence that the only mail being blocked is mail you do not authorise.
   Common mistake: Treating p=reject as a set-and-forget final state. New sending tools get added to the stack. Subdomains get spun up. Acquisitions add new infrastructure. Review DMARC aggregate reports quarterly to catch new unauthenticated sources before they become a problem.

6. Set up forensic reports (optional but useful for investigating specific failures).
   
   What: Add an ruf tag to your DMARC record: ruf=mailto:forensic@yourdomain.com. Forensic reports contain redacted message-level data about individual DMARC failures, including headers that can help identify where failing mail is originating. Not all mail servers send forensic reports (Gmail does not by default), but those that do provide more granular detail than aggregate reports.
   Why: When investigating a specific spoofing campaign or a stubborn unidentified source in your aggregate data, forensic reports give you message-level context. Aggregate reports show patterns. Forensic reports show instances.
   Common mistake: Routing forensic reports to the same inbox as aggregate reports without a filtering rule. Forensic report volume can be high during active spoofing attempts. Keep them in a separate inbox or folder so they do not bury your aggregate report summaries.

The Framework

Use this decision tree when assessing or building a DMARC implementation. Each branch represents the correct next action given your current state.

DMARC POLICY DECISION TREE
============================

START: Does a DMARC record exist at _dmarc.yourdomain.com?
|
+-- NO  --> Publish p=none with rua= configured. Start 30-day observation.
|
+-- YES --> What is the current policy?
            |
            +-- p=none
            |     |
            |     +-- Is rua= configured and are reports arriving?
            |           |
            |           +-- NO  --> Add rua= tag immediately. Restart observation.
            |           |
            |           +-- YES --> Have you reviewed 30+ days of aggregate reports?
            |                       |
            |                       +-- NO  --> Wait. Review at 30 days.
            |                       |
            |                       +-- YES --> Are all sending sources authenticated?
            |                                   |
            |                                   +-- NO  --> Authenticate each source.
            |                                   |          Then step to quarantine pct=10.
            |                                   |
            |                                   +-- YES --> Step to p=quarantine pct=10.
            |
            +-- p=quarantine
            |     |
            |     +-- What is pct?
            |           |
            |           +-- Less than 100 --> Ramp pct by 25 every 1-2 weeks.
            |           |                    Monitor reports at each step.
            |           |
            |           +-- 100 --> Are any legitimate sources appearing as failures?
            |                       |
            |                       +-- YES --> Fix authentication. Hold at quarantine.
            |                       |
            |                       +-- NO  --> Step to p=reject pct=100.
            |
            +-- p=reject
                  |
                  +-- Is rua= still configured and monitored quarterly?
                        |
                        +-- NO  --> Add rua= or resume review schedule.
                        |
                        +-- YES --> You are at full enforcement. Maintain.

NOTES:
- Never remove rua= at any policy level. Reports are your visibility.
- New sending tools require re-authentication before first use.
- Subdomains inherit nothing. Each subdomain used for sending needs its own
  SPF, DKIM, and DMARC configuration or an explicit subdomain DMARC record.
- sp= tag controls subdomain policy if not set separately at the subdomain level.

Real Example

A B2B SaaS company I worked with in early 2026 had published a DMARC record eighteen months earlier in response to the initial Google and Yahoo announcement. The record was v=DMARC1; p=none; — no rua tag, no report destination. They had received zero aggregate reports in eighteen months because there was no inbox configured to receive them.

From the outside, their DMARC implementation looked complete: the record existed, the DNS lookup returned a valid value, and every compliance checker they ran returned green. Their domain had been spoofed for at least three months, which they discovered only when a customer forwarded a phishing email that appeared to come from their support address. A green compliance check is not the same as a working implementation.

The remediation work took six weeks. First, we added the rua tag and spent two weeks reading the aggregate reports that immediately began arriving. Three legitimate sending sources were not fully DMARC-aligned: their transactional email provider had DKIM configured but SPF alignment was broken because the From: domain was their root domain while the SPF record only covered the subdomain they used for transactional mail. Their marketing automation platform was passing DKIM but their SPF record had not been updated to include the platform's sending infrastructure after they migrated from a previous tool the previous year. And a third-party survey tool was sending from a subdomain with no DMARC record and no authentication at all.

We fixed authentication for all three sources, confirmed clean aggregate reports across two weeks of observation at p=none, then moved to p=quarantine at pct=10 and stepped up to pct=100 over three weeks. After another two-week clean observation period, we moved to p=reject. The spoofed phishing mail stopped appearing in their customers' inboxes within days of the p=quarantine step, before they had even reached full enforcement.

Audit Checklist

• A DMARC record exists at _dmarc.yourdomain.com — verify with a DNS lookup tool or dig TXT _dmarc.yourdomain.com

• The record includes an rua= tag pointing to a monitored inbox or DMARC report aggregation service

• Aggregate reports are actually arriving and being reviewed at least monthly (not just configured and forgotten)

• Your current policy is not p=none if you have been running aggregate reports for 30 or more days and your sending sources are authenticated

• Every active sending source (ESP, transactional provider, CRM, third-party tools) has SPF and DKIM configured for DMARC alignment, not just for delivery

• Any subdomain used for sending has its own DMARC record or inherits a policy via the sp= tag on the root domain record

• Your SPF record includes all current sending infrastructure and does not include infrastructure from a previous ESP you migrated away from

• Your DKIM keys are at least 1024-bit (2048-bit recommended) and have been rotated in the last 12 months if your provider supports rotation

• You have a process to re-authenticate new sending tools before they send their first email, not after the DMARC reports flag them