Why Your Email SEG Breaks DMARC Alignment for Exchange Online (And How to Detect It)

When mail passes through an email security gateway (SEG) like Mimecast before reaching Exchange Online, DMARC alignment fails for legitimate messages even when SPF and DKIM both pass individually. The reason is not a configuration error on your end. It is how most SEGs handle mail relaying, and it creates a specific diagnostic signature in your DMARC reports that is easy to miss if you are not looking for it.

If you manage Exchange Online with a SEG in front of it, and you have been staring at DMARC failures without understanding why they appear for seemingly legitimate mail, this is the piece that is probably missing from your troubleshooting.

The Mail Flow Problem: SEG Plus Distribution List Equals Alignment Failure

Here is what actually happens when a SEG sits between the internet and your Exchange Online distribution lists.

A message comes from an external sender to your distribution list address. Because the distribution list has "allow external senders" enabled, Exchange Online accepts it. Before it arrives, the message passes through your SEG - Mimecast, Abnormal Security, Hornetsecurity, or any similar gateway. The SEG performs its security scans, and then forwards the message on to Exchange Online.

The problem starts here. The SEG forwards the message using its own mail server as the relay. The original RFC5321 Mail From address (the bounce address, used by SPF) gets replaced with the SEG's own domain. The SEG then delivers the message to your distribution list.

Your DMARC record is checking whether the domain in the RFC5322 From header (the address your users see) aligns with the domains that authenticated the message. SPF checks out against the SEG's domain. DKIM might sign the message body with the SEG's domain. But the From header still shows the original sender's domain.

That is where alignment fails. DMARC is not broken. It is doing exactly what it is supposed to do - it sees a message where the visible sender domain and the authenticated domain do not match.

This is not a Mimecast-specific quirk. It is the standard behavior of any SEG that acts as a mail relay rather than a pure pass-through. The SEG must present its own identity to the receiving mail server during the SMTP conversation, which means SPF will always authenticate against the SEG's domain, not the original sender's.

Why SPF and DKIM Passing Is Not Enough: Authentication vs Alignment

A common point of confusion is why DMARC fails when both SPF and DKIM show as passing in your headers. The short answer is that authentication and alignment are separate checks.

SPF authenticates the RFC5321 Mail From domain - the domain your recipient's mail server saw during the SMTP conversation. DKIM authenticates a domain through a cryptographic signature in the message headers. DMARC then checks whether those authenticated domains align with the RFC5322 From header - the sender address your users see and that appears in their email clients.

Alignment can fail in three ways:

• SPF passes for the SEG domain but the From header shows your own domain = fail
• DKIM passes with the SEG domain but the From header shows the sender's domain = fail
• Both pass for the SEG domain but the From header is a different domain = fail

For distribution list mail, the most common failure is the first one. The SEG rewrites the Mail From, SPF passes for the SEG, but the From header still belongs to the original external sender. DMARC sees a mismatch and reports failure.

This is also why simply adding the SEG's IP to your SPF record does not fix it. SPF passing for your domain would require the SEG to send directly on behalf of your domain, which most SEGs cannot do without breaking their own mail flow architecture.

How to Read DMARC Reports to Find SEG-Induced Alignment Failures

When your DMARC reports show failures, the reason field tells you what went wrong. Look for these specific patterns in your aggregate (XML) reports:

fail_classification = "sfp" or "dkim" means SPF or DKIM passed but alignment failed. If you see this against your own domain as the targeted domain, and the source IP belongs to your SEG provider, you have found the signature of SEG-induced alignment failure.

fail_classification = "pct" means the message was filtered because DMARC saw a policy conflict, but the percentage threshold prevented it from being fully rejected. This is less specific and harder to diagnose from pct alone.

SPF or DKIM pass against the SEG domain while From header shows a different domain. In your aggregate report, each failure record contains the source IP, the aligned domain, and the SPF/DKIM result. If the aligned domain is your SEG's domain (look up the IP range) but the From header in the actual message was a third-party domain, you have confirmed the SEG is the cause.

The key is correlating the failure records in your DMARC report with your known mail flows. If you see failures on your domain appearing in DMARC reports but only from IPs belonging to your SEG or your distribution list infrastructure, those failures are almost certainly caused by the SEG rewriting the Mail From address.

DMARCFlow parses these reports automatically and groups failures by source IP and classification, making it easier to spot the SEG signature without manually scanning XML files. This is especially useful for large domains with high mail volume where the SEG-induced failures would otherwise be lost in noise.

Practical Fixes for Exchange Online and Mimecast

There is no single universal fix for SEG-induced alignment failure because the problem is structural. The SEG must identify itself during SMTP delivery, which means SPF will always check against the SEG domain. Here is what can actually help:

Use a subdomain for distribution list mail. Route distribution list traffic through a subdomain that has its own DMARC record set to p=none or a relaxed alignment policy (raa modifier). This allows the From header to use the parent domain while alignment passes against the subdomain. This requires Exchange Online connector configuration changes and careful testing.

Configure the SEG to preserve original headers. Some SEGs offer configuration options to minimize header rewriting or to add an ARC header that preserves the original authentication chain. Mimecast has specific header compatibility settings that can help preserve DKIM signatures on forwarded mail. Check your SEG documentation for header preservation options and test thoroughly before deploying to production.

