Why Your Emails Bounce With DMARC Failures When Both Sender and Receiver Use Proofpoint

The problem nobody expects

You run a Google Workspace domain with Proofpoint for outbound mail. Your SPF and DKIM are correctly configured. You send a message to a business partner who also uses Proofpoint for their inbound filtering. Your message bounces. The bounce says DMARC failed.

You check your own records: SPF passes, DKIM passes, your DMARC policy is set to reject. Everything looks right. But the bounce came from your partner's Proofpoint instance, applying their DMARC policy to mail that never aligned with their domain in the first place.

That is the catch-22. Both organizations have valid email authentication. Yet Proofpoint-to-Proofpoint delivery fails because neither side's Proofpoint instance can prove the mail originated from the domain in the From header.

DMARCFlow can surface these alignment failures through aggregate report monitoring before users start reporting bounces. If you send mail to other Proofpoint customers, DMARCFlow tells you which receiving domains are rejecting your mail due to alignment issues, letting you start the fix conversation proactively rather than waiting for a complaint.

Why Proofpoint breaks DMARC alignment

Proofpoint sits between the public internet and your corporate mail system. When it handles your outbound mail, it can modify the information that receiving mail servers use to evaluate SPF and DKIM.

Here is the specific sequence that causes the failure.

What you expect to happen

Your mail leaves your corporate network. Proofpoint receives it and sends it toward the recipient's mail server. The recipient's gateway checks SPF against your sending IP, checks DKIM against your domain's published key, and evaluates DMARC alignment using your From header domain. All checks pass because your authentication is correct.

What actually happens in many Proofpoint deployments

Proofpoint receives your mail, processes it, and may rewrite either the envelope sender (MAIL FROM) or the From header before forwarding. It also often signs outbound mail with its own DKIM key attached to Proofpoint's domain rather than your domain.

When the receiving gateway evaluates authentication:

- SPF check runs against Proofpoint's IP address, not yours - DKIM signature belongs to Proofpoint's domain, not yours - DMARC alignment checks whether the From header domain matches the domains used in SPF and DKIM results

Since Proofpoint's domain does not match your From header domain, alignment fails. The receiving gateway then applies its own DMARC policy to the misaligned message. If that policy is reject, the mail bounces.

This is not unique to Proofpoint. Any email security gateway that rewrites envelope information, From headers, or DKIM signatures can create the same situation.

How to diagnose the failure from the sender side

Before you can fix anything, you need to understand which domain's DMARC policy rejected the message and which authentication result caused the alignment failure.

Step 1: Read the bounce message

The bounce message usually contains a reason phrase. Look for text like "DMARC failure" or "Alignment failed." If the bounce comes from a domain that is not yours, that tells you the receiving gateway rejected the message based on its own DMARC policy.

Step 2: Examine the Authentication-Results header

This header is added by the receiving mail server and describes what authentication checks were run and what they returned. It looks like this:

Authentication-Results: receiving-gateway.com;
 dkim=fail (signature not aligned);
 spf=fail (sending IP not authorized);
 dmarc=fail (alignment failure)

If you see dkim=fail or spf=fail alongside dmarc=fail, check whether the domains listed are your domain or the gateway's domain. If they show the gateway's domain, the gateway is rejecting mail because it cannot establish that the mail came from your domain.

Step 3: Pull your own DMARC aggregate reports

If you receive DMARC reports from the receiving domain, they will show the source IP and authentication results from that domain's perspective. This tells you exactly what the receiving gateway saw when it evaluated your mail.

Step 4: Ask the receiving organization to check their Proofpoint logs

If you have a contact at the receiving organization, ask them to check their Proofpoint logs for the rejected message. They can tell you whether Proofpoint modified the mail in transit and which domain it was using for SPF and DKIM evaluation.

How to diagnose the failure from the receiver side

If your organization is the one receiving these bounces, you are applying your own DMARC policy to mail that arrives misaligned. Here is how to confirm that is what is happening.

Step 1: Check your quarantine or mail logs

Find the rejected message in your Proofpoint quarantine or logs. Look at the Authentication-Results header in the message metadata. If it shows dkim=fail or spf=fail for a domain you do not recognize, that domain's gateway is sending mail that has been rewritten.

Step 2: Identify the sending gateway

Cross-reference the sending IP in the logs with the domain shown in the failed authentication result. If the IP belongs to Proofpoint and the DKIM domain belongs to a different Proofpoint customer, you are seeing Proofpoint-to-Proofpoint relay behavior.

Step 3: Verify the From header domain is legitimate

