What happens when an email is rejected by an intermediary filter?

Your campaign sent cleanly, your ESP shows it delivered, but the recipient never got it. The bounce message mentions something like "550 rejected by gateway" or names a service you've never heard of. That's an intermediary filter rejection, and it's one of the more frustrating deliverability problems to debug because the obstacle isn't the final mailbox at all.

An intermediary filter is a security layer that sits between the internet and a company's actual mail server. Services like Barracuda, Proofpoint, and Mimecast are the big names here. Large enterprises and universities often route all inbound email through one of these before it ever touches an employee's inbox. The gateway decides whether to accept, quarantine, or reject. If it rejects, your message stops there. The final mail server never even sees it.

This matters because the rejection doesn't come from Gmail or Microsoft 365. It comes from the gateway's own IP address, using the gateway's own rules. Those rules can be stricter than anything a consumer inbox would apply. A company's IT team might have configured Proofpoint to block anything failing DMARC, or to reject senders from certain IP ranges, or to quarantine anything with certain keywords. You won't find those rules published anywhere.

The bounce itself often tells you more than you'd expect if you read it carefully. The response string might literally name the product ("rejected by Proofpoint Essentials") or reference an IP that resolves to a gateway hostname. That's your starting point. Here's what to actually do with it:

• Pull the full bounce code and message from your ESP logs. Don't just look at the soft/hard bounce label. Read the raw response.
• Check whether the IP in the rejection trace resolves to a known gateway. A quick reverse DNS lookup (or our free header analyzer) can confirm it.
• Verify your DMARC, SPF, and DKIM are all passing. Many enterprise gateways treat auth failures as automatic rejects. Fix that first before anything else.
• Check your domain and sending IP against major blocklists. Gateways often pull from Spamhaus and others in real time.
• If everything checks out on your end, the issue might be a policy decision specific to that company. The only real fix there is to have the recipient ask their IT team to whitelist your sending domain or IP.

That last point is worth sitting with. Sometimes you're not doing anything wrong. Enterprise security teams set aggressive policies and don't always keep them perfectly tuned. If you're reaching one person at a company and getting rejected, ask them to loop in IT. If you're seeing this pattern across multiple recipients at corporate domains, it's more likely a reputation or authentication issue on your side worth investigating.

Want to check whether your domain is hitting any blocklists that might be feeding these gateway rejections? Our free blocklist checker takes about ten seconds and shows you exactly where you stand.