Why Your Legitimate Email Gets Rejected by Third-Party Filters Citing DMARC

The Problem: Legitimate Mail Suddenly Rejected Citing DMARC

You run your email through a third-party email security gateway (SEG). Proofpoint, Mimecast, Barracuda - the name does not matter. The setup has been stable for months or years. Then one day you check your DMARC aggregate reports and find a spike in authentication failures. Some recipient domains are rejecting your mail outright, citing DMARC policy violations.

Your first instinct: something is wrong with your SPF or DKIM records. You check them. They look fine. SPF includes all your known sending IPs. DKIM is signed with a valid selector. Your domain passes both checks when you test directly.

So why is a recipient server rejecting your mail?

The answer has nothing to do with your records and everything to do with how your SEG forwards mail. When your mail leaves your server and passes through the SEG for relay to external recipients, the SEG changes what the receiving server sees. That structural change breaks DMARC alignment, even though nothing about your SPF and DKIM configuration has actually changed.

This is where DMARC aggregate report monitoring becomes essential. Tools like DMARCFlow continuously parse your aggregate reports and flag authentication failures by source IP and DKIM domain, so you can spot a new relay path appearing in your failure data before it causes a production incident.

This is not a bug in your setup. It is a predictable consequence of how email relaying interacts with DMARC, and it catches organizations off guard because the failure is invisible until a recipient with a strict policy starts rejecting mail.

How an SEG Changes What Receivers See

When you send mail directly from your mail server to a recipient, the recipient server sees your sending IP in the SMTP transaction and evaluates your SPF against it. The From domain in the message header and the domain in the Return-Path (RFC 5321 MAIL FROM) are typically the same or at least aligned. Your DKIM signature, if you sign outbound mail, uses a selector in your own domain.

When you route mail through an SEG, the chain looks different. Your internal mail server hands the message to the SEG. The SEG then forwards that message to the recipient on your behalf. The recipient server receives the connection from the SEG's IP address, not yours. The Return-Path is rewritten to show the SEG's domain or a bounce-handling address controlled by the SEG.

Here is what that means for each authentication check:

SPF: The receiving server evaluates the Return-Path domain against the IP that delivered the message. That IP belongs to the SEG, not your organization. The SEG's IP is not in your SPF record. Unless your SEG is somehow included in your SPF record, SPF fails at the receiving server.

DKIM: If your SEG does not forward mail with a DKIM signature that is aligned to your From domain, meaning the DKIM signature's domain matches the From domain exactly, DKIM alignment fails. Many SEG products strip the original DKIM signature during the relay process without replacing it with an aligned one. Others sign the forwarded message with their own domain instead. In both cases, when the receiving server checks the DKIM signature, the d= domain in the signature does not match the From domain in the header, so DMARC DKIM alignment fails.

DMARC alignment: DMARC requires at least one of SPF or DKIM to pass alignment. When the SEG relay breaks both, alignment fails entirely. If the recipient domain has a strict DMARC policy (p=quarantine or p=reject), your legitimate mail gets quarantined or rejected.

You can have a perfectly correct SPF record, a perfectly valid DKIM signature, and still fail DMARC at a receiving server because of the relay infrastructure sitting in between.

Why This Can Happen Suddenly Without Any Changes on Your Side

Organizations are often baffled when this starts happening out of nowhere despite nothing changing in their email infrastructure.

The most common trigger: a recipient domain that was previously using a relaxed DMARC policy (p=none, monitor-only) moves to p=quarantine or p=reject. Or a recipient domain upgrades their email security gateway to a version that enforces DMARC checks more strictly.

There is also a second scenario that plays out regularly: an organization adds a new outbound relay path, a new SaaS platform, a marketing email system, a cloud mail platform, that routes through the SEG. Now some portion of outbound mail that was previously going direct is now going through the SEG. That traffic was previously passing DMARC checks; now it starts failing.

In both cases, the change is on the recipient side or the infrastructure side, not in your DNS records. That is why checking your SPF and DKIM records gives you no comfort - they have not changed. The failure is in the relay path.

Reading Your DMARC Reports to Find SEG-Related Failures

If you are seeing unexpected DMARC rejections, your aggregate reports will tell you what went wrong. Look for these specific patterns:

Source IP that is not yours: In the aggregate report, the sending source IP in the Authenticated Headers section does not match any IP in your SPF record. That is a telltale sign of a relay or gateway. The IP belongs to the SEG or to a forwarding service.

DKIM signature from an unexpected domain: The d= field in the DKIM signature does not match your From domain. If it shows the SEG's domain instead, alignment will fail regardless of whether the signature itself is valid.

High volume of softfails or failures on one receiving domain: If one specific recipient domain shows a sudden spike in authentication failures while others are fine, that domain has likely moved to a stricter DMARC policy. Your mail was getting through before because they were in monitor-only mode.

Failures that started on a specific date: Correlate the failure start date with any infrastructure changes you made on that day - a new relay, a gateway configuration update, a new SaaS integration.

DMARCFlow parses these aggregate reports automatically and surfaces failure patterns by source IP and DKIM domain, making it straightforward to identify SEG relay as the cause without manually digging through XML report files.

