Why DMARC p=reject Does Not Block Mail

The confusion starts here

You published DMARC p=reject. You expected mail fraud to stop. You still see DMARC failures in your aggregate reports and nothing seems different. That is not a sign your policy is broken. It is a sign you expected the wrong thing.

p=reject does not block mail from your server. It tells receiving mail servers what to do with mail that fails your DMARC checks. Your server never touches the decision. The receiving server does.

How DMARC p=reject actually works

Here is the sequence when a legitimate message gets through:

Your server submits a message to a recipient at example.com
Your message passes SPF, passes DKIM, and the From domain aligns with your sending domain
example.com checks your DMARC DNS record and sees p=reject
example.com sees authentication passing and delivers the message

Here is what happens with a forged message:

An attacker sends email claiming to be from your domain
The attacker has no access to your SPF or DKIM credentials
The receiving server checks SPF and DKIM -- both fail
The receiving server reads your DMARC policy and sees p=reject
The receiving server rejects the message
Your server submitted the message successfully and never hears about the rejection

The rejection happens at the receiving infrastructure. Your mail server treated the submission as successful. The outcome only shows up later in your aggregate reports.

Why failures still appear in your aggregate reports

Aggregate reports are not delivery confirmations. They are authentication logs. They tell you what mail servers observed when they checked your domain, not whether the messages landed in inboxes.

When you see a DMARC failure, it means one of two things:

A legitimate message failed authentication because of a forwarding issue or a misconfigured sending platform
Someone sent a forged message and the receiving server correctly rejected it

Both look identical in the raw report. The difference is visible only in the source IP and the DKIM selector used. Parsing that manually from dozens of provider reports is exactly the problem that makes DMARC feel useless to people who have not built the habit.

When p=reject genuinely does not work

p=reject is not a guarantee. There are specific, common cases where it fails to protect you.

Forwarded mail. When Gmail forwards a message to another provider, the final receiver sees the mail coming from Google's IP addresses, not yours. SPF fails because the IP does not match your domain. DKIM may survive if Google does not strip the signature. DMARC alignment fails because theEnvelope From and the From header do not match what the receiver expects from Google's relay. The result is a DMARC failure on a message you legitimately sent.

Allowlisted senders. Some corporate mail systems maintain internal allowlists that predate their DMARC implementation. A receiver may have added your domain to an allowlist years ago and still accepts mail from it regardless of DMARC status. Safe sender lists in Outlook and Gmail can override p=reject for authenticated users in certain configurations. This is not a theoretical edge case. DMARCFlow has seen it in aggregate reports from enterprise Exchange deployments.

Receivers who interpret p=reject as advisory. The DMARC RFC allows receivers to treat p=reject as p=quarantine in certain circumstances. Some receivers do this for internal trusted senders, for example, or for certain forwarding scenarios. A p=reject policy does not force uniform behavior across all mail providers.

Mailing lists. Most mailing lists repackage messages and send them from their own infrastructure. The From header still shows the original sender, but the mail originates from the list server. SPF fails. DKIM may or may not survive depending on whether the list modifies the message body. DMARC alignment fails. Many lists work around this by requesting that senders set p=none, or by using a custom From header that shows the list name rather than the original sender.

What to monitor instead

Stop waiting to see blocked mail in your sent folder. Your server does not have a blocked folder because no blocking happens there. Instead, watch your aggregate reports for three concrete numbers:

Aligned pass rate. What percentage of mail claiming to be from your domain passes both SPF and DKIM in alignment? A well-configured domain sending through a single platform should be above 95 percent. If your pass rate is below 90 percent and you have not changed your sending setup, something is misconfigured. If it drops suddenly from a high baseline, something changed.

Failure source breakdown. Which source IPs are generating the failures? If failing IPs are your own sending infrastructure -- your marketing platform, your CRM, your help desk -- those are configuration problems to fix. If failing IPs are cloud hosting ranges, consumer ISPs, or IP ranges you do not recognize, those are spoofing attempts your policy is blocking. You want to see failures from the second group and zero failures from the first.

