What to Do When Your Gateway Rejects DMARC Mail

Your mail passes DMARC authentication when sent directly from your own server. Route the same message through Proofpoint or a similar email security gateway and it suddenly fails, citing DMARC alignment. The records are correct. Nothing changed on your end. The gateway vendor says your setup looks fine. And your legitimate outbound mail is getting blocked.

The problem is not that your DMARC is wrong. The problem is that the gateway is authenticating with its own identity, not yours, and DMARC requires those identities to match. The diagnostic tool that surfaces this mismatch fastest is your DMARC aggregate report. DMARCFlow presents those reports with clear attribution of which specific domain the gateway is signing as, so you identify the problem in minutes rather than hours of packet inspection.

This article explains why the mismatch happens, how to diagnose it from your aggregate reports, and what steps actually fix it.

Why DMARC Alignment Fails at the Gateway Layer

DMARC requires that the authenticated sending identity matches the From address your recipients see. There are two ways authentication can pass:

SPF alignment means the domain in the envelope (the RFC 5321 Mail From, invisible to users) matches the domain in the From header (the RFC 5322 From address, what recipients actually see).

DKIM alignment means the domain in the DKIM signature's d= tag matches the From header domain.

When your mail goes through a gateway, the gateway typically sends from its own infrastructure. SPF validates against the gateway's IP addresses. DKIM signs with the gateway's domain. Unless the gateway is specifically configured to use your domain for both, neither aligned check passes. Your From header says yourdomain.com. The gateway's authentication says gatewayvendor.com. DMARC sees a mismatch and fails.

This is not a bug in your configuration. It is the default behavior of any mail relay that has not been explicitly set up to send on behalf of your domain.

Reading the Aggregate Report to Confirm the Problem

The fastest way to confirm this is the issue is to look at your DMARC aggregate reports. You want two specific signals.

First, look for alignment results of fail on messages where you expected delivery to succeed. In the aggregate report XML or your aggregator's UI, check the `` section for each failing message. If you see DKIM result = pass but d= shows the gateway vendor's domain instead of yours, that is your answer.

Second, look at the envelope domain in the SPF check. If the gateway is relaying through its own MTA and the envelope domain shows gatewayvendor.net while the From header shows yourdomain.com, you have two misalignments at once: SPF not aligned and DKIM not aligned.

DMARCFlow aggregate reports surface exactly which domains are failing alignment and whether the failure comes from SPF, DKIM, or both, so you can walk into the vendor conversation with specific data instead of a vague description of the symptom.

Proofpoint, Mimecast, Barracuda: Why the Problem Looks the Same Across Vendors

The specific vendor name matters less than the underlying mechanism. Proofpoint, Mimecast, Barracuda, IronScales, and most other mail security gateways share the same default behavior: they relay mail using their own sending infrastructure and their own DKIM keys. The result is identical across all of them. Your From header shows yourdomain.com. The gateway's DKIM signature shows gatewayvendor.com. DMARC alignment fails.

The setup that fixes this is also vendor-agnostic: configure the gateway to DKIM-sign with your domain. Proofpoint calls this Custom DKIM Keys. Mimecast calls it Managed DKIM. Barracuda calls it Forwarder DNS Configuration. The mechanism is the same across all three. The configuration steps differ by vendor portal.

How to Fix the Gateway Alignment Problem

There are two real fixes and two workaround options. The right choice depends on what your gateway vendor supports and how quickly you need the problem resolved.

Fix 1: DKIM Signing With Your Domain

The cleanest fix is to have the gateway DKIM-sign outbound mail using your organization's domain instead of the gateway's own domain. Most major gateway vendors support this through DKIM delegation.

Here is how it works in practice: you add a DKIM record under selector._domainkey.yourdomain.com. The gateway generates the key pair and tells you which DNS record to publish. The gateway retains the private key and uses it to sign mail that passes through on your behalf. When the message arrives at the receiving server, the DKIM signature carries your domain's d= tag, and alignment passes.

This requires a DNS change on your side and configuration on the gateway vendor's side. Most vendors have documentation for this. Proofpoint calls theirs "Custom DKIM Keys." Mimecast calls it "Managed DKIM." The exact name varies but the underlying mechanism is the same.

If your vendor does not support custom DKIM signing, that is a vendor limitation worth knowing about before you sign a renewal.

Fix 2: Add the Gateway to Your SPF Record

If the gateway sends from a fixed set of IP addresses, you can add those IPs to your SPF record so SPF validates against your domain instead of the gateway's.

The approach: ask the gateway vendor for their sending IP list or CIDR range. Then add it to your SPF record using `include:spf.gatewayvendor.com` or direct `ip4:` entries. This makes SPF aligned because the envelope domain and the From header both reference yourdomain.com.

