Why Your Email Security Filter Keeps Rejecting Legitimate Messages (And How to Fix DMARC)

Your email passes SPF. It passes DKIM. Yet the recipient's server rejects it, citing DMARC failure. The reason is almost always the same: the third-party email security filter in your mail path is breaking DMARC alignment without you realizing it.

This is one of the most common DMARC problems that does not get enough clear coverage. Here is what is actually happening and what you can do about it.

What DMARC Alignment Actually Checks

DMARC is stricter than SPF or DKIM alone. It does not just verify that an email is authorized. It verifies that the domain in the From header matches the domain that authorized the email via SPF or DKIM. This matching requirement is called alignment.

There are two alignment modes:

• Relaxed alignment: the organizational domain must match, but subdomains can differ. If your From address is newsletter@example.com and the SPF or DKIM domain is example.com, relaxed alignment passes.
• Strict alignment: the domains must match exactly. newsletter@example.com must have SPF or DKIM also scoped to newsletter@example.com, not just example.com.

When a third-party email security filter processes your email, it often rewrites parts of the message or introduces its own sending infrastructure. This breaks the alignment chain.

How Does SEG Relaying Break DMARC Alignment?

A typical enterprise mail flow with a third-party email security gateway looks like this:

1. Your mail server sends an email with From: user@example.com
2. The email arrives at Proofpoint (or Mimecast, Cisco IronPort, etc.)
3. The SEG processes it, may rewrite headers or content, and forwards it to the recipient
4. The recipient's server evaluates DMARC

The problem emerges in step 3. Many SEG products, by default, send the forwarded email using their own domain in the SMTP envelope, not yours. The DKIM signature they apply is their domain's DKIM key, not yours. The SPF check passes against the SEG's IPs, not your mail server.

The recipient's DMARC check then sees:

• From header: example.com


• SPF domain: seg-vendor.com (or a subdomain)


• DKIM domain: seg-vendor.com

example.com does not align with seg-vendor.com. DMARC fails, even though your original email was fully authenticated.

This is called the forwarder DMARC problem, and it is distinct from simple SPF or DKIM failures.

Why Does It Seem Inconsistent Across Recipients?

One of the most confusing aspects of this problem is that it is not consistent across all recipients. Some domains accept the forwarded email. Others reject it. Some enforce DMARC p=reject. Others use p=quarantine. And some do not enforce DMARC at all.

This inconsistency makes debugging harder. You may have a marketing email that works fine for Gmail and Microsoft 365 recipients but gets rejected by financial institutions or government domains that enforce stricter DMARC policies. That pattern is a hallmark of SEG-related DMARC failures.

One DMARCFlow customer saw their marketing email rejected by a specific banking group at a rate of roughly 30% during a campaign because the bank's DMARC policy was p=reject while other major providers were still at p=quarantine. The SEG had been relaying their DKIM signatures, not their own.

How to Diagnose Which Mailstream Is Failing

The fastest way to identify the problem is to look at your DMARC aggregate reports. Most organizations with DMARC published receive these reports from major email providers. If you are not receiving them, start there.

In your DMARC reports, look for entries where:

• The DKIM result shows "pass" but the aligned domain does not match your From domain


• The SPF result shows "pass" but the aligned IP belongs to a vendor, not your mail servers


• Failures are coming from specific destination domains that you know use strict DMARC

If you see DKIM signatures from your SEG vendor's domain in the failure reports, that is a clear signal. The SEG is signing outbound email with its own domain, not yours.

DMARCFlow's aggregate reporting helps here by pulling DMARC failure data into a unified view, making it easier to spot which specific mailstreams are causing alignment failures without manually parsing XML reports from dozens of recipients. You can filter by DKIM domain, source IP, and destination domain to isolate the SEG relay case from other failure modes.

Practical Fixes for SEG-Related DMARC Failures

There are three main approaches, depending on your SEG vendor and your level of control over its configuration.

Fix 1: Align the SEG's sending domain with your organizational domain

Some SEG products allow you to configure them to send using your domain rather than their own infrastructure. This requires proper DKIM signing setup where you provide the SEG with DKIM keys for your domain. When the SEG then signs outbound email using your domain's DKIM key, DMARC alignment passes because the From domain and the DKIM signing domain now match.

This is the cleanest solution. It requires coordination with your SEG vendor and potentially your DNS administrator to publish the right DKIM records.

Fix 2: Use SRS (Sender Rewriting Scheme) to preserve your domain through the relay

SRS modifies the Return-Path envelope so that SPF checks pass against your domain even after the SEG has relayed the message. This does not directly fix DKIM alignment, but it helps when the failure mode is SPF-related.

