Why DMARC p=reject Rejects Legitimate Email

You switched to DMARC p=reject. Your CRM notifications stopped arriving. Internal alerts are bouncing. SPF passes. DKIM passes. But DMARC fails anyway and your legitimate email gets rejected.

Here is the short version of what is happening: DMARC is working correctly. The problem is that your sending infrastructure cannot prove it is authorized to send from your domain. That is an alignment problem, not a DMARC misconfiguration.

The first thing to do is check your DMARC aggregate reports and look for sending IPs with DKIM or SPF pass but alignment failure. Those aligned failures are your problem. DMARCFlow surfaces exactly this: which IPs are failing, whether DKIM or SPF is involved, and whether the failure is an alignment issue or a raw authentication failure. That distinction tells you where to start.

The rest of this article explains why alignment fails, which sending systems typically cause it, and how to fix each one.

What alignment actually means

DMARC checks one of two things. Either the DKIM signature's signing domain matches your From header domain, or the SPF envelope return-path domain matches your From header domain. Raw DKIM pass or SPF pass is not enough. The signing domain has to align with the domain in your From address.

When DKIM is in play, the email includes a DKIM-Signature header with a domain identifier in the "d=" field. DMARC reads that field and compares it to the domain in your From header. If they differ, alignment fails. The DKIM signature is valid -- the sending server is authorized to send. But DMARC rejects the email because the signing domain does not match the From domain.

The same logic applies to SPF. The MAIL FROM or return-path domain has to match the From header domain. When an ESP or internal system uses its own return-path domain, SPF alignment fails even if the sending IP is authorized in your SPF record.

This is the part that causes the most confusion. Organizations see raw DKIM pass and SPF pass and assume DMARC should accept the email. DMARC requires one of those passes and alignment on top of it. Both are required, not either/or.

Why this breaks when you move to p=reject

Your From header displays you@example.com. But your ESP or internal system sends using its own infrastructure. The DKIM signature is for the ESP's domain. The return-path is the ESP's domain. Neither aligns with your From header. At p=none, these failures are logged and email delivers. At p=quarantine, they sometimes reach spam. At p=reject, DMARC blocks them outright.

The policy shift surfaces sending infrastructure you did not know you had. Internal tools, CRM integrations, legacy SaaS platforms -- they were silently misaligned. p=reject makes the problem visible.

Common culprits

Third-party ESPs and CRMs. Marketing platforms and transactional email services often send from their own infrastructure by default. The From header displays your domain to the reader, but the DKIM signature and return-path are theirs. That is an alignment failure. It fails DMARC regardless of whether DKIM itself is valid. This is the single most common cause of p=reject false positives.

Internal mail systems and automation scripts. Printers that email scans, monitoring tools that send alerts, ERP and ticketing systems that send notifications -- these often relay through local mail agents with no DKIM signing and SPF pointing to the wrong domain. They are invisible until p=reject activates and they start bouncing.

Legacy and SaaS platforms with hard-coded sending. Some platforms send From addresses that look like yours but route through the vendor's own mail system. You cannot reconfigure the sending behavior. Until the vendor changes their infrastructure, these will fail alignment.

How to fix it

For third-party ESPs and CRMs, check whether your platform supports custom DKIM signing with your own domain. SendGrid, Amazon SES, Mailgun, and Postmark support this. The DKIM signature uses your domain instead of theirs, alignment passes, and DMARC accepts the email. If custom DKIM is not available, use subdomain delegation: send marketing or transactional email from a subdomain such as marketing@example.com that is routed through the ESP with DKIM configured for that subdomain. Your main domain stays at p=reject. The subdomain handles unaligned sending with its own aligned configuration.

For internal mail systems, the fix depends on the system. Simple cases like Cron job notifications or monitoring alerts can relay through your main mail infrastructure with proper SPF and DKIM. More complex environments benefit from a dedicated internal mail relay that handles DKIM signing for all internal-originated email. The relay authenticates each internal sender, then forwards with proper From header and aligned DKIM signature. Your main domain DKIM and SPF do not change.

For legacy or SaaS platforms that cannot be reconfigured, subdomain delegation is the practical option. Route their sending through a subdomain with its own DMARC record set to p=quarantine or p=none. Your main domain stays fully protected at p=reject. The From header still displays your main domain to the recipient. The alignment check passes because the subdomain's DMARC policy is aligned with its own sending behavior.

How to find all your misaligned systems before you switch

Before activating p=reject, run at p=none long enough to collect representative DMARC aggregate reports -- typically two to four weeks. Every sending IP in those reports that shows DKIM pass or SPF pass but alignment failure represents a system that will break when p=reject goes live.

Match those IPs against your known infrastructure: your ESP, your internal IP ranges, your SaaS tools. Anything that does not match a known system needs investigation. You may find sending infrastructure you did not know about.

DMARCFlow makes this process faster. The aggregate report viewer shows alignment failures grouped by sending IP, making it straightforward to build a complete inventory without parsing raw XML. That inventory tells you exactly what needs fixing before the policy goes live.

Validating your fixes before going live

After reconfiguring your ESP or internal relay, return to p=none for a period and monitor aggregate reports. Check that the previously failing sending IPs now show aligned passes. If the same IPs that failed alignment are now passing, the fix is working. When all your known sending systems show aligned passes, it is safe to move to p=reject.

This validation step is what prevents the bounce reports that happen when organizations move to p=reject without checking their reports first.

If it is already happening right now

Do not lower the policy back to p=none immediately. Lower to p=quarantine instead. This restores most legitimate email delivery while you fix the root cause. Then work through your sending systems systematically. Once aggregate reports confirm all systems are aligned, raise the policy to p=reject.

The reports exist for a reason. Use them before you move the policy, not after.

FAQ

Can I just set p=none again?

You can, but that removes the protection you added. Lower to p=quarantine instead. This keeps reject-level protection for properly aligned email while restoring delivery for misaligned senders. Fix the alignment problems, confirm the fixes in reports, then raise to p=reject.

What if my CRM vendor does not support custom DKIM?

If the vendor does not support custom DKIM and subdomain delegation is not feasible, route their email through your own mail relay. Your relay receives the email from the CRM, then forwards it with proper DKIM and From header alignment. This adds latency so it is not ideal for transactional email, but it works for batch sends where a short delay is acceptable.

Does this mean p=reject is too aggressive for most organizations?

No. p=reject is the right target for any domain that sends email publicly and has completed aDMARC alignment audit. The problem is not the policy -- it is that most organizations have more sending infrastructure than they realize. The answer is to fix the infrastructure, not to avoid the policy.

How long until I see alignment fixes in my DMARC reports?

DMARC aggregate reports from major receivers are typically generated daily, sometimes less frequently. Config changes may not appear for 24 to 48 hours. Some receivers generate reports weekly. Plan for at least a few days of monitoring at p=none before assessing whether a fix is working.

---

The false positive problem at p=reject is almost always an alignment problem in disguise. Your DMARC reports tell you exactly which sending systems are misaligned. DMARCFlow gives you a readable view of those reports without requiring you to parse XML manually. That is where to start, and that is how you confirm the fix is working before you raise the policy.