The limitation: gateways that use a large or dynamic pool of IPs can make this impractical. If the IP list changes frequently, your SPF record becomes a maintenance burden and will eventually exceed the 10-DNS-lookup SPF limit.

Workaround 1: Lower DMARC Policy During Transition

If neither fix is immediately available from your vendor, you can move DMARC to p=quarantine temporarily while the configuration is sorted out. This routes failing mail to spam instead of rejecting it, buying time for a proper fix.

The risk: p=quarantine hides the problem rather than fixing it. If you leave it in place long enough, it becomes permanent.

Workaround 2: Monitor Continuously While the Vendor Configures a Fix

The fastest path to resolution is usually to keep DMARC at p=none, monitor your aggregate reports daily, and push the vendor with specific failure data from those reports. Every spike in alignment failures is a data point you can send the vendor to justify escalation.

DMARCFlow monitors aggregate reports continuously and alerts when alignment failure rates change, including spikes caused by gateway configuration changes or new sending sources being added without your knowledge. During a vendor transition, that alert is often the first signal that a new problem has appeared.

How to Talk to Your Gateway Vendor

Opening a support ticket with "our mail is failing DMARC" is unlikely to get a useful response. Opening it with the specific aggregate report data is more likely to produce a configuration change.

Before calling the vendor, gather:

The specific sending domain that is failing

The date and time the failures started

The DKIM signature domain showing in the aggregate report auth_results

Whether the failures affect all sending domains or specific ones

Whether the problem started after a gateway configuration change

Then ask the vendor these questions:

1. Does your platform support DKIM signing with the customer domain? If yes, what is the process for setting up custom DKIM keys for our domain? 2. What are the fixed IP addresses or CIDR ranges used for outbound relay? (So we can update our SPF record.) 3. Can you confirm whether your platform uses a relay subdomain or the customer domain for DKIM signing by default? 4. Do you have documentation for enabling customer-domain DKIM signing?

If the vendor says "we do not support that," you have your answer. If they say "it is possible but requires a professional services engagement," ask for a scope and timeline before committing.

Prevention: Catch the Problem Before It Causes a Rejection

Third-party gateway DMARC alignment failures are a recurring problem, not a one-time event. New gateway configurations, added sending domains, changes to relay infrastructure, or new vendors being added to your email stack are all common triggers.

The primary prevention tool is ongoing aggregate report monitoring with alerting. DMARCFlow continuously monitors your aggregate reports and alerts you when alignment failure rates spike, including spikes caused by gateway configuration changes you were not told about. Most organizations discover these failures only when a user reports that an important message was blocked. With continuous monitoring, the first signal is a monitoring notification, not a complaint from a customer.

DMARCFlow is specifically useful here because it processes aggregate reports from multiple domains and multiple sending sources in one view, so if your gateway starts misbehaving on one domain, you see it across your entire domain portfolio rather than waiting for users to notice.

FAQ

Why does my mail pass DMARC when sent directly but fail through the gateway?

When sent directly, your mail server's SPF and DKIM use your domain. When routed through the gateway, the gateway's SPF and DKIM use the gateway's domain. DMARC checks whether those authenticated domains match your From header. If they do not, DMARC fails even though the individual authentication checks passed.

Is this a problem with my DMARC record?

No. Your DMARC record is correct. The issue is that the sending infrastructure is not aligned with your domain. The fix is on the gateway configuration side, not in your DNS records.

Will changing my DMARC policy to p=none stop the rejections?

It will stop the rejections, but it does not fix the underlying problem. It also reduces your protection against spoofing. Treat p=none as a temporary measure while a real fix is being configured.

My gateway vendor says they cannot support DKIM signing with our domain. What are my options?

Options in order of preference: escalate within the vendor to their technical team (first-line support often does not know this capability exists), open a feature request and ask for a timeline, evaluate whether another gateway vendor supports this out of the box, or use SPF alignment as a partial workaround if the gateway uses fixed IPs.

How long does custom DKIM setup typically take?

It varies by vendor. Some have自助 setup in their admin portal. Others require a support ticket and DNS verification. The DNS propagation takes up to the TTL of your existing DKIM record, typically a few hours to a day. Full setup from ticket to working DKIM is commonly one to five business days.

DMARC alignment failures through third-party gateways are a solvable problem. The fix is not in your DNS records. It is in the gateway vendor's configuration. Getting there fast requires aggregate report data that tells the vendor exactly what is failing and why, not just that mail is being rejected.

DMARCFlow aggregate reports give you that data: specific failure domains, specific alignment results, and specific DKIM signature domains. Bring that to your vendor conversation.