Not all SEG vendors support SRS, and it has its own complications with mailing list forwarding. For one-to-one corporate email relay scenarios, it can be effective.

Fix 3: Configure the SEG to forward without modifying DMARC-related headers

Some SEG products have a configuration mode where they relay email without rewriting the envelope or applying their own DKIM signature. The original authentication results from your mail server carry through to the recipient. This works best when your own mail infrastructure already has strong SPF, DKIM, and DMARC in place.

Fix 4: Temporarily adjust your DMARC policy to relaxed alignment

Only do this as a short-term workaround while you implement Fix 1, 2, or 3. Moving to relaxed alignment reduces the security benefit of DMARC strict alignment, and it should never be a permanent configuration. The goal is always to fix the SEG relay, not to weaken your DMARC policy.

Relaxed vs Strict Alignment: When Each Approach Makes Sense

Strict alignment is the goal for most organizations. It means any email claiming to be from your domain must be signed with your domain's DKIM key, not a third party's. This is the configuration that provides the strongest protection against email spoofing.

Relaxed alignment is more forgiving. It is appropriate when you have legitimate subdomains or business units that send through infrastructure that cannot be fully aligned, but you still want DMARC protection for your main domain.

For most organizations using a third-party SEG, the path forward looks like this:

1. Audit which of your mailstreams go through the SEG
2. Determine which SEG forwarding behavior is causing alignment failures
3. Configure the SEG to use your DKIM domain (preferred) or enable SRS
4. Monitor DMARC reports to confirm the fix

That audit step is where teams most often stumble. DMARCFlow can help by aggregating your DMARC reports across all major recipients and surfacing which source IPs and DKIM domains are associated with alignment failures, so you can identify the SEG relay case without manual XML parsing. If you do not know which of your mailstreams are relayed through the SEG, you cannot know which ones are at risk of alignment failures.

What About Forwarded Email vs SEG Relay?

It is worth distinguishing between two different problems that produce similar error messages:

SEG relay: your email goes through a corporate email security gateway that rewrites the envelope. The solution involves SEG configuration.

Mailing list forwarder: a mailling list service (Mailman, Listserver, etc.) forwards your email to subscribers. The list service rewrites the From header and applies its own signatures. The solution involves SRS or configuring the list service to preserve original headers.

Both problems are DMARC alignment failures, but the fixes differ. This post focuses on the SEG relay case because it is more common in enterprise environments and less discussed.

FAQ

Why does my email pass SPF and DKIM but fail DMARC?
Because DMARC checks alignment, not just individual authentication results. Your email must have both a passing SPF or DKIM result AND alignment between the authenticated domain and the From header domain. A SEG in the mail path typically breaks this alignment.

How do I know if Proofpoint or Mimecast is causing the problem?
Check your DMARC forensic or aggregate reports for DKIM signatures from vendor domains. If you see DKIM domains like proofpoint.com or mimecast.com alongside your From domain in failure records, the SEG is applying its own signatures instead of relaying your authenticated email cleanly.

Should I set my SEG's sending domain to align with our organizational domain?
Yes, where the SEG vendor supports it. This is the cleanest solution because it preserves your DMARC policy without modification. You will need to work with the vendor to set up DKIM key management for your domain on their platform.

What is SRS and does it help with DMARC failures through forwarders?
SRS (Sender Rewriting Scheme) modifies the envelope sender address during relay so that SPF checks reference the original domain rather than the forwarder's infrastructure. It helps with SPF alignment but not DKIM alignment. For SEG relays where SPF is passing but DKIM alignment is failing, SRS alone will not fix the problem.

Our DMARC passes for most recipients but fails for one specific domain. Why?
That domain is enforcing DMARC more strictly than others. Many organizations use p=none or p=quarantine, which tolerates alignment failures. Domains using p=reject will reject any message that fails alignment, regardless of whether SPF or DKIM individually passed.

Bottom Line

Third-party email security filters rejecting legitimate email citing DMARC is almost always a DMARC alignment problem, not an authentication failure. The SEG is sending email that your domain did not directly authorize, which breaks the From-header-to-authenticated-domain chain that DMARC requires.

The fix depends on what control you have over the SEG. The best long-term solution is to configure the SEG to send using your DKIM keys so alignment holds. SRS can help in specific scenarios. And ongoing DMARC monitoring is essential to confirm the problem is resolved and to catch any remaining edge cases.

For teams managing email through multiple SEG products or hybrid infrastructure, DMARCFlow provides the aggregate visibility needed to confirm that SEG relay configurations are not introducing new DMARC failures across your mailstreams.