What to Do When DMARC Reject Policy Generates Failur...

What to Do When DMARC Reject Policy Generates Failure Reports You Cannot Interpret

When you set your DMARC policy to p=reject, receiving mail servers refuse any message that fails authentication. What happens next surprises most administrators: your domain starts generating failure reports that land in your own inbox.

These are not spam. They are legitimate notifications that your DMARC policy is working as designed. The problem is that most administrators receive failure reports without a clear path to interpret them.

The reports tell you what went wrong. They do not always tell you how to fix it.

Why DMARC p=reject Sends Failure Reports to Your Inbox

Failure reports arrive because p=reject causes receiving servers to check every incoming message against your DMARC record. When a message fails authentication - because it comes from a third-party sender that is not aligned, or because forwarding broke the DKIM signature, or because a subdomain has no SPF record - the receiving server may send a report back to the address listed in your RUA record.

The volume of reports reflects how many sending sources are misaligned with your domain's authentication. Every legitimate sender that is not properly configured generates a failure every time they send. The reports accumulate in your inbox and can feel overwhelming if you do not have a system to parse them.

Reading Your DMARC Reports: Aggregate vs Forensic

Before you can act on the reports, you need to understand what kind of report you are looking at.

DMARC aggregate reports (RUA) are the most common. They arrive as a ZIP or XML attachment and contain a summary of authentication results over a 24-hour period. Here is a simplified example of what one source IP entry in an aggregate report might show:

203.0.113.42 fail pass 47

This tells you that IP 203.0.113.42 sent 47 messages claiming to be from your domain, that DKIM failed for all of them, and that SPF passed. The DKIM failure here means the signing domain did not align with your From domain. That points to a DKIM alignment problem rather than an SPF problem.

DMARC forensic reports (RUF) arrive immediately after a single failure. They contain the full headers of the failing message, including the Return-Path, From address, and authentication results. Forensic reports are useful when you need to identify exactly which message triggered the failure and from which IP. Most organizations disable forensic reports because they generate high volume and can expose sensitive information about your sending patterns.

For routine diagnosis, aggregate reports are more useful. Look for the source_ip field to identify which mail server sent the failing message, the dkim_result and spf_result fields to see which check failed, and the alignment fields to determine whether the From domain matched the authenticated sending domain.

The Three Most Common Causes of DMARC Failures at p=reject

1. Third-party senders not aligned with your domain

This is the most frequent cause. Services like marketing automation platforms, CRM systems, or legacy relay infrastructure send email that appears to come from your domain but is actually sent from their own servers. If they are not configured to use your domain's DKIM key or their sending IP is not listed in your SPF record, the message fails DMARC.

The fix: either add the third-party sender to your SPF record (if they use a fixed IP range), configure them to send with DKIM keys that match your domain, or move those sending functions to a subdomain that has its own less restrictive DMARC policy.

2. Subdomains sending mail without their own SPF record

This one surprises people. If your organizational domain has a p=reject policy and a subdomain sends mail but has no SPF record of its own, it inherits the parent policy. Every message from that subdomain fails. The sending application may report no error at all - the failure happens at the receiving server.

RFC 6686 specifies that a subdomain without its own DMARC record inherits the parent domain's policy. There is no ambiguity here: a subdomain that sends mail and has p=reject on the parent is either properly authenticated or its mail is rejected.

The fix: either add an SPF record for the sending subdomain, create a subdomain-level DMARC record with p=none or p=quarantine, or ensure the subdomain uses a sending method that aligns with the parent domain's authentication.

3. Misconfigured forwarding breaking DKIM alignment

Forwarding is a DKIM killer. When a message passes DKIM signing at the original sending server and is then forwarded by a mailing list or auto-forwarder, the forwarding server may modify headers or the envelope-from in ways that break DKIM validation. The SPF check may also fail because the forwarding server's IP replaces the original sender's IP.

The fix: this one is harder to resolve on the receiving side. The forwarded organization needs to implement ARC (Authenticated Received Chain) to preserve the original authentication results through the forwarding chain. If you are the sender, using strict DKIM alignment and ensuring your sending infrastructure does not get forwarded can help.

Decision Tree: How to Diagnose Which Cause Is Generating Your Reports

Work through these questions in order:

1. Do the failures come from your own IP ranges?

Yes: check whether a subdomain is sending without its own SPF record.

No: go to question 2.

2. Do the failures come from known third-party services (marketing platforms, billing systems, CRMs)?

Yes: configure that service to use your domain's DKIM key or add their sending IPs to your SPF record.

