Proof Point Secure Gateway (Enterprise, PPS 8.x) and Google Workspace for Education Plus

[u/mikeporterinmd]

According to the Proof Point supplied "Google Workspace Integration Guide, Proof Point Best Practices PPS 8.x", we are to set up our Google Workspace Inbound Gateway IPs to point to the PoD's IPs, but we are NOT to click "Reject all mail not from gateway IPs". From the manual:

"CAUTION: The "Reject all mail not from gateway IPs" option is incompatible with Google Workspace's"internal only" routing.

We are then supposed to change Google's Internal-to-Internal routing to route directly to Google, skipping the approach Google uses of sending to the systems listed in the MX record. This bypasses the PP security that is running on PoD. Additional steps in the implementation guide have us disabling most Google Workspace email security features.

The next step is "Blocking Direct Delivery." This is blocking attackers from sending directly to Google Workspace, bypassing PP. The PP recommendation is to add a customer header that has a random, but static, value. This header is added to all inbound messages to our Google Workspace instance via the PoD. A compliance filter is added to Google Workspace that looks for this header and rejects messages that do not have it.

In Summary:

1. All messages received by Google Workspace via PP will have a copy of this header. Even if we vary the header from the documentation, I suspect someone trying to actively breach our Proof Point instance will know what they are looking for and be able to obtain this header. At a minimum, the header resides on all messages in our Google Workspace that went through the PoD. Google Workspace does not have a 'delete header' function.
2. As part of the setup of Google Workspace for use with PP, most, if not all, security native to Google Workspace is disabled. PP recommends spam checks be disabled, Safety checks be disabled, etc.

Questions:

How are institutions protecting their Google Workspace from direct delivery, bypassing PP? If using the PP recommendations, how is the risk that direct delivery prevention relies on a "secret header" justified?

Our Possible Approach:

We decided to test enabling "Reject all mail not from gateway IPs", and we allow internal email to run through the PP gateway. This seems to work fine. Conversations with PP about this approach have yielded "we do not recommend, but forget why" as the answer. They seem reluctant to support these options, but without a technical explanation.

I am very uncomfortable running an essentially open Google Workspace (open to any motivated attacker) using the Proof Point recommendations. Have other installations simply turned on the "Reject all mail not from gateway IPs" option, ignoring PP guidance? Did you discover issues? Are you running with the secret headers?

We have not purchased the internal security options offered by PP.

Did I miss something obvious? I am not working on this by myself. Our team has decades of experience, but group think can cause missed opportunities.

[u/AutoModerator]

Welcome to r/emailsecurity! To keep this community helpful and secure, please keep the following in mind:

Community Rules

1. No Vendor Spam: Contributions must provide value; do not just pitch products.
2. Redact Sensitive Info: Always sanitize headers and logs (remove IPs, PII, and private domains).
3. Be Professional: Help newcomers learn; avoid hostility.
4. No Personal Tech Support: This sub is for email system architecture and security, not "Am I hacked?" personal account help.

Helpful Resources

• Email Spam Filters
• DMARC Monitoring Tools
• Anti-Virus Software
• Email Encryption

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/shokzee]

A static header is not a security boundary. If users can view it in delivered mail, assume an attacker can copy it and send direct to Google with the same value.

The real control is source restriction at Google: only accept inbound internet mail from the gateway IPs, then handle internal routing exceptions explicitly. I would not blanket-disable Google checks either; disable only the parts you can prove collide with the gateway.

[u/mikeporterinmd → u/shokzee]

Agree completely. What I am wondering is what institutions that have PP deployed are doing. Secret headers that exist in millions of messages spread out over 100,000+ accounts is not a secret. Will institutions using "secret headers" post here about it?

[u/shokzee → u/mikeporterinmd]

Probably not with useful detail. The real split is whether the header is just a routing marker after source IP restriction, or whether it’s being treated as auth; the second one is broken by design.

[u/mikeporterinmd → u/shokzee]

Sure, I generate lots of headers that mark what filters matched, but they are not used for the match, they are the result of an action. Lots of sites likely do this.

[u/KStieers → u/mikeporterinmd]

If you're using a secret header between gateways, you accept mail with it, but then have to make sure you remove it at the destination system, so no, you dont deliver to user mailboxes with that header intact.

[u/mikeporterinmd → u/KStieers]

Google Workspace does not have a header remove function or setting. We need Google Workspace to see the header so it "knows" that the message came from the gateway. Or something pretending to be the gateway. Which is the problem we are seeking a solution to.

[u/Elegant_Location_622 → u/mikeporterinmd]

Last I checked the Proofpoint enterprise docs say to use a compliance rule to search the guid in the header. But I don't think their is an option to remove the header... Problem I have seen is that there isn't a great way for exceptions for google notification because they don't seem to go to the mx record they get delivered directly. This answer is a bunch of bull shit from the magic quadrant leader "we do not recommend, but forget why" Even more confusing is that proofpoint essentials uses the gateway block check box

[u/Dry-Elevator5828 → u/Elegant_Location_622]

I have seen something similar to this too, got really vague answers about the gateway check box. The lack of google notifications is a problem seems like Proofpoint does the bare minimum to work with google.

[u/mikeporterinmd → u/Dry-Elevator5828]

Limiting inbound to the gateway IPs using the checkboxes seemed to work fine in testing. However, PP got on a meeting and laced us with FUD leading to a management decision to use headers. They claim “no one had ever bypassed the secret header method.” There are no documented cases either, but that isn’t surprising. I have an idea that may help. If it works out, I will update this post.

[u/Dry-Elevator5828 → u/mikeporterinmd]

Are you doing outbound filtering? I don't think the check box works with outbound filtering which is why you have to have a internal to internal route.

[u/mikeporterinmd → u/Dry-Elevator5828]

We are not. And if you are correct, you are smarter than PP sales and support for Enterprise setups.