Why Proofpoint Breaks DMARC When You Move to p=reject

Your SPF record is correct. Your DKIM is signing. Your DMARC policy is set to p=reject. And now Google, Microsoft, and Yahoo are rejecting your legitimate outbound mail. What went wrong?

The culprit is probably your email security gateway.

Third-party email security gateways - Proofpoint, Mimecast, Barracuda, Cisco IronPort, and similar platforms - sit between your mail server and the internet. They scan mail for threats, apply data loss policies, and then forward the processed mail to its destination. That relay behavior is what breaks DMARC.

How Gateways Break DMARC Alignment

DMARC has two authentication mechanisms that must both pass for a message to be considered legitimate: SPF alignment and DKIM alignment.

SPF alignment checks whether the IP address sending the mail is authorized by your SPF record. When your mail goes through a gateway, the gateway's IP address is the one connecting to the receiver - not your mail server's IP. If your SPF record only lists your own server IPs, the gateway's IP fails SPF alignment.

DKIM alignment checks whether the message was signed by a domain that matches your From address. Some gateways strip or rewrite the original DKIM signature during processing. Others add their own signature but from a different domain. Either way, DKIM alignment fails.

At p=none, both failures are logged in your DMARC aggregate reports but no action is taken. At p=reject, receivers enforce the policy and refuse the mail. The problem was always there. You just could not see it until enforcement started.

This is where aggregate report monitoring becomes critical - and where DMARCFlow provides the most value. At p=none, your reports likely showed SPF and DKIM failures for months, but those failures were silent. DMARCFlow's reporting surfaces those failures by source IP, domain, and receiver, making it obvious which sending infrastructure is misaligned before you move to enforcement.

Why p=none Hides the Problem

When your DMARC policy is p=none, you are in monitoring mode. Receivers accept your mail regardless of whether SPF or DKIM pass, and they send you aggregate reports summarizing authentication results. If you looked at those reports, you might have seen SPF and DKIM failures for months - but because no mail was being rejected, there was no urgency to investigate.

Once you move to p=reject, receivers start refusing mail that fails authentication. If your gateway is not configured to preserve or replace authentication headers, legitimate mail starts bouncing.

How to Diagnose Gateway-Caused DMARC Failures

Look at your DMARC aggregate reports. Find a message that was sent through your gateway but is now being rejected. Check the source IP address in the failure record. If that IP belongs to your gateway vendor - not your own mail servers - you have identified the problem.

For example, Proofpoint uses ranges like 104.18.0.0/23 and 172.64.0.0/13 according to their published infrastructure documentation. If your aggregate reports show failures from these ranges for mail you know is legitimate, the gateway is the cause.

This diagnostic step is exactly what DMARCFlow automates. Rather than manually reviewing raw XML aggregate reports, DMARCFlow normalizes failure data and shows you a ranked list of sending sources by alignment failure rate. If your gateway appears at the top of that list, you know it needs configuration before any enforcement change.

Fix Option 1: Configure the Gateway to Preserve Authentication

The cleanest fix is to configure your gateway to relay mail in a way that maintains the original authentication results. This is sometimes called "transparent mode," "DMARC passthrough," or "authentication preservation mode" depending on the vendor.

Not all gateways support this. Proofpoint calls this "Direct Forwarding" in some configurations. When enabled, the gateway inspects mail but forwards it from the original sender's infrastructure rather than its own, preserving SPF alignment.

Check your gateway documentation for settings related to:

Transparent relay or DMARC passthrough

Authentication header preservation

Direct forwarding vs. store-and-forward mode

Fix Option 2: DKIM Signing at the Gateway Level

If the gateway must relay mail from its own infrastructure, configure it to sign outbound mail with your domain's DKIM key. This means adding a DKIM record for the gateway's selector, using the gateway's DKIM private key to sign mail, and ensuring the gateway's selector domain matches your From domain.

This turns the gateway into an authorized sender under your DMARC policy. When the gateway signs with your domain's DKIM key, DKIM alignment passes regardless of which server physically sends the mail.

Proofpoint supports this through their "Domain Keys" configuration. You generate a DKIM key pair, add the public key as a DNS TXT record, and configure Proofpoint to use the private key for signing.

Fix Option 3: Move to p=quarantine First While You Fix Alignment

If neither of the above is immediately feasible, set your DMARC policy to p=quarantine as a temporary measure. This directs receivers to mark failing mail as spam rather than rejecting it outright. You get a grace period to fix gateway alignment without creating a mail delivery emergency.

Monitor your aggregate reports daily during this period. DMARCFlow's daily digest reports help you track alignment changes over time, so you can validate that all legitimate sending sources are passing before moving to p=reject.

Fix Option 4: Route High-Priority Mail Directly

For transactional mail, automated alerts, or any mail that cannot afford delivery delays, consider routing these flows directly to the internet without gateway relay. Apply your security scanning at the point of message creation instead of at the point of delivery.

This approach adds operational complexity and is not a substitute for fixing the underlying alignment problem. Use it as a temporary measure for critical mail flows while you work on the gateway configuration.

FAQ

Does this problem occur with all security gateways?

No. It depends on how the gateway is configured. Gateways that operate in transparent or direct-forwarding mode generally preserve authentication. Gateways that operate in store-and-forward relay mode - where they receive mail, process it, and then send it from their own servers - typically break alignment unless explicitly configured to preserve or replace authentication headers.

Can I use p=quarantine instead of p=reject if my gateway breaks alignment?

Yes. p=quarantine is a valid intermediate step. Mail that fails authentication is marked as spam rather than rejected, giving you time to fix the gateway configuration. Do not move to p=reject until aggregate reports show full alignment for all legitimate sending sources.

How do I check if my gateway is causing DMARC failures?

Review your DMARC aggregate reports for the past 30 days. Look for SPF and DKIM failures on mail that you know was legitimate. Note the source IP addresses in those failure records. If those IPs belong to your gateway vendor instead of your own mail servers, the gateway is causing the failures. DMARCFlow automates this by grouping failures by sending source and flagging gateway IPs that appear in your authentication data.

Can I configure Proofpoint to preserve DKIM signatures?

Yes. Proofpoint supports DKIM signing for outbound mail through its Domain Keys configuration. You generate a DKIM key pair, publish the public key as a DNS TXT record, and configure Proofpoint to sign with the private key. This makes Proofpoint an explicitly authorized sender under your DMARC policy. Consult Proofpoint's documentation for your specific version for step-by-step instructions.

What DMARC record settings help when using a relay gateway?

Set p=quarantine while fixing the configuration. Use the "rua" tag to receive aggregate reports by email. Consider using "pct" to gradually move a percentage of traffic to p=reject while you validate alignment. The "fo" tag can be set to "1" to request failure reporting for individual messages, which gives you faster feedback than aggregate reports alone.

Does moving to p=reject always cause mail rejection if I use a gateway?

No. If your gateway is correctly configured - either in transparent mode or with DKIM signing - your mail will pass authentication and be delivered normally. The rejection only happens when the gateway relays mail without preserving or replacing authentication, causing both SPF and DKIM alignment to fail.