Why Third-Party Email Security Gateways Cause Sudden DMARC Failures on Legitimate Mail

You set up DMARC. Your aggregate reports looked clean. Your policy is set to reject and mail is flowing. Then your help desk starts getting reports that some legitimate mail is not arriving. You check your DMARC record. It has not changed. You check your SPF and DKIM. Both look fine. The problem is somewhere in the middle, and the middle is your email security gateway.

Third-party email security gateways are a common source of silent DMARC breakage. They sit between your mail servers and the outside world, and they modify messages in transit. Some of those modifications are invisible to users but visible to DMARC authentication checks. When the modification breaks the alignment between your From header and your SPF or DKIM result, receivers apply your p=reject policy to mail that should have passed.

The first sign of this problem is usually not a user complaint. It is a spike in your DMARC aggregate report failures. Monitoring those reports with DMARCFlow is typically how you catch it before the help desk does.

This is not a bug in your DMARC setup. It is a side effect of how some gateways relay mail. Here is what is happening and what to do about it.

What Is Happening and Why It Matters

Your DMARC policy tells receivers how to handle mail that claims to be from your domain. For DMARC to pass, the mail must satisfy either SPF alignment or DKIM alignment. Alignment means the domain in the From header matches the domain in the SPF check or the domain in the DKIM signature.

When a third-party gateway relays your mail, it may modify the message in ways that break one or both of those alignments. The result is DMARC failure even though the mail is genuinely from your domain and genuinely legitimate.

The problem usually surfaces without warning. Your gateway vendor may push a product update that changes relay behaviour. Your aggregate reports were fine last month. This month, some of your legitimate mail starts failing DMARC at receivers that enforce it strictly.

The Two Ways a Gateway Breaks DMARC Alignment

From-Header Rewriting

Many gateways rewrite the From header to show their own domain or a generic support domain instead of your original sending domain. This is often done for tracking or routing purposes. When the From header shows example-gateway.com instead of yourdomain.com, DMARC alignment fails immediately. The From header domain no longer matches your SPF domain or your DKIM signing domain.

Some gateways do this only for certain message types, such as automated notifications or password reset emails. That is why the failure sometimes affects only a subset of your mail.

Envelope-From Mismatch

The SMTP envelope-from (also called the return-path or MAIL FROM) is the address used for bounces. When your gateway forwards your mail, it may set the envelope-from to its own relay domain rather than preserving your original sending domain.

Even if the From header is unchanged, a mismatch between the envelope-from and the From header causes alignment failures for SPF-based DMARC. The receiver checks SPF on the envelope-from domain, which no longer matches your From header domain.

DKIM is unaffected by envelope-from changes because DKIM validates the message content, not the envelope. That is why some organisations see DKIM passing while SPF fails for the same message.

How to Diagnose the Failure From Your Aggregate Reports

Your DMARC aggregate reports contain the evidence. Look for these patterns:

In the auth_results section, you will see SPF or DKIM results listed with a domain that does not match your From header domain. For example, SPF may show pass for gateway-relay.com instead of yourdomain.com. Or DKIM may show a signature from gateway-relay.com.

In the policy_evaluated section, you will see fail for alignment on SPF, DKIM, or both. The disposition field will show reject or quarantine even though the mail came from your legitimate sending infrastructure.

Here is what a simplified failure record looks like:

  
    198.51.100.42
    47
    reject
  
  
    
    
    
  

In this example, SPF passes but the SPF domain is gateway-relay.com, not yourdomain.com. DMARC alignment fails on SPF. DKIM passes and is aligned with yourdomain.com. With p=reject, this mail is rejected because SPF alignment fails, even though DKIM alignment passes.

The connecting IP in the record will be the gateway relay IP, not your own mail server IP. This tells you the mail originated from the gateway infrastructure.

Three Ways to Fix It

Fix 1: Configure the Gateway to Preserve the From Header

Most enterprise gateway products have an option to preserve the original From header. This is the cleanest fix because it keeps your DMARC alignment intact without requiring changes to your DNS or authentication setup.

Check your gateway documentation for From header rewriting settings. Some vendors call this header transparency, sender preservation, or direct relay mode. If your vendor does not support preserving the From header, that is a significant gap worth escalating with them.

Fix 2: Set Up DKIM Cosigning With the Gateway

If the gateway must modify messages, you can add a DKIM signature from the gateway domain alongside your existing DKIM signature. Your original DKIM signature still covers your From header domain. The gateway adds its own signature. When the message reaches a receiver, one of the two aligned DKIM signatures will satisfy DMARC alignment.