Architectural Fixes for SEG-Induced DMARC Rejections

There are three practical paths to resolving this, depending on your infrastructure and how much change you can tolerate.

Option 1: SRS (Sender Rewriting Scheme)

SRS is a protocol designed specifically to solve the email forwarding relaying problem. It works by rewriting the Return-Path address at the relay point so that bounces can still find their way back to the original sender, while also making the SPF check pass at the receiving server.

When the SEG applies SRS, it rewrites the MAIL FROM to include a routing address that encodes the original sender. When the receiving server checks SPF, it checks the rewritten domain, which the SEG's SPF record covers, rather than the original sender's domain. This makes SPF pass. The receiving server can then deliver the mail, and any bounces route back through the SRS system, which decodes the original sender and routes the bounce correctly.

Not all SEG products support SRS natively. It is more commonly implemented at the border MTA level or through a dedicated forwarding service. If your SEG does not support SRS, you may need to add it to your relay infrastructure.

Option 2: DKIM Signing at the SEG

If the SEG can sign outbound mail on behalf of your domain using a DKIM key in your domain's DNS, that solves the DKIM alignment problem. The SEG inserts a DKIM signature with d=yourdomain.com, which matches the From domain exactly. Even though the mail is forwarded through the SEG, the DKIM signature is valid and aligned.

This requires the SEG to have access to a DKIM private key for your domain - either through a shared secret arrangement or by generating the key pair and publishing the selector DNS record yourself, giving the SEG the private key to sign with.

Some enterprise SEG products call this "DKIM relay" or "outbound DKIM signing." It is the cleanest solution if your SEG supports it, because it preserves your domain's email authentication identity through the relay without needing SRS.

Option 3: Transition to p=quarantine Before Enforcing p=reject

If you cannot implement SRS or DKIM signing immediately, and the failures are affecting a small enough volume of mail, moving your own DMARC policy to p=quarantine instead of p=reject buys you time to implement a proper fix. p=quarantine does not block mail outright; it routes it to the recipient's spam folder. This gives you breathing room to work with your SEG vendor or update your relay infrastructure without losing legitimate mail to hard bounces.

This is not a permanent solution. It is a transition state. The goal is still to resolve the alignment failure properly.

Option 4: Dedicated Sending Domains for SEG Relay

Some organizations sidestep the alignment problem by using a separate subdomain specifically for mail that routes through the SEG. That subdomain has its own SPF record (covering the SEG's IPs) and its own DKIM key (managed by the SEG). It also has its own DMARC record. Mail that does not go through the SEG uses the primary domain with its own authentication, unaffected by SEG relay issues.

This works but adds administrative complexity. You need to manage separate sending infrastructure for different mail streams, which can become harder to audit over time.

How to Prevent This From Sneaking Up on You

The organizations that get caught by this are usually the ones not reading their DMARC aggregate reports closely. The failures accumulate silently until a recipient domain enforces a strict policy and suddenly bounces start appearing in volume.

Set up DMARC monitoring with aggregate reports flowing into a tool that can alert on failure spikes - especially on source IPs you do not recognize. A sudden appearance of sending IPs from a cloud provider or security vendor you do not control is a sign that something in your relay infrastructure has changed.

When you add a new email relay, a new SaaS integration, or a new gateway, test whether your outbound mail from that integration passes DMARC alignment before going live. You can do this by sending a test message to a controlled account and checking the authentication results in the header, or by monitoring aggregate reports for the first few days after the change.

DMARCFlow monitors your aggregate reports continuously and alerts when new sending infrastructure appears in your failure data, so a new relay path showing up as a source of DMARC failures gets flagged before it causes a production email incident.

FAQ

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

You can, but it may not fully solve the problem. Adding the SEG's IPs to your SPF record fixes SPF alignment. However, if the SEG does not preserve your DKIM signature through the relay, DKIM alignment still fails. You need both SPF and DKIM alignment to pass for DMARC to pass reliably. The combination of SEG IPs in SPF plus DKIM signing by the SEG is the most robust solution.

Why does my internal mail pass DMARC checks but external mail fails?

Internal mail never leaves your domain's boundary, so external DMARC checks do not apply. Your internal Exchange or Microsoft 365 server accepts mail from authenticated internal senders without querying your public SPF, DKIM, or DMARC records. The moment mail leaves your infrastructure and crosses to an external recipient, the receiving server evaluates it against your published DMARC policy. That is when the SEG relay problem surfaces.

Does this affect all SEG products equally?

No. Some SEG products are designed to preserve email authentication through the relay by signing outbound mail with your domain's DKIM key. Others strip or replace authentication headers. The behavior depends on the SEG's architecture and its configuration. If your SEG vendor cannot preserve DKIM alignment, SRS at the relay level is the next best option.

My SEG vendor says everything is configured correctly. Why am I still seeing failures?

There may be a configuration mismatch between how your SEG is set up for inbound inspection versus outbound relay. Some SEG products use different sending infrastructure for these two functions, and the outbound IPs may not be covered by your SPF record or may not be signing with your DKIM key. Ask your vendor specifically about their outbound relay configuration and whether they support DKIM signing on behalf of your domain.