Use a dedicated subdomain for external senders to distribution lists. Instead of routing all distribution list mail through the SEG, create a separate subdomain specifically for external sender traffic. Apply a different DMARC policy to this subdomain. This isolates the SEG mail flow from your main domain's DMARC enforcement, reducing noise in your primary DMARC reports.

Move distribution list management to Microsoft 365 native tools. If your distribution lists are primarily internal, consider migrating away from "allow external senders" mode to Microsoft 365 groups with external collaboration settings. This changes the mail flow architecture and can eliminate the SEG relay problem for internal-first distribution lists.

Microsoft ARC (Authenticated Received Chain) may help but has limits. ARC adds a chain of custody record to messages as they pass through each intermediary. If your SEG supports ARC and your receiving mail system (or downstream filtering) checks ARC, it can restore trust in the original authentication results. However, ARC support is not universal across all email platforms and security gateways, so do not rely on it as your primary fix. It is a mitigation, not a solution.

Does ARC Fix This? (And When It Does Not)

ARC was introduced to solve exactly this problem - preserving authentication context when mail passes through legitimate intermediaries like mailing list services and some security gateways. The idea is that each server in the chain adds an ARC header recording what it saw, and the receiving system can use that chain to make a more informed decision.

In practice, ARC has meaningful limitations for the SEG + Exchange Online distribution list scenario:

Not all SEGs generate ARC headers correctly. Some gateways that claim ARC support do not populate all required fields or generate headers that fail validation at the receiving end.

ARC enforcement varies by platform. Some Microsoft 365 tenant configurations check ARC and use it as evidence when evaluating DMARC, but in most deployments ARC is treated as advisory. A DMARC alignment failure with a valid ARC chain may still result in rejection under a strict p=reject policy depending on your tenant's filtering settings.

ARC headers can be stripped by downstream intermediaries. If another security gateway or mail filter processes the message after your SEG, it may strip or corrupt the ARC headers, making them useless.

ARC is worth enabling as a belt-and-suspenders measure, and it will help in some scenarios, but it is not a reliable substitute for fixing the underlying mail flow architecture.

How DMARCFlow Helps You Catch SEG Alignment Failures Automatically

Detecting SEG-induced alignment failures requires reading your DMARC aggregate reports consistently, grouping failures by source IP, and correlating those IPs with your known mail infrastructure. Manually, this is time-consuming and easy to get wrong. With DMARCFlow, the process is automated.

DMARCFlow imports your XML aggregate reports on a schedule, parses the failure records, and surfaces a breakdown by source IP, classification type, and targeted domain. When your SEG IPs show up repeatedly in alignment failures (sfp/dkim classification) against your own domain as the From header, DMARCFlow flags it as a pattern rather than noise.

This gives you the evidence to act on: you know the SEG is causing the failures, you have the approximate volume, and you can see the failure rate trend over time as you apply fixes. If you are still manually scanning DMARC XML files to find these patterns, DMARCFlow replaces that process with structured daily parsing and trend reporting, so you can confirm within a few report cycles whether a configuration change actually reduced the SEG-induced failures.

For ongoing monitoring, DMARCFlow's report parsing is the most practical way to keep track of whether your SEG is generating alignment failures at scale and whether your mitigations are working.

FAQ

Why does DMARC fail for my distribution lists even though SPF and DKIM both pass?

SPF and DKIM are authentication checks that examine who sent the message and whether the signature is valid. DMARC alignment then asks: does the authenticated domain match the From header the recipient sees? When a SEG relays mail to your distribution list, it authenticates as itself, not as the original sender domain. Alignment fails because the From header and the authenticated domain belong to different entities. This is the correct behavior, not an error.

Is this a Mimecast-specific problem?

No. Any SEG that acts as a mail relay - Mimecast, Abnormal Security, Hornetsecurity, Cisco Ironport, Proofpoint, and others - will produce this behavior. The SEG must identify itself during SMTP delivery, which means SPF will check against the SEG domain. The problem is inherent to relay architectures, not specific to any vendor.

Can I just add the SEG's IP addresses to my SPF record?

No. Adding the SEG's IPs to your SPF record tells the world that your domain authorizes the SEG to send mail on its behalf. This would allow the SEG to send spoofed mail that would pass SPF, but it does not fix DMARC alignment because DKIM also needs to sign with your domain. The structural fix requires a different mail flow architecture, not just SPF changes.

Does setting p=none on my DMARC record fix this?

Setting p=none stops DMARC from rejecting or quarantining failing messages, but it does not fix the underlying alignment problem. Your legitimate mail still fails DMARC checks, it just is not blocked. The failures will continue to appear in your DMARC reports, and messages that other receiving domains are filtering may still be rejected based on their own DMARC policies. Fixing the mail flow is the real solution.

What does ARC actually do for this problem?

ARC adds an authenticated chain of custody header at each hop. If your SEG generates a valid ARC header and your receiving infrastructure checks it, the receiving mail system can use that chain to make a more informed DMARC decision. In practice, ARC support is inconsistent across platforms and SEG vendors, so it helps in some cases but should not be relied upon as the primary fix.