There are two ways to do this:

Option A: Add the gateway's DKIM selector to your DNS. Some gateways generate their own DKIM keys and ask you to publish their selector as a TXT record on your domain. This is the more common approach for hosted gateway products.

Option B: Have the gateway sign with your DKIM selector directly. This requires sharing your private key with the gateway, which has security implications. It is simpler operationally but requires careful key rotation and access controls.

Fix 3: Add the Gateway IP to Your SPF Record

If the envelope-from mismatch is the problem and the gateway will not change it, you can add the gateway relay IPs to your SPF record. This makes the gateway an authorised sender for your domain, and SPF alignment will pass.

Be careful with this approach. Adding IPs to your SPF record means those IPs are explicitly authorised to send mail on behalf of your domain. If the gateway configuration changes or is compromised, mail can appear to come from your domain with your blessing. Keep your SPF record tightly scoped to only the IPs you actually use.

How to Stop It From Happening Again

The root cause of most sudden DMARC failures from gateways is a product update on the vendor side that changed relay behaviour. Without notice. After you fix the immediate problem:

Add your gateway IPs to your monitoring scope. Even before you add them to SPF, know what IPs your gateway uses for relay. Changes in those IPs will show up in your aggregate reports before they cause widespread failures.

Set up alerts on DMARC failure rates. A sudden increase in DMARC failures for a specific source IP is usually the first sign of a gateway problem. DMARCFlow monitors your aggregate reports continuously and alerts you within hours of a spike, rather than waiting for users to report missing mail.

Review your gateway configuration after any product update. Gateway vendors push updates frequently. After any change to your gateway software, check your aggregate reports within 24 hours to confirm alignment is still passing.

Consider the long-term architecture. If your gateway cannot preserve From header transparency, it will continue to be a source of DMARC risk. This may be a reason to evaluate alternative gateway products or to move toward a model where your primary mail infrastructure handles authentication natively.

How DMARCFlow Helps You Catch This Faster

The hardest part of gateway-related DMARC failures is detecting them quickly. By the time users report missing mail, the problem has usually been running for hours or days. Your aggregate reports contain the evidence, but reviewing them manually takes time.

DMARCFlow monitors your aggregate reports continuously and alerts on anomalies. A sudden spike in alignment failures for mail from a specific relay IP is exactly the pattern that triggers an alert. You find out about the problem from your monitoring system rather than from your help desk.

Once alerted, you can identify the gateway IP from the failure pattern and engage your vendor while mail is still flowing through alternative channels. The aggregate reports also tell you exactly which From header domains are affected, which helps the vendor reproduce and fix the issue faster.

If you do not have RUA reports configured, start there. Without visibility into your aggregate reports, you are relying on users to tell you when legitimate mail stops arriving. That is not a reliable monitoring strategy.

FAQ

Does Proofpoint break DMARC?

Proofpoint does not inherently break DMARC, but Proofpoint relay configurations that rewrite the From header or use a mismatched envelope-from cause DMARC alignment failures. Proofpoint has settings to preserve sender identity and supports DKIM cosigning. The failure usually comes from a specific configuration or a product update that changed relay behaviour. Check Proofpoint documentation for header preservation settings.

Can I use a third-party email security gateway with DMARC enforcement?

Yes, but the gateway must be configured to preserve your From header or to cosign DKIM. A gateway that rewrites the From header without cosigning will cause DMARC failures for any domain with a reject or quarantine policy.

My DKIM passes but my SPF fails for mail going through the gateway. Why?

This is the classic symptom of an envelope-from mismatch. The gateway changes your envelope-from to its own domain while preserving your From header and your DKIM signature. SPF checks the envelope-from domain against your DMARC record, so it fails. DKIM checks the DKIM-signed domain against your From header domain, so it passes when aligned. The fix is to either preserve the envelope-from or add the gateway IP to your SPF record.

How do I know if my gateway is rewriting the From header?

Send a test message through the gateway and examine the raw message headers on the receiving end. Look for the From header in the message body and compare it to what you sent. If the domain has changed, your gateway is rewriting headers. Your DMARC aggregate reports will also show this as SPF or DKIM alignment failures for the gateway relay IPs.

How do I prevent my gateway from breaking DMARC in the future?

Configure your gateway to preserve the From header or to cosign DKIM before deploying any DMARC policy above p=none. After any gateway product update, review your aggregate reports within 24 hours to confirm alignment is still passing. Set up automated monitoring on your aggregate reports rather than reviewing them manually.