Why Proofpoint Blocks Legitimate Email Citing DMARC

Your SPF record is correct. Your DKIM signature validates. And yet two counterparty domains that use Proofpoint for inbound email security have started rejecting your messages, with rejection notices citing DMARC failures.

This is a real scenario that appeared recently in a DMARC practitioner forum. A Google Workspace administrator with properly configured email authentication suddenly found their mail bouncing from Proofpoint-protected domains. The receiving domains had not changed anything. The sending domain had not changed anything.

The issue is not a broken configuration on either side. The issue is DMARC alignment, which is distinct from SPF and DKIM passing. Understanding the difference is the key to fixing it.

The first signal that something is wrong often does not come from your own systems. It comes from a counterparty complaint or a bounce message. The reason is that alignment failures do not appear in standard mail logs. They require DMARC aggregate reports to surface. Without a tool that actually parses and alerts on those reports, the first you hear about the problem is a bounced message or a help desk ticket.

The Difference Between Passing and Aligning

DMARC requires either SPF alignment or DKIM alignment to pass, not just the underlying authentication checks.

SPF alignment means the domain in the envelope sender (the Return-Path header) must match the domain in the From header. If your From header says example.com but your mail passes through a relay that rewrites the envelope to relay.example.net, SPF may technically pass but SPF alignment fails. DMARC sees two different domains and marks the message as failing.

DKIM alignment means the domain in the DKIM signature's d= tag must match the From header domain. If a security gateway or relay adds its own DKIM signature from its domain rather than yours, the signature is cryptographically valid but DKIM alignment fails. DMARC again sees a domain mismatch.

This is the mechanism that trips up organizations sending from Microsoft 365 or Google Workspace through Proofpoint-protected domains. The alignment check is separate from the authentication check. You can pass both SPF and DKIM while still failing DMARC if neither result aligns with your From domain.

How Proofpoint Triggers Alignment Failures

Proofpoint operates as an inbound MX gateway for the receiving organization. When mail flows through Proofpoint before reaching the internal mail system, several things can happen that break DMARC alignment for the sender.

Envelope rewriting: Proofpoint may rewrite the Return-Path for quarantine, suspicious, or processing purposes. If the rewritten envelope domain does not match the sender's From domain, SPF alignment fails.

Third-party DKIM signatures: If email passes through additional relay infrastructure before reaching Proofpoint, those relays may add their own DKIM signatures. A valid signature from relay.example.com does not align with your From domain, even if you also signed with your own DKIM key. Some receivers evaluate all DKIM signatures, and if none align, the message fails DMARC.

Direct injection bypassing MX: Some Microsoft 365 configurations send mail directly to the internet rather than routing through the organization's inbound MX. If the receiving domain's Proofpoint is not in the delivery path, the envelope may be set to M365's own routing domain, breaking alignment.

The Reddit case that triggered this article fits this pattern: a Google Workspace sender with proper DKIM, bouncing from Proofpoint-protected domains. The likely cause is that either the receiving Proofpoint infrastructure or an upstream relay is modifying envelope or DKIM information in a way that breaks alignment.

How to Diagnose Alignment Failures Using DMARC Reports

The fastest way to confirm this is the issue is to pull your DMARC aggregate reports and look for specific failure patterns.

Look for these indicators in the report:

SPF result: pass, SPF alignment: fail: This means SPF authentication passed, but the domain in the envelope sender (the Return-Path) did not match your From domain. In the XML, this shows as inside but the section shows fail.

DKIM result: pass, DKIM alignment: fail: This means a DKIM signature validated, but the signing domain (the d= value) does not match your From domain. In the XML, appears in auth_results but shows fail.

Receiving infrastructure: The report's or fields often reveal which security gateway or relay infrastructure handled the message. Proofpoint, Mimecast, and similar gateways appear as separate organizational names in the report.

Here is a simplified example of what alignment failure looks like in a DMARC report XML snippet:


  
  


  fail
  fail
  reject

The DKIM signature is valid, but it is from relay.example.com, not from your From domain. The SPF check passes for m365-relay.microsoft.com, but that is not your From domain either. Both fail alignment, and DMARC rejects the message.

Without DMARC aggregate reports, you cannot see this. Standard mail logs show a delivered or bounced message. They do not show that DMARC evaluated alignment and found the authenticated domain did not match the From domain. That is why reports matter for this class of problem specifically.

How to Fix DMARC Alignment Failures Through Proofpoint