No: go to question 3.

3. Do the failures show DKIM passing but SPF failing at the receiving server?

Yes: likely a forwarding issue or ARC gap. Check whether recipients are forwarding your messages through mailing lists.

No: run a full header analysis using a forensic report if available, or check whether the sending domain in the From address matches the RFC5321 MailFrom domain.

How to Fix Each Cause Without Lowering Your Policy

For third-party senders: do not lower your DMARC policy to fix this. Lowering the policy to p=none or p=quarantine hides the problem instead of solving it. Use your aggregate reports to build a complete map of every legitimate sending source for your domain. Each unique source IP in a failure report is a sender you have not yet accounted for. Bring each one into alignment through SPF or DKIM.

For subdomains: audit which subdomains send mail. Any subdomain that sends automated mail - alerts, notifications, transactional messages - needs either its own SPF record, its own DMARC record, or a sending configuration that aligns with the parent domain.

For forwarding: the right solution is for the forwarding infrastructure to implement ARC, which preserves the original authentication results and allows the final receiving server to evaluate the message against the original sender's DMARC record rather than the forwarder's. If the forwarder has not implemented ARC, your options are limited to asking recipients to whitelist your domain or working with the forwarder to implement ARC support.

Why Automated DMARC Monitoring Catches What Manual Review Misses

Reading aggregate reports manually is tedious. A domain that sends through five third-party services and two subdomains generates reports with dozens of source IPs. Parsing the XML, deduplicating IPs, and identifying which failures are related requires automation - and more importantly, it requires tracking changes over time.

Consider what the manual process looks like in practice: you receive a ZIP of XML reports, you unzip and open them, you copy source IPs into a spreadsheet, you deduplicate, you cross-reference against your known sending inventory, and you repeat this every day. A new IP appears. Is it a vendor that just expanded their sending infrastructure, or is it a spoofing attempt? With manual review, you find out when a user reports that your emails are not arriving.

DMARCFlow automates this entire workflow. It ingests your aggregate reports, resolves source IPs against known sending infrastructure, tracks which third-party services are generating failures, and alerts you when a new sending source first appears. The shift in workflow is from reactive (something breaks, you investigate) to proactive (a new source appears, you evaluate whether it is authorized before it affects deliverability).

For the specific decision tree above, DMARCFlow replaces the manual IP lookup step in each question. Instead of cross-referencing source IPs manually, the tool surfaces the sending source, the domain it claims to be from, and the historical volume pattern - so you can answer each decision tree question in seconds rather than minutes.

When Failure Reports Are Normal and When to Act Immediately

Failure reports are normal and expected when you have recently added a new sending source that is not yet configured for your domain's authentication. If you just onboarded a new marketing platform and you see failures from their IP range for the first day or two, that is expected. If the failures persist beyond the vendor's warmup period, something is misconfigured.

Act immediately when the failure volume spikes without a known cause. A sudden increase in failure reports from an unknown IP range can mean someone is spoofing your domain at scale. The receiving servers are correctly rejecting the spoofed messages, but the volume of reports signals that spoofing is happening. Cross-reference the source IPs against your known sending inventory and your vendor IP ranges. If the IPs are not yours and not from a known vendor, treat this as a spoofing event and investigate.

Failure reports from your own employees' accounts can indicate a compromised mailbox being used to send unauthenticated mail through your mail server. This is different from external spoofing and requires a separate security investigation.

FAQ

Why do I get failure reports even though I trust everyone who sends from my domain?

DMARC does not trust intent. It verifies technical alignment. If a sender's mail server is not authorized in your SPF record or does not sign with your DKIM key, the message fails DMARC at the receiving server regardless of whether the sender is legitimate.

Can I reduce the volume of failure reports without lowering my DMARC policy?

Yes. The volume of failure reports reflects the number of misaligned sending sources. Each source you bring into alignment reduces future failure volume. You can also reduce report noise by configuring your RUA to receive reports only from your highest-volume sending sources, though this reduces visibility.

What percentage of failures is acceptable for a domain at p=reject?

Any persistent failure percentage above 0% for your own legitimate sending sources means something is misconfigured. Failures from unknown sources are expected and indicate spoofing attempts. The goal is 0% failures from known, authorized sending sources.

Should I switch back to p=none if I am getting too many failure reports?

Only as a temporary diagnostic step. Lowering the policy masks the problem and does not fix the underlying misconfiguration. Use the report data to identify the root cause and fix it. Return to p=reject once the sending sources are aligned.