Trend changes, not absolute values. A single aggregate report snapshot is nearly useless. What matters is whether your aligned pass rate is changing week to week. A 5 percent drop in aligned pass rate over 7 days means something in your sending infrastructure changed. A 5 percent spike in unaligned failures from a new IP range means someone started spoofing your domain at scale.

DMARCFlow collects and parses aggregate reports from Gmail, Microsoft 365, Yahoo, and other major receivers, normalizes the data, and alerts you when your pass rate changes by more than a configurable threshold. For most teams, that is the difference between checking DMARC reports occasionally and actually knowing whether your policy is working.

How to test whether p=reject is working

Send a test message to a Gmail address and a Microsoft 365 address using your own domain as the From address. Use your primary sending infrastructure -- do not test from a workstation with a desktop mail client. Check your aggregate report 24-48 hours later.

A passing test looks like this: your own legitimate sending IPs show aligned passes in the report. You see zero failures from those same IPs.

A failing test looks like this: your own IPs appear in the failures section. That means your DKIM signing is broken, your SPF is misconfigured, or your sending platform is not using your domain's aligned DKIM selector.

Common causes of your own IPs appearing in failures:

Your CRM or marketing platform sends from its own domain, not yours, and has not been DKIM-signed with your domain

You changed your DKIM selector and the new record has not propagated

You have multiple sending platforms with different DKIM configurations and one of them is misconfigured

Fix legitimate failures before you trust p=reject to block external spoofing.

DMARC p=quarantine vs p=reject -- which should you use

p=quarantine tells receiving servers to mark failing mail as spam. p=reject tells them to refuse it outright.

The practical difference: p=quarantine is safer if you are not certain all your legitimate sending infrastructure is properly authenticated. p=reject is what you want once you have confirmed everything is aligned. It is the only policy that reliably stops domain spoofing.

The rollout path most organizations follow:

Set p=none and read aggregate reports for 30 days. Build a baseline of what your normal pass rate looks like.
Move to p=quarantine and watch for 30 days. Fix any legitimate mail that starts landing in spam.
Move to p=reject once your aligned pass rate is above 95 percent and stable.

Skipping steps because you want results faster is how you end up with a broken email pipeline and a DMARC report you cannot interpret because you never built the baseline to compare against.

FAQ

Does p=reject stop all email spoofing of my domain?
No. It protects your exact domain from direct spoofing. It does not protect misspelled variants, lookalike domains such as yourdomain.com vs yourdmain.com, or subdomains you have not secured with your own DMARC policy. It also does not protect you if an attacker compromises a legitimate sender's infrastructure and sends from there.

Can I see when messages are rejected because of my p=reject policy?
No. Receiving servers do not send rejection notifications to the sending domain. You infer rejections from aggregate reports by comparing your sending IPs against the IPs generating failures. If failing IPs are not yours, your policy is blocking something.

My aggregate report shows failures but my policy seems to be working. How do I tell the difference?
Look at the source IP for each failure. If the IP belongs to your own sending infrastructure, that is a configuration problem on your side. If the IP is from a cloud provider, hosting company, or ISP you have never used, that is an external spoofing attempt being blocked. The outcome is good in both cases -- but the action you take is different.

I use Google Workspace and Microsoft 365. Do they automatically enforce p=reject?
Both enforce DMARC for mail received by their hosted services. They also generate and send aggregate reports. The quality of enforcement depends on your DKIM configuration within those platforms. If you have not set up DKIM signing in Google Workspace or Microsoft 365, neither provider has a valid DKIM signature to validate, and DMARC validation falls back to SPF only.

Can I set different DMARC policies for different subdomains?
Yes. DMARC policies apply independently per domain. You can set p=reject for your root domain and p=none for subdomains used by marketing platforms, transactional email services, or internal tools that send through shared infrastructure. This is standard practice for organizations that use multiple sending platforms.

How long does it take for a DMARC policy change to take effect?
DMARC policies are read from DNS, so they take effect as soon as the DNS record propagates -- typically within minutes, but up to 24-48 hours depending on TTL settings. Aggregate reports, however, reflect a retrospective view. Gmail, Microsoft 365, and Yahoo send aggregate reports daily or less frequently, so you may not see the effect of a policy change for 24-72 hours in your first report.