How to Stop Rejected Emails From Filling Up Your Mailbox

Why Your Mailbox Is Full of Rejection Notices

The rejection notices filling your mailbox are not coming from your mail server. They are coming from other mail servers that received mail appearing to be from your domain, checked it against your DMARC policy, and decided to reject it.

Here is the exact sequence. Someone -- either your mail server or someone impersonating your domain -- sends a message with a From address of user@yourdomain.com to a receiving server. That receiving server performs DMARC validation. The message fails DMARC because the SPF or DKIM does not align with yourdomain.com. The receiving server then generates a delivery status notification (DSN), also called a bounce message, and sends it back to user@yourdomain.com. That is the rejection notice in your inbox.

If the original mail was legitimate, your sending infrastructure had a configuration problem. If the original mail was not yours, someone was spoofing your domain, and you are receiving the collateral damage of other servers rejecting mail that looked like it came from you.

This process is called backscatter. The term describes the way rejection notifications scatter back to the From address after mail is rejected at the destination.

Two Sources of Backscatter

The first source is your own mail failing DMARC. Your mail server sends a message, but the SPF record does not include the sending IP, or the DKIM signature does not match the From domain, or both. Receivers reject the mail, and rejection notices come back to your From address. The fix is to fix your sending infrastructure so your mail passes DMARC.

The second source is more common and more damaging: someone else is spoofing your domain. They send mail with your From address from infrastructure they control. Your mail server never touched the message. But when receivers reject the spoofed mail, the rejection notification goes to your From address because that is what the From header says. You receive rejection notices for mail you never sent.

The difference matters for the fix. If your own mail is failing, you fix your DNS records. If someone is spoofing your domain, the only reliable fix is to make DMARC reject policy strict enough that receivers refuse spoofed mail before they accept it.

Step 1: Find Out What Is Actually Failing

Before changing your DMARC policy, look at your aggregate reports. These are XML reports sent to the email address specified in the rua tag of your DMARC record. They arrive daily and show which sending sources are passing and failing DMARC for your domain, broken down by receiving organization.

If you do not have aggregate reports set up, set them up now. Without the data from aggregate reports, you are guessing about what is failing and why. You cannot safely move to a reject policy if you do not know whether your own sending infrastructure is passing DMARC.

When you have aggregate reports in front of you, look for patterns:

• Are failures coming from IP addresses you control? That means your own sending infrastructure has a configuration problem. Fix that first.
• Are failures coming from IP addresses you do not recognize? That means someone is spoofing your domain. The volume of spoofed mail is the backscatter you are receiving.
• Are failures concentrated at specific receivers? Some receivers enforce DMARC more strictly than others. High failure volume at specific large receivers is a sign of spoofing.

If you see failures from your own servers, do not move to reject policy yet. Fix the underlying SPF or DKIM problem first. Moving to reject while your own mail is failing will break your legitimate email delivery.

Step 2: Fix Your Own Sending Infrastructure

If your aggregate reports show your own servers failing DMARC, identify which domain is failing and why. The most common causes:

• Your mail server IP address changed but your SPF record still lists the old IP. Receivers see your mail coming from an IP not in your SPF record, SPF fails, and DMARC fails.
• Your DKIM key was rotated and the new public key was not published to DNS, or the DNS record has a typo. DKIM signatures fail because receivers cannot validate them.
• A third-party service (marketing platform, billing system, CRM) sends mail using your From address from its own infrastructure. SPF fails because the sending IP is not in your SPF record. DKIM fails because the service is not signing with your domain key.

For each case, the fix is specific. Update your SPF record when your IP changes. Publish your DKIM public key correctly after rotation. For third-party senders, either route their mail through your infrastructure so your SPF and DKIM apply, or have the service sign with a DKIM key under your domain so alignment passes.

Do not move to reject policy until your aggregate reports show zero unexpected failures from your own infrastructure across at least two weeks of data.

Step 3: Move to DMARC Reject Policy

When your aggregate reports show your legitimate mail consistently passing DMARC, you are ready to update your policy record from p=none to p=reject.

The current record looks something like:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Update it to:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

