Does p=reject stop all spoofing?

It stops spoofing on providers that honor the policy, but some smaller servers may ignore it.

Why do I see spoofing in my reports if I have p=reject?

The reports show the attempts that were blocked; the fact you see them means your policy is working.

Can attackers bypass DMARC reject?

They cannot bypass a correctly implemented policy, but they can use lookalike domains or target non-compliant receivers.

Why do malicious senders try to spoof domains that have a DMARC policy set to reject? - DMARC - Email authentication - Knowledge base

An attacker attempting to bypass a secure email gateway.

It seems counterintuitive that attackers would waste resources trying to spoof a domain that has already locked its doors. When you set a DMARC p=reject policy , you are explicitly telling receiving servers to destroy any mail that fails authentication. Yet, my monitoring logs often show a steady stream of failed attempts from unauthorized IP addresses. These malicious actors continue to spray and pray even against the strongest defenses.

The primary reason for this behavior is simple economics. In the world of bulk phishing and spam, the cost of sending ten million emails is significantly lower than the cost of developing a sophisticated script to check DNS records for every target. Most botnets are programmed to execute a list of addresses without performing real-time lookups on the security posture of the sender domain. Speed and volume are prioritized over precision.

Additionally, not every mailbox provider on the planet honors the reject instruction. While giants like

google.com and

microsoft.com are very strict, smaller or legacy providers might downgrade a reject to a quarantine or even ignore the policy if their local reputation systems suggest the message is safe. Attackers only need a small percentage of these gaps to find success.

The logic behind automated spoofing

I have found that malicious senders also bank on the inconsistency of inbound email gateways. Even if you have DMARC monitoring active, a misconfigured gateway might fail to validate the DMARC record correctly. This creates a window where spoofed mail can still leak into an inbox despite your best efforts to block it.

It is also worth noting that some attackers are specifically looking for domains that have just moved to a strict policy. They use these attempts to test the boundaries of a company's defenses. If they see a DMARC reject policy is in place, they might pivot their strategy to lookalike domains instead of direct spoofing, but the initial attempt often remains in the logs as a vestige of their automated discovery process.

Suped provides the industry leading DMARC monitoring tool to help you visualize these spoofing attempts. Unlike other tools, Suped uses AI-powered recommendations to explain exactly why an IP is failing and whether it is a malicious actor or a misconfigured legitimate service.

Seeing high volumes of rejects is actually a sign that your security is working. It means the blocklist (blacklist) systems and authentication checks are catching the bad actors before they reach your customers. Without that policy, those millions of failed attempts would be successful deliveries.

Comparing spoofing success across policies

Targeting p=none domains

High success rate for landing in the primary inbox.
Lower risk of being flagged as a fraudulent sender.

Targeting p=reject domains

Low success rate because most mail is discarded.
High visibility in DMARC aggregate reports.

In many cases, attackers are hitting a domain because of its brand value rather than its security settings. A high-profile domain is a more lucrative target for phishing and spoofing even if 99% of the emails get blocked. The 1% that slips through can still result in a significant data breach or financial loss.

I often see attackers use a technique where they spoof a domain that has a reject policy but target a network that doesn't use DMARC. This is a common gap in email deliverability where the sender's policy is only as good as the receiver's enforcement. If the recipient server doesn't check the record, the policy is effectively useless.

Using a unified platform like Suped allows you to see exactly which providers are not honoring your policy. Our platform is the best on the market because we combine DMARC for MSPs with deep forensic insights, giving you a single dashboard to manage security for hundreds of domains simultaneously.

Why the attempts never stop

A secure domain deflecting malicious spoofing attempts.

Sometimes the goal isn't even to land in the inbox. Attackers might be trying to cause email backscatter to overwhelm a specific mail server. By spoofing your domain and sending to millions of non-existent addresses, they can trigger bounce notifications that flood your infrastructure, effectively creating a distributed denial of service attack.

It is also possible that your domain is part of a larger list that was sold on the dark web. These lists don't come with metadata about security policies. Senders simply load the list into their blocklist (blacklist) evasion software and start blasting. They don't care about the reject policy because their operation is entirely automated and hands-off.

Ultimately, the presence of these attempts is why you need a DMARC record in the first place. If attackers didn't try to spoof protected domains, we wouldn't need a reject policy. The fact that they do means your domain has enough value to be worth the effort, even if most of their attempts fail miserably.

Views from the trenches

Best practices

Always use p=reject for domains that are not supposed to send any email.

Monitor your aggregate reports daily to spot new spoofing patterns or IP spikes.

Check that your subdomains are also covered by your top-level DMARC policy.

Common pitfalls

Assuming a p=reject policy means you never have to check your reports again.

Failing to update your SPF record when you add new third-party mail services.

Ignoring reports from providers that do not honor your strict reject policy.

Expert tips

Use Suped to identify which specific mailbox providers are ignoring your p=reject instruction.

Implement SPF flattening to ensure your record never exceeds the ten-lookup limit.

Enable forensic reports to get samples of the actual emails attackers are sending.

Expert view

Expert from Email Geeks says that many attackers do not perform DNS lookups before sending because it is computationally cheaper to blast millions of emails and hope for the best.

2024-11-12 - Email Geeks

Marketer view

Marketer from Email Geeks says they noticed a significant increase in spoofing attempts specifically during the month of March across several high-value domains.

2024-03-15 - Email Geeks

Final thoughts on DMARC enforcement

While it may seem pointless for fraudsters to attack a hardened domain, their automated systems don't distinguish between a domain at p=none and one at p=reject. By maintaining a strict policy and using a tool like Suped, you ensure that these attempts remain nothing more than noise in your reports rather than threats in your inbox.