Blog · Dmarc
Why Proofpoint Breaks DMARC Alignment and How to Fix It
What is DMARC alignment and why it matters
DMARC alignment is the step that determines whether a message actually comes from the domain it claims to come from. When a receiving mail server checks a message, it verifies SPF and DKIM independently, but DMARC then asks a second question: do the domains in those results match the domain in the From: header?
There are two alignment modes. Relaxed alignment accepts any subdomain of the organizational domain. Strict alignment requires an exact match. Most organizations use relaxed alignment because it is more forgiving, but it still requires the RFC5321.MailFrom domain to have a recognizable relationship to the From: header domain.
This distinction matters because Proofpoint rewrites exactly that RFC5321.MailFrom domain during mail processing.
How Proofpoint rewrites Return-Path and breaks DMARC alignment
When an email passes through Proofpoint, Proofpoint substitutes its own infrastructure for the RFC5321.MailFrom domain. This is a core part of how Proofpoint handles delivery logistics.
Here is the specific sequence:
1. Your mail server hands a message to Proofpoint with your domain in the RFC5321.MailFrom
2. Proofpoint processes the message and delivers it through its own relay infrastructure
3. The receiving server sees Proofpoint's infrastructure as the RFC5321.MailFrom, not yours
4. When the receiving server checks DMARC alignment, it compares Proofpoint's domain against your From: header domain
5. Alignment fails, and the message is rejected or quarantined
The receiving DMARC checker never sees your original MailFrom domain. It only sees what Proofpoint left behind.
This is not a bug. It is expected behavior for any SEG that handles delivery logistics. But it creates a specific failure pattern that is easy to spot in DMARC reports if you know what to look for.
How to diagnose Proofpoint DMARC failures in your aggregate reports
Open your DMARC aggregate report and look for this exact pattern:
- SPF result: pass
- DKIM result: pass
- DMARC result: fail
SPF and DKIM both passing but DMARC failing always means alignment is the problem. The next question is why.
When Proofpoint is the cause, you will also see the connecting IP address belongs to Proofpoint's infrastructure, not your own mail servers. The sending domain in the report may show a Proofpoint-owned domain rather than your own.
Without a tool like DMARCFlow that monitors your DMARC reports continuously, you may not catch this pattern until users start reporting that their messages are not getting through. Proofpoint alignment failures are invisible to standard mail queue monitoring. Your queues look healthy. SPF and DKIM checks pass. The failure only shows up in DMARC reports, which most organizations do not check proactively.
This is why DMARCFlow is useful here specifically: it alerts you when your DMARC failure rate spikes, often before the problem surfaces in user complaints. If the spike coincides with a Proofpoint update or configuration change, you have your cause.
Why Proofpoint-to-Proofpoint routes show the problem most clearly
The problem is most visible when both the sender and the receiver use Proofpoint. When Organization A sends to Organization B, both running Proofpoint, Organization B's receiving infrastructure sees Organization A's Proofpoint relay in the RFC5321.MailFrom. Because both organizations use Proofpoint, the receiving server may apply additional scrutiny to the connecting relay. The result is a DMARC alignment failure that looks like a security incident but is actually an infrastructure artifact.
Gmail and Yahoo have become stricter about DMARC alignment over time. This means Proofpoint alignment issues are more likely to surface as rejections or spam folder routing with those receivers, even when the mail flow has not changed on your end.
Four ways to fix Proofpoint DMARC alignment issues
Option 1: Adjust your DMARC policy with pct to test gradually
If you cannot reconfigure Proofpoint immediately, add or adjust the pct tag in your DMARC record:
v=DMARC1; p=reject; pct=50; rua=mailto:reports@example.com
This causes 50 percent of failing messages to be rejected, letting you measure the impact before going to 100 percent. Lower pct values give you more headroom to observe. DMARCFlow can help you track whether the pct change is reducing failures or just shifting them.
Option 2: Configure Proofpoint to preserve your Return-Path
Some Proofpoint deployments can preserve the original RFC5321.MailFrom rather than substituting Proofpoint's own domain. This is a configuration change that requires Proofpoint admin access and may depend on your license tier. Contact Proofpoint support and ask specifically about alignment-preserving relay mode.
Option 3: Use a dedicated subdomain for Proofpoint-originated mail
Set up a sending subdomain specifically for mail that originates through Proofpoint, with its own relaxed DMARC record:
v=DMARC1; p=none; rua=mailto:reports@example.com
This subdomain carries no reject policy, so Proofpoint rewrites do not cause alignment failures. Your primary domain keeps its full DMARC policy. This approach requires coordination with your email team to ensure Proofpoint routes mail for this subdomain through the dedicated infrastructure.
Option 4: Engage Proofpoint support for alignment-preserving configuration
If the above options are not viable, open a support case and reference the Return-Path rewrite behavior specifically. Ask whether your current deployment supports passing the original MailFrom domain through to the receiving server. Proofpoint is aware of this issue and has documented it, but the fix depends on your specific configuration.
FAQ
Does SPF pass if Proofpoint is in my SPF record?
Yes, SPF checks the RFC5321.MailFrom domain at the time of delivery. If Proofpoint is in your SPF record, SPF can still pass. But DMARC alignment checks the relationship between the MailFrom and the From: header, and that relationship is broken when Proofpoint rewrites the MailFrom.
Does DKIM help with this problem?
DKIM signs the message body and selected headers at the time of signing. If Proofpoint does not modify the From: header or body, DKIM can still pass. But if DMARC alignment mode requires DKIM alignment and Proofpoint does not preserve the original DKIM signing domain, DKIM alignment can also fail.
Can I just use p=none instead of p=reject?
You can, but p=none provides no protection and stops DMARCFlow from alerting you to failures. If you want meaningful protection while managing risk, p=quarantine or p=reject with pct is better. Use pct to test gradually if you are concerned about mail breakage.
Is Proofpoint the only SEG that causes this?
No. Any SEG that rewrites the RFC5321.MailFrom domain can cause this problem. Proofpoint is the most commonly discussed because it is widely deployed in enterprise environments. Other SEG products that handle delivery logistics can produce the same failure pattern.