That single character change -- p=reject instead of p=none -- changes how receivers handle mail from your domain. Receivers that validate DMARC will now refuse messages that fail alignment, rather than accepting them and sending rejection notifications back to your From address.

For legitimate mail from your infrastructure: if your SPF and DKIM are correct, nothing changes. Your mail passes DMARC and is delivered normally.

For spoofed mail using your domain: receivers refuse the message before accepting it. No rejection notification is sent back to your From address. The backscatter stops.

For mail from vendors or partners sending on your behalf without proper alignment: this is where p=reject breaks things. If a vendor sends from their own infrastructure using your From address, their mail will be rejected. You will find out because the vendor will report delivery failures or you will see bounce reports in your aggregate data.

What Happens to Legitimate Mail After You Enable Reject

The most common break after moving to p=reject is vendor mail. Any third party that sends email from your domain without using your SPF or DKIM will fail DMARC once you enforce reject. This includes marketing email platforms, billing systems, CRMs, and any other service that sends on your behalf.

The discovery process is not usually pleasant. Most teams find at least one vendor they forgot about, or discover that a vendor changed their sending infrastructure without telling anyone. You will find out from aggregate reports showing failure counts from vendor IP addresses, or from the vendor reporting that their delivery rates dropped.

The fix options are:

• Route the vendor's mail through your mail server so your SPF and DKIM apply to it
• Have the vendor sign with a DKIM key under your domain so alignment passes
• Add the vendor's sending IPs to your SPF record and have them sign with your DKIM key (less ideal but workable)
• Exclude that vendor's IPs from DMARC alignment requirements using a subdomain policy (sp=) if the vendor only sends from specific subdomains

After moving to reject, check your aggregate reports weekly for the first month. Look for new failure sources that were not present in your baseline data. Those are the gaps you need to close.

If you are reviewing aggregate report data manually and finding it slow to parse, tools that consolidate DMARC reports from multiple domains into a searchable interface remove the overhead of processing XML files per domain. DMARCFlow is built for this: one view of all your domain data so you can spot new failure sources after moving to reject policy without manually checking each domain separately.

Frequently Asked Questions

Why am I receiving rejection notices for mail I did not send?

You are receiving backscatter. Someone is sending mail that appears to come from your domain. Receiving mail servers are rejecting that mail and sending rejection notifications to your From address. The mail was not yours. This is a spoofing problem. Moving to DMARC p=reject makes it harder for spoofers to use your domain, which reduces the backscatter over time.

Is backscatter dangerous?

Backscatter itself is not malicious. It is annoying and it fills your mailbox. However, backscatter is a symptom of someone using your domain to send mail. If they are using your domain, they may be phishing your customers, damaging your sender reputation at receivers, or both. The backscatter is noise. The spoofing is the actual problem.

Can I block the rejection emails at my mail server?

You can filter them, but blocking is not straightforward because the rejection notices come from external servers and appear to be legitimate delivery status notifications. Blocking them risks blocking real bounces. Fix the root cause instead: move to p=reject so receivers refuse spoofed mail before generating rejection notifications.

How long does it take for p=reject to start working?

DMARC policy changes propagate as DNS changes propagate. Most receivers check your DMARC record every time they receive a message, so the policy change takes effect within minutes to hours for most receivers. Some large receivers cache DNS records and may take up to 24 to 48 hours to pick up the new policy. You should see backscatter start to drop within a day and be significantly reduced within a week.

What breaks when I move from p=none to p=reject?

The most common breaks are third-party vendors sending on your behalf without proper alignment, any internal mail system that sends from an IP not in your SPF record, and any application that rewrites the From address in transit. Review your aggregate reports for at least two weeks before moving to reject, and monitor them closely for the first month after. Every new failure source you find is a gap in your sending infrastructure that needs to be closed before or shortly after the policy change.

The Short Version

Backscatter is rejection noise. It comes from your domain failing DMARC checks at receiving servers, either because your own mail is misconfigured or because someone is spoofing your domain. Fix your own infrastructure first. When your aggregate reports show clean passing data, move to p=reject. Watch for vendor mail breaking after the change. The backscatter does not stop instantly, but it drops significantly once receivers start refusing spoofed mail before accepting it.