If the From header shows a known business partner domain but authentication is failing for a different domain, you are likely blocking legitimate mail due to how that partner's gateway processes outgoing messages.

What the sender can do to fix it

Configure Proofpoint to preserve original SPF and DKIM

Proofpoint has configuration options that control whether it rewrites envelope information and DKIM signatures. If your Proofpoint instance is set to rewrite or resign mail, ask your Proofpoint administrator or support engineer whether you can switch to a passthrough or transparent mode that preserves the original authentication information.

In many Proofpoint deployments, this is controlled by the outbound relay configuration. The relevant settings are typically found under Email Protection > Inbound Configuration > Authentication, or in the outbound relay policy settings.

Work with the receiving organization to whitelist or bypass

If you cannot change Proofpoint's behavior immediately, ask the receiving organization to add your sending domain or IP to an approved senders list in their Proofpoint instance. This bypasses DMARC evaluation for your specific domain without weakening their overall policy.

Temporarily adjust your own DMARC policy

If neither of the above is immediately available, you can change your DMARC policy from reject to quarantine while you resolve the issue. This prevents bounces from blocking legitimate mail while you work on the fix. Do not leave it at quarantine indefinitely - restore full reject policy once the alignment issue is resolved.

Open a Proofpoint support ticket

If the root cause is Proofpoint's relay behavior and the above configuration options are not available to you, open a support case with Proofpoint. Ask specifically about DKIM passthrough and envelope sender preservation for outbound relay scenarios. Proofpoint's support team has addressed this specific issue before and can recommend configuration changes specific to your deployment.

What the receiver can do to fix it

Add the sending domain to an approved senders list

If you trust the sending domain and the misaligned authentication is a known artifact of their gateway, add their domain to an approved or trusted senders list in your Proofpoint configuration. This exempts their mail from DMARC evaluation without changing your overall policy.

Use a sending domain exception in your DMARC policy

Some organizations implement domain-level exceptions in their DMARC policy. This requires a custom configuration but allows specific trusted domains to bypass DMARC evaluation while maintaining full reject policy for all other mail.

Review message filtering rules

Proofpoint allows you to create message filtering rules that act before DMARC evaluation. You can configure a rule that identifies mail from known gateway IPs and applies a custom handling action that bypasses the DMARC reject policy.

Does this happen with other email security gateways

Yes. This is not a Proofpoint-specific flaw. Cisco IronPort, Microsoft Defender for Office 365 in certain relay configurations, Mimecast, and Hornetsecurity can all modify mail in transit in ways that break DMARC alignment. The underlying issue is that DMARC alignment requires the From header domain to match the domains used in SPF and DKIM results. Any intermediate system that changes those domains in transit can break alignment regardless of whether the original sender had valid authentication.

When you diagnose a Proofpoint-to-Proofpoint failure, you are building knowledge that applies to any gateway-to-gateway mail flow where alignment breaks down.

---

Frequently Asked Questions

Can Proofpoint-to-Proofpoint DMARC failures be completely prevented?

In most cases, yes. The fix is usually in the Proofpoint relay configuration. When Proofpoint is configured to preserve the original SPF and DKIM rather than rewriting them, alignment is maintained and mail flows normally.

Will changing my DMARC policy to p=none fix Proofpoint-to-Proofpoint failures?

No. The failure is caused by alignment, not by your policy setting. Changing to p=none only tells receivers not to reject mail that fails DMARC. It does not fix the underlying misalignment. The bounce stops but the underlying authentication problem remains.

Is this a problem with my DKIM configuration?

Not necessarily. Even if your DKIM is correctly configured for your own domain, Proofpoint may be signing with its own key and stripping or replacing yours. The receiving gateway then evaluates Proofpoint's DKIM signature against Proofpoint's domain, which does not align with your From header.

Does relaxed alignment mode solve this?

Relaxed alignment (the "l" tag in your DMARC record) allows subdomains to pass DMARC when the organizational domain matches. It does not help when the DKIM or SPF domain is a completely different domain (like Proofpoint's) rather than a subdomain of the From header domain.

Who should initiate the fix - the sender or the receiver?

Both sides need to be involved. The sender usually needs to configure their Proofpoint instance to preserve original authentication. The receiver may need to add the sender to an approved senders list or adjust filtering rules. Open communication between the two organizations is the fastest path to resolution.

Are there other security gateways that cause the same issue?

Yes. Cisco IronPort, Microsoft Defender for Office 365 in certain relay modes, Mimecast, and Hornetsecurity can all modify mail in transit in ways that break DMARC alignment. The fix approach is similar regardless of which gateway is involved.