DMARC Policy: Moving from p=none to p=reject Safely

DMARC (Domain-based Message Authentication, Reporting & Conformance) is one of the most effective tools available for preventing email spoofing. Yet the majority of domains that publish a DMARC record never make it past p=none — the monitoring-only mode that does nothing to stop malicious emails. Moving to p=reject is the goal, but doing it carelessly can silence legitimate email streams for weeks.

This guide walks through every stage of a responsible DMARC rollout: from reading your first XML reports to safely enforcing rejection at the domain and subdomain level.

Why p=none Is Not Enough

A DMARC policy of p=none tells receiving mail servers to take no action when authentication fails — it only requests that reports be sent back to you. This is valuable during the discovery phase, but it provides zero protection. Phishing emails that spoof your domain pass right through to inboxes.

Many organizations get stuck at p=none for months or years because they are afraid of breaking something. The fear is valid — misconfigured enforcement can cause legitimate emails to be quarantined or rejected — but it is manageable with a systematic approach.

Setting Up DMARC Reporting First

Before you do anything else, publish a p=none record if you do not already have one, and configure both the aggregate (rua) and forensic (ruf) reporting addresses.

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com; fo=1"

rua — Aggregate report destination. Receiving mail servers send daily XML summaries of all email they processed claiming to be from your domain.
ruf — Forensic (failure) report destination. Individual redacted copies of failing messages. Not all providers send these, and some jurisdictions have privacy restrictions around them.
fo=1 — Generate a forensic report on any authentication failure (SPF or DKIM), not just complete DMARC failures.

Give this record a few days to propagate and collect data before you analyze anything.

Reading DMARC Aggregate Reports

Aggregate reports arrive as gzipped XML attachments. The raw XML is not human-readable at scale, so use a DMARC reporting tool: Postmark's DMARC Digests, EasyDMARC, Dmarcian, or Valimail are all reasonable options with free tiers.

The key fields in each aggregate record:

<record>
  <row>
    <source_ip>203.0.113.45</source_ip>
    <count>127</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <spf>
      <domain>mail.example.com</domain>
      <result>pass</result>
    </spf>
    <dkim>
      <domain>example.com</domain>
      <result>fail</result>
    </dkim>
  </auth_results>
</record>

What you are looking for:

Source IPs sending on your behalf — categorize them as known (your ESP, marketing tools, internal mail servers) or unknown (potentially malicious or forgotten services).
DKIM pass/fail per source — has each sending service been configured to sign with your domain's DKIM key?
SPF pass/fail per source — is each sending IP included in your SPF record?
DMARC disposition — under p=none this always says none regardless of failures, which is why it does not protect you yet.

Identifying All Legitimate Email Streams

This is the most time-consuming part of the process, but skipping it causes broken email when you enforce policy. Go through your aggregate reports and catalog every source IP and the service it belongs to.

Common sending sources that get missed:

Marketing automation — HubSpot, Marketo, Mailchimp, Pardot
Customer support platforms — Zendesk, Freshdesk, Intercom (often send notification emails from your domain)
CRM systems — Salesforce, HubSpot CRM email features
Transactional email providers — SendGrid, Postmark, Amazon SES, Mailgun
HR and payroll systems — Workday, Gusto, BambooHR sending onboarding or payslip emails
Monitoring and alerting tools — PagerDuty, OpsGenie, Datadog
Internally hosted mail servers — old Exchange servers, application servers sending password reset emails directly
Partner and subsidiary domains — if you allow a partner to send on your behalf

For each one, ensure that either:

The sending IP is included in your SPF record, and the From: domain aligns with the SPF envelope sender, OR
The service is configured to sign with a DKIM key published under your domain, and the d= value in the DKIM signature aligns with your From: domain.

Alignment is critical. DMARC requires that either SPF or DKIM aligns with the From: header domain — not just that SPF or DKIM passes in general.

Moving to p=quarantine

Once your aggregate reports show that all known legitimate senders are achieving at least one aligned pass (SPF or DKIM), you are ready to move to p=quarantine. This tells receiving servers to deliver failing messages to the spam folder rather than the inbox.

Use the pct tag to roll out gradually:

_dmarc.example.com. TXT "v=DMARC1; p=quarantine; pct=5; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com; fo=1"

pct=5 means the quarantine policy applies to only 5% of failing messages. The remaining 95% are still handled as p=none. This limits the blast radius if you missed a legitimate sender.

Increase the percentage incrementally — 5%, 10%, 25%, 50%, 100% — with at least a week between each step to review the incoming reports. Watch for:

Unexpected increases in DMARC failures from known-good IPs
Complaints from internal teams that their emails are being filtered
Forensic reports showing legitimate-looking messages failing

When pct=100 shows no legitimate failures for at least two weeks, you are ready for the final step.

Advancing to p=reject

_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com; fo=1"

p=reject instructs receiving servers to outright drop failing messages. Some providers accept the message and discard it silently; others reject it at the SMTP level and return a bounce. Either way, spoofed emails claiming to be from your domain will not reach inboxes.

You can remove pct at this stage since the default is 100%.

Common Failures at Enforcement

Mailing Lists and Forwarding

Mailing list software (Mailman, Google Groups in pass-through mode) often rewrites the envelope sender but preserves the original From: header. This breaks SPF alignment. The solution is for the mailing list to either rewrite the From: header (ARC-compatible approach) or configure DKIM re-signing.

Email forwarding at the MTA level breaks SPF because the IP changes. This is why DKIM is more reliable — it survives forwarding as long as the message body and headers are not modified.

Shared Hosting and Legacy Mail Servers

Applications hosted on shared servers often send email directly from the server's IP, which is not in your SPF record. Find these by checking aggregate reports for source IPs in hosting provider ranges.

Third-Party Services Without DKIM Support

Some older SaaS tools do not support custom DKIM signing. For these, your options are: configure SPF alignment using a subdomain (e.g., From: noreply@mail.example.com with its own SPF record), push the vendor to add DKIM support, or migrate to a different service.

Subdomain Policy

By default, your root domain's DMARC policy does not automatically apply to subdomains. Use the sp tag:

_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@example.com"

This is important because attackers frequently use subdomains for phishing — payroll.example.com, invoices.example.com — since the root domain may be protected but subdomains are not. If you have legitimate email sending from specific subdomains, publish individual DMARC records for those subdomains:

_dmarc.mail.example.com. TXT "v=DMARC1; p=none"

A subdomain-specific DMARC record takes precedence over the organizational domain record.

Maintaining Enforcement Long-Term

Reaching p=reject is not a one-time task. Aggregate reports need to be reviewed regularly because new email streams get added over time — a new marketing platform, a new application that sends password resets, a vendor integration. Every time a new sending source is added, it may initially fail DMARC authentication until properly configured.

Set up alerts in your DMARC reporting tool for new source IPs appearing in aggregate reports, and treat that as a trigger to investigate and configure the new sender.

DMARC enforcement combined with properly configured SPF and DKIM is one of the highest-ROI security controls for email — it directly prevents your domain from being used in phishing attacks against your customers and partners.