Ready for DMARC p=reject? Your Pre-Flight Checklist

Most domains start with DMARC set to p=none. It is the safest first step -- you get reports, you learn what is sending mail on your behalf, and nothing breaks. But p=none does not stop forgers. It only tells you who is trying.

At some point most domain owners want to move to p=reject and actually block the spoofers. The question is when you have done enough preparation that flipping the switch will not also block legitimate mail.

Most advice says "make sure your authentication passes." That is technically correct but practically useless if you do not know what that means or how to verify it at scale. This guide gives you the actual checklist.

What p=reject does

When you set your DMARC record to p=reject, receiving mail servers are instructed to block any message that fails DMARC alignment. The message does not land in spam. It gets rejected at the SMTP level.

For your domain, this means two things at once:

Phishers and spoofers cannot send mail that appears to come from your domain. Their messages get blocked.
If one of your legitimate sending sources is not properly configured, its messages also get blocked.

The risk of breaking legitimate mail is real. That is why readiness matters.

The three pillars of DMARC readiness

Before you move to p=reject, three things need to be true for every source that sends mail from your domain:

1. SPF is configured for every legitimate sender

SPF (Sender Policy Framework) lists the IP addresses that are authorized to send mail for your domain. If a mail server sends a message from @yourdomain.com but its IP is not on your SPF record, that check fails.

The readiness question is not "do I have an SPF record?" It is "does my SPF record cover every IP that legitimately sends mail on my behalf?" That includes marketing automation platforms, internal mail servers, HR systems, CRMs, and any SaaS tool that sends email as you.

2. DKIM is signed by every legitimate sender

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outbound messages. Receiving servers verify that signature against your public key, published in DNS. If the signature is missing or does not match, the DKIM check fails.

Many third-party senders (Google Workspace, Microsoft 365, Mailchimp, SendGrid) sign their outgoing mail by default. But some require DKIM setup to be enabled explicitly. Others might sign mail but use a selector domain that does not align with your From domain.

3. Your DMARC aggregate reports show no unknown senders

This is where most readiness guides fall short. You can have perfect SPF and DKIM configuration and still be unready if you do not know what is actually sending mail from your domain.

DMARC aggregate reports arrive daily from every major receiving server (Gmail, Yahoo, Microsoft, Apple, and thousands of others). They tell you which IPs are sending mail that claims to be from your domain, whether those IPs passed or failed SPF and DKIM alignment, and what percentage of messages passed or failed.

If you see IPs in those reports that you do not recognize, you have unknown senders. Moving to p=reject with unknown senders in your reports means you will block legitimate mail without knowing why.

Step-by-step readiness checklist

Work through each step before you change your DMARC policy. If you find a problem at any step, fix it before proceeding.

Step 1: Collect at least four weeks of DMARC aggregate reports

One week of data is not enough. Some senders (especially marketing platforms and payroll systems) send mail on a bi-weekly or monthly cycle. Four weeks gives you visibility into all of your regular sending patterns.

DMARCFlow aggregates reports from all major providers and surfaces unknown senders and alignment failures in a single view, so your readiness check takes minutes rather than hours of XML parsing.

Step 2: Identify every unique sender IP in your reports

Look at the source IP field in each report. Ask for each one: "Do I know why this IP is sending mail for my domain?" Your known senders should include your own mail servers, your SaaS tools, and any third-party platforms.

List every unknown IP. These need to be either authorized (added to SPF or identified as a legitimate third-party sender) or investigated before you move to reject.

Step 3: Verify SPF for every known sender

For each known sending IP, check whether your current SPF record includes it. If an IP is missing from your SPF record, add it. If an IP belongs to a third-party sender that does not support SPF alignment, you may need to use a different authentication method or route that sender through a mail flow that does support it.

Step 4: Verify DKIM signing for every known sender

Check whether each of your known senders is adding a valid DKIM signature to messages. You can spot-check this by looking at email headers in your sent folder, or by using a DKIM checker tool. Pay attention to the d= domain in the DKIM signature -- it must match your From domain exactly, not a subdomain or a third-party selector domain.

Step 5: Check alignment for all sending sources

DMARC alignment means the domain in the From header matches the domain in the SPF or DKIM authentication result. A message can pass SPF but still fail DMARC if the RFC5321 Mail From domain differs from your From domain. In your aggregate reports, look for the "disposition" field. You want all legitimate traffic showing "none" disposition (p=none is still in effect) and aligned. Consistent failures from a known sender must be resolved before you move to reject.

Step 6: Confirm zero or near-zero unknown senders

If your four weeks of reports show no IPs you cannot identify, and all known senders are passing alignment, you are ready. If you have unknown IPs representing under 1% of total volume and you have confirmed they are not critical mail systems (password resets, security alerts), you can move to reject but monitor closely in the first 48 hours.

What to do if you find problems

Unknown senders are the most common readiness blocker. Here is the priority order for addressing them:

1. Add missing legitimate senders to SPF -- If a known SaaS tool is sending mail for your domain and is not in your SPF record, add it. Most major providers have published SPF mechanisms you can include.

2. Enable DKIM for third-party senders -- If a sender is not signing mail, check whether they support DKIM. Many do but require it to be enabled in their admin console.

3. Route unknown senders through a compliant relay -- If you discover a legitimate sender that cannot be authenticated directly, consider whether email relay through a service that does support proper authentication is practical.

4. Do not ignore low-volume unknowns -- Even if an unknown sender represents 1% of your mail volume, at p=reject that 1% gets blocked. If that 1% is password reset emails or security alerts, you will have a problem.

How to test before committing

p=quarantine is your staging environment. Set your DMARC record to p=quarantine and leave it there for two to four weeks while you continue to monitor reports. Messages that fail DMARC alignment will go to spam rather than being blocked outright.

This gives you a safety net. If a legitimate sender is still misconfigured, their messages go to spam instead of bouncing. You can fix the configuration before flipping to p=reject.

Watch your bounce reports and spam folder placements during this period. If you see a spike in undelivered messages or messages going to spam that should not be, you have a configuration problem to fix first.

How DMARCFlow helps

The readiness checklist above depends entirely on having readable, aggregated DMARC reports. Manually parsing the XML files that come from receiving servers is time-consuming and error-prone. If you have dozens of receiving domains and hundreds of sending IPs, the raw report data is nearly impossible to read without a tool that normalizes and aggregates it.

DMARCFlow is built for exactly this. It connects to your DMARC report sources and turns the XML stream into a readable dashboard: unknown senders surface automatically, alignment failures are flagged by domain, and you can filter the data by time period to run a readiness check in minutes instead of hours.

For teams running p=none who want to evaluate readiness without building their own report pipeline, DMARCFlow handles the aggregation and surfaces exactly the failures you need to fix before you change the policy.

The short version

You are ready for DMARC p=reject when:

You have four or more weeks of DMARC aggregate reports
Every IP in those reports is a known, authorized sender
Every known sender passes SPF and DKIM alignment
Your From domain matches across all authentication checks
You have tested with p=quarantine for at least two weeks without incident

If all of those boxes are checked, you can move to p=reject with confidence. If one or more boxes are not checked, treat that as your action item before you change the policy.

Related concepts: DMARC p=none -- SPF -- DKIM -- DMARC alignment -- Email authentication