Why DMARC Reject Sends You Backscatter Notifications -- And How to Stop Them

You enabled DMARC p=reject to protect your domain. Now your inbox is full of rejection notifications appearing to come from your own domain. This is normal. Here is why it happens, what it means, and how to use your DMARC aggregate reports to make it stop.

What is email backscatter?

Backscatter is what happens when a receiving mail server sends a bounce or rejection notification to the address in an email's From header. If that From address is your domain, the bounce comes to you -- even if you did not send the original message.

This is not new behavior. Backscatter has been part of email since the beginning. What changes with DMARC p=reject is the volume, because reject enforcement catches mail that used to slip through.

Why DMARC p=reject creates backscatter

When you set DMARC to p=reject, receiving servers enforce authentication checks on every inbound message. If a message fails DMARC alignment -- meaning neither SPF nor DKIM passes for the From domain -- the server rejects it and sends a rejection notice to the From address on the original message.

The rejection notice goes to your domain because your domain was in the From header. The actual sender might be a misconfigured third-party platform, or it might be an attacker spoofing your domain. Either way, the bounce goes to you.

This is why p=reject surprises most teams when they first deploy it. The policy is working. The backscatter is the evidence.

Three reasons backscatter appears

Authorized senders are failing DMARC alignment

Your organization probably sends email through multiple third-party services -- a marketing platform, a support tool, a legacy CRM, an internal system. These services send from your domain using their own servers and DKIM keys.

If a service sends mail with your domain in the From header but signs with its own DKIM key, DMARC alignment fails. The receiving server rejects the message and sends the bounce to your domain.

This is the most common cause of backscatter after a first DMARC deployment. It is also the most fixable.

Legitimate mail that used to flow is now being rejected

Before DMARC was enforced, misconfigured third-party senders could still deliver mail because no policy was blocking them. After p=reject is enabled, that mail gets stopped. The backscatter you see in the first weeks after deployment is mostly legitimate mail that was always failing authentication -- you are only seeing it now because something is finally doing something about it.

Attackers are spoofing your domain

Attackers regularly forge domains in phishing campaigns. When those spoofed messages hit receiving servers that apply DMARC reject, the rejections bounce back to the targeted domain. A sudden spike in backscatter volume with no corresponding increase in your own sending activity is usually a sign that your domain is being used in an active spoofing campaign.

How to read your DMARC aggregate reports

Your DMARC aggregate reports arrive from receiving servers that accepted mail from your domain. They contain authentication results for each sending source -- no message content, just metadata. Aggregate reports are the primary tool for understanding why backscatter is happening.

DMARCFlow parses these reports automatically and shows you a per-source breakdown of DKIM and SPF results, failure reasons, and volume trends. Without a tool like this, you are reading raw XML from dozens of receiving servers -- which is how most teams describe their experience before using one.

In your aggregate reports, look for these signals:

Which source IPs are generating rejections

Each failing source appears with its IP address and authentication results. An authorized third party will correspond to a known service. An unknown IP with your domain in the From header is likely spoofing.

DKIM and SPF result per source

If a known third party shows DKIM failures, their DKIM signing is not aligned with your domain. That is the fix -- get them to sign with your domain, not theirs.

Volume changes over time

A sudden 5x increase in failure volume from unfamiliar IPs over 48 hours, with no change in your own sending, means an active spoofing campaign is likely underway. DMARC is doing its job. The backscatter is informational at this point.

Steps to reduce backscatter

Once aggregate reports show you which sources are failing, here is how to work through them.

Step 1: Classify each failing source

For each source IP in your aggregate reports, ask one question: do we authorize this sender? If yes, it needs fixing. If no, it is likely spoofing and should be blocked by the DMARC policy.

Step 2: Fix DKIM signing for authorized third parties

Authorized senders need to sign DKIM with your exact From domain. Many services default to signing with their own domain, which fails DMARC alignment. Work with the vendor to configure DKIM for your domain. If the service cannot do this, consider switching to one that can -- proper DKIM alignment is a baseline requirement for any third-party email sender in 2026.

Step 3: Check SPF alignment for subdomain mail

SPF checks the envelope sender (Return-Path), not the From header. If a third-party service sends mail with your domain in the From header but their own domain in the Return-Path, SPF passes but DKIM alignment still fails. In this case, DKIM is the fix -- SPF alone will not save it.

Step 4: Apply a subdomain policy while fixes are in progress

If a specific subdomain is generating backscatter and the responsible service cannot be fixed immediately, apply a separate DMARC record to that subdomain with a looser policy (p=quarantine or p=none) while the parent domain stays at p=reject. This limits the blast radius.

Step 5: Monitor volume for spoofing signals

Use your aggregate report volume as a baseline signal. A spike in rejections from unfamiliar IPs is not a problem to fix -- it is a report that your policy is working. Log it, track it, and use it to demonstrate to stakeholders that the DMARC deployment is catching spoofing attempts.

When backscatter signals a larger problem

Backscatter that arrives suddenly, with no changes on your end, usually means an external party is actively spoofing your domain. This is worth investigating because spoofing campaigns frequently coincide with phishing using your brand.

The tell is volume against baseline. If your aggregate report volume doubles or triples over a weekend and you did not change your sending patterns, something is being sent in your name. DMARC p=reject is already handling it. Your job at that point is to document the scope using your aggregate reports and assess whether the spoofing targets customers or partners who might be vulnerable.

This is also where a tool that tracks aggregate report volume over time pays for itself. Raw XML reports do not show you trends. DMARCFlow shows you the volume chart, so you can spot a spoofing campaign within hours instead of days.

Frequently Asked Questions

Does backscatter mean my DMARC policy is wrong?

No. Backscatter is the expected result of rejecting mail that fails authentication. What matters is whether the failing sources are authorized senders that need configuration fixes, or unauthorized spoofing that your policy is correctly blocking.

Why do I see rejection emails from my own domain?

Because the From header on the original message contained your domain. Rejection notices go to the From address, not the actual sending server. This is how email bounce routing works at the protocol level and is unrelated to whether you sent anything.

Should I switch back to p=none to stop backscatter?

No. Switching to p=none hides the problem rather than fixing it. If authorized senders are failing, they still need to be reconfigured. If spoofing is the cause, p=none allows the spoofed mail into inboxes. Keep p=reject and work through the senders.

How long does backscatter last after enabling DMARC reject?

For new deployments with misconfigured third-party senders, backscatter typically drops significantly within 2-4 weeks once senders are reconfigured. For spoofing-related backscatter, it continues as long as the campaign is active. DMARC does not stop spoofing -- it makes it visible.

Can I block reject notifications from being sent to my domain?

No. Bounce notifications are generated by receiving servers, not your domain. You cannot prevent them. The only way to stop backscatter is to stop mail from failing DMARC in the first place -- either by fixing authorized senders or by keeping spoofed mail from reaching receiving servers (which p=reject already does).

What you actually need to do

Backscatter after enabling DMARC p=reject is a signal, not a problem. It tells you which senders are failing authentication and which receiving servers are enforcing your policy. Read the aggregate reports, classify the failing sources, fix the authorized ones, and ignore the spoofed ones -- p=reject is already handling them.

The part most teams find hardest is making sense of aggregate report data quickly. DMARCFlow parses DMARC reports automatically and presents a breakdown by source, failure type, and volume trend. That is the practical work this article describes -- and it is where a dedicated DMARC tool saves the most time for teams deploying or managing DMARC at scale.