Reference
Why authenticated mail can still be rejected — recipient-side gateways
Security gateways at the receiving organisation can modify your mail in transit, breaking DKIM and SPF, and your own reject policy then destroys it. What the dashboard shows, and who has to fix it.
Jump to section
Sometimes your DMARC reports show mail failing — even being rejected — when your SPF, DKIM and DMARC records are all correct. A common cause is an email security gateway at the receiving organisation (Check Point Harmony / Avanan, Mimecast, Proofpoint, Barracuda, Cisco Secure Email, Sophos Email and similar).
What actually happens
- Your mail arrives at the recipient's mail platform and authenticates perfectly against your published records.
- Their security gateway scans it. Many gateways modify the message as part of protection — inserting banners or rewriting links for click-time analysis. Any change to the message body breaks your DKIM signature.
- The gateway then re-delivers the message from its own servers. Your SPF no longer matches (the connecting address is now the gateway's, not yours), and the DKIM signature is broken.
- The recipient's platform re-checks DMARC on the re-delivered copy,
both checks fail, and — if your policy is
p=reject— it obeys your own policy and rejects your legitimate message.
Nothing was misconfigured on your side, and nobody blocked you deliberately. DMARC's design anticipates that forwarding breaks SPF (that is why DKIM exists); when an intermediary breaks DKIM too, the sender has nothing left to configure.
How the dashboard treats this
The dashboard identifies sources belonging to known security gateways and separates their failures from your compliance grade:
- Your grade is computed over traffic you control. Failures attributed to a recipient-side gateway don't count against it.
- A "Gateway impact" panel on the domain page names the gateway, shows how much mail was affected and how much was rejected, and links to remediation. The impact is never hidden — rejected mail is real mail loss, so it's shown as an incident with a fix rather than a bad grade.
Who fixes it, and how
The fix belongs to the receiving organisation's IT team:
- Microsoft 365 recipients: enable Enhanced Filtering for Connectors (Defender portal → Settings → Email & collaboration → Enhanced filtering) for the gateway's connector, listing the gateway's relay IP ranges. Microsoft then authenticates re-delivered mail against its original source, and gateway processing stops colliding with sender reject policies. This is the standard, vendor-documented setup for inline gateways.
- Gateway allow-lists: if the gateway's own filtering is junking or quarantining your mail (reputation heuristics often flag newer, low-volume domains), the recipient can add an allow rule or report the mis-classification in the gateway console.
- ARC (Authenticated Received Chain): some gateways add ARC seals that preserve the original authentication results, and some receiving platforms can be told to trust those seals (in Microsoft 365: trusted ARC sealers). This is complementary — useful when available, but Enhanced Filtering is the primary fix. There is nothing for you, the sender, to configure for ARC: seals are added by intermediaries and honoured by receivers.
What you should never do
Do not add the gateway's IP ranges to your SPF record. It would make these failures disappear — by authorising every customer of that gateway worldwide to send SPF-authenticated mail as your domain. The dashboard's fix suggestions will warn you if a suggested source is a known gateway.
If the affected organisation is one you work with, the practical step is a short note to their IT team: your mail is authenticated correctly, and their gateway's re-delivery is being rejected under sender DMARC policies — pointing them at Enhanced Filtering for Connectors.