Fixes exist on both the sending and receiving sides.

For the sending organization:

If you are using Microsoft 365 and sending mail directly to the internet rather than through your MX, you may be introducing an envelope mismatch. Configure M365 to use your MX infrastructure or a compliant relay as the smart host for outbound mail. This preserves the original envelope sender domain rather than replacing it with M365's routing domain.

If you use a third-party email gateway for inbound processing that also handles outbound relay, ensure it is configured to preserve the original envelope sender rather than substituting its own domain in Return-Path.

Check whether your upstream mail provider is adding DKIM signatures from its own domain in addition to or instead of your domain. If so, coordinate with them to ensure only your domain's DKIM signature is applied, or ensure any third-party signature uses a subdomain that aligns with your From domain.

For the receiving organization (if you control the Proofpoint instance):

Review Proofpoint's handling of Return-Path headers. If Proofpoint is rewriting Return-Path for messages that it processes rather than simply delivering, that rewrite breaks SPF alignment for the sender.

Check whether Proofpoint is adding DKIM signatures from its own domain. If Proofpoint signs outbound mail from its own domain for delivery tracking or other purposes, ensure this does not replace the sender's own DKIM signature.

If internal relay infrastructure is adding extra hops, evaluate whether those hops are necessary. Each hop that touches the envelope or adds a DKIM signature is a potential alignment failure point.

How to Monitor for This Issue Before It Causes Problems

This class of problem is exactly what DMARC aggregate reports are designed to surface. The key is actually receiving and reviewing those reports on a regular basis, not just at policy deployment time.

Set up automated ingestion of your DMARC reports. Look for sudden changes in alignment failure rates from specific receiving domains. A new spike in alignment failures from domains belonging to Proofpoint or similar gateway providers is an early warning sign that something has changed in how your mail is being processed.

The practical issue is that most organizations only look at DMARC reports when something breaks. By then a counterparty has already complained or mail has already bounced. DMARCFlow automates report ingestion and sends alerts when alignment failure patterns change, when new receiving domains appear in your reports, or when a previously stable sending relationship suddenly starts producing failures. The first indication of a Proofpoint alignment problem becomes an alert in your inbox rather than a complaint from a business counterparty.

This matters because the specific fix for alignment failures varies. Without automated monitoring, you do not know the fix worked until someone checks manually. With monitoring, you get confirmation the moment alignment failures drop back to zero.

FAQ

Our SPF and DKIM are both passing. Why is DMARC still failing?
DMARC requires alignment, not just passing. Both SPF and DKIM must pass and the authenticated domain must match the From header domain. A valid DKIM signature from Proofpoint's domain does not align with your From domain. A passing SPF result for a relay's domain does not align with your From domain either.

We did not change anything. Why did our email start failing suddenly?
The receiving domain may have changed their DMARC policy from p=none to p=quarantine or p=reject. Or their email gateway vendor may have changed how they handle envelope information or DKIM signatures. Check your DMARC reports for the exact failure mode and the timeline of when it started.

Can we ask the receiving domain to whitelist us?
Technically yes, but it is not a scalable solution and many organizations will not whitelist individual senders. The correct fix is to ensure your email infrastructure passes DMARC alignment. Whitelisting one domain at a time does not scale and does not address the underlying alignment issue.

We use Microsoft 365 and Proofpoint. What is the recommended setup?
Configure Microsoft 365 to route outbound mail through Proofpoint as the smart host, rather than sending directly to the internet. This ensures the envelope is preserved correctly throughout the delivery path. Alternatively, if Proofpoint handles only inbound mail, ensure your outbound path does not introduce envelope rewriting that breaks alignment.

What This Means in Practice

The root cause of DMARC alignment failures through Proofpoint is almost always a mismatch between the domain that authenticated the message and the domain in the From header. This is not visible from standard mail logs. It requires DMARC aggregate reports to diagnose.

The fix requires ensuring that either SPF or DKIM authenticates using your From domain, not a relay or gateway domain. In practice, this means auditing your mail relay infrastructure, coordinating with your email gateway vendors, and verifying that your DKIM signing happens at the authoritative MTA rather than at an intermediate hop.

Once alignment is established, the problem does not recur unless something in the delivery path changes again. Monitoring your DMARC reports after the fix confirms that alignment failures have stopped and that no new failure patterns have appeared. Setting up automated DMARC report monitoring means the next time something shifts in your mail delivery path, you know about it before your users do.