The cybersecurity industry is navigating a fundamental architectural shift—moving from perimeter-based defenses toward cloud-native, API-driven security models. Nowhere is this more apparent than in email security for organizations using Google Workspace.
For decades, the Secure Email Gateway (SEG) was the gold standard. But as organizations migrate to cloud platforms, the architectural assumptions behind legacy gateways increasingly conflict with how modern cloud email actually works.
The Core Architectural Difference
Understanding the fundamental difference between SEG and API-based approaches is critical for making an informed decision.
Legacy SEG Architecture (Proofpoint)
Proofpoint operates on a perimeter-based security model designed for the era of on-premises Exchange servers. The architecture requires:
- MX Record Redirection: Your DNS MX records must point to Proofpoint's data centers instead of Google
- Store-and-Forward: Proofpoint accepts messages, scans them, then relays clean emails to Google Workspace
- External Perimeter: Security inspection happens outside your cloud environment
This model was essential when organizations hosted vulnerable Exchange servers on-premises. A gateway filtering traffic before it reached internal infrastructure made sense.
API-Based Architecture: Integrated Cloud Email Security (Check Point Harmony)
Check Point Harmony Email (formerly Avanan) represents a category of solutions called Integrated Cloud Email Security (ICES)—the evolution from perimeter gateways into the API economy:
- No MX Changes: Integrates directly via Google's APIs
- Inline Inspection: Uses Google's native routing rules to intercept messages after Google accepts them but before inbox delivery
- Embedded Protection: Operates within the Google ecosystem rather than in front of it
Why Architecture Matters for Google Workspace
The architectural mismatch between legacy gateways and cloud email creates several practical problems.
Problem 1: Breaking Google's Native Security
When Proofpoint sits in front of Google Workspace, all incoming email appears to originate from Proofpoint's IP addresses. To Google's security filters, this looks like a massive spam campaign.
The workaround: Administrators must whitelist all Proofpoint IP ranges in Google Admin Console. If Proofpoint adds new data centers or rotates IPs, someone must manually update configurations or risk legitimate email being rejected.
The compounding issue: Even with whitelisting, Google's spam filters often disagree with Proofpoint's assessments. Proofpoint deployment guides explicitly recommend disabling Google's spam filtering to avoid "double-scanning" conflicts.
You end up paying twice for security—Google and Proofpoint—but using only one layer.
API-based alternative: Check Point scans email after Google processes it. Both security layers remain active. Google filters high-volume spam; Check Point focuses on sophisticated attacks that bypass native controls.
Problem 2: Email Authentication Complications
Email authentication protocols (SPF, DKIM, DMARC) verify the identity of connecting servers.
In a Proofpoint deployment:
- Connection chain: Sender → Proofpoint → Google
- What Google sees: Proofpoint's IP, not the original sender's
- SPF result: Fails (the sender's SPF record authorizes their IPs, not Proofpoint's)
The workaround: Enable "Automatically detect external IP" in Google—a heuristic feature that parses email headers to find the original sender's IP. This parsing is imperfect and can be manipulated by attackers to bypass authentication.
DMARC complications: Because SPF checks rely on heuristic workarounds, strict DMARC enforcement becomes risky. Many administrators relax DMARC policies to avoid rejecting legitimate mail, weakening overall security.
API-based alternative: Email delivers directly to Google. The connection comes from the original sender. SPF, DKIM, and DMARC work exactly as designed.
Problem 3: Internal Email Blind Spot
Compromised internal accounts frequently launch lateral phishing attacks or spread ransomware. This internal attack surface is critical.
The gateway limitation: Proofpoint sits at the perimeter—it's architecturally blind to internal-to-internal email (East-West traffic).
The workaround: "Hair-pinning"—configuring internal emails to leave Google, travel to Proofpoint on the public internet, then route back. This introduces latency to internal communications, creates internet bandwidth dependencies for local traffic, and risks mail loops.
API-based alternative: By operating within the API layer, Check Point sees every internal message, chat, and file share with zero network latency penalty. This enables building behavioral profiles that detect anomalies like a finance employee suddenly emailing a large number of internal recipients with urgent requests.
Comparative Analysis
| Feature | Proofpoint (SEG) | Check Point Harmony (API) |
|---|---|---|
| Deployment | DNS changes, firewall rules, weeks of planning | OAuth authorization, minutes to deploy |
| Google Native Security | Requires disabling or bypassing | Layers on top, acts as "last line of defense" |
| Internal Email Visibility | Requires complex routing rules | Native visibility via API |
| SPF/DKIM/DMARC | Workarounds required | Standard operation preserved |
| Failure Mode | Email flow stops if gateway fails | Google native security remains active |
| Collaboration Apps | Separate CASB product required | Native protection for Drive, Docs, Chat |
The "Last Line of Defense" Strategy
A common assumption is that the first filter catches more threats. The reality is more nuanced.
Gateway processing burden: Proofpoint, as the first line of defense (MX), processes 100% of incoming traffic. To maintain delivery speeds, gateways optimize for throughput using static signatures and reputation lists.
API-based positioning: By sitting behind Google, Check Point allows Google's infrastructure to filter out the 90%+ of traffic that's spam, known malware, or marketing noise. This lets advanced AI models focus exclusively on sophisticated attacks that bypass standard filters.
This defense-in-depth strategy often catches more of the dangerous threats because computational resources concentrate on what actually matters.
Detection Approach Differences
Reputation-based (Proofpoint): Heavy reliance on "Very Attacked People" profiling and global reputation networks. Effective against known campaigns, but struggles with zero-day attacks or compromised legitimate infrastructure (like phishing links hosted on legitimate SharePoint sites).
Contextual AI (Check Point): Deep integration with collaboration suites enables analysis of historical communication patterns—who talks to whom, typical tone, usual timing. This catches Business Email Compromise (BEC) attempts that contain no malicious payloads—just a text-based request for a wire transfer that's anomalous for that specific user pair.
Post-Delivery Remediation
URL Rewriting (Proofpoint): Links are rewritten to redirect through Proofpoint's proxy for time-of-click scanning. Attackers adapt using "time-bomb" URLs that appear clean during scanning but turn malicious later, or CAPTCHAs that block automated scanners.
Search and Destroy (Check Point): If a message is delivered and later identified as malicious, API integration enables reaching into every inbox and retracting the message instantly. This limits the "blast radius" of zero-day attacks. Gateway architectures generally can't retract delivered messages without additional modules.
Beyond Email: Collaboration Security
Modern workspaces extend beyond email. Google Workspace includes Drive, Docs, and Chat.
Gateway architecture limitation: Securing Drive requires a separate Cloud Access Security Broker (CASB) product with different deployment models and policies that must be manually synchronized.
Platform architecture advantage: Check Point provides unified protection for Gmail, Drive, Docs, Slides, and Chat from the same console. The same threat intelligence engine blocks malicious files whether they arrive via email or file share—preventing "channel hopping" where blocked email attackers switch to Drive.
Deployment Reality
SEG deployment timeline:
- DNS planning for MX record TTL propagation
- Firewall configuration to whitelist gateway IPs
- Google Admin Console configuration for inbound gateways and routing
- Policy tuning to prevent false positives before enabling blocking
This typically spans weeks to months.
API deployment timeline:
- Administrator logs into portal
- OAuth authentication with Google
- Solution begins scanning immediately
This takes approximately five minutes with no downtime or risk of lost email.
Total Cost of Ownership Considerations
Licensing complexity: SEG vendors often use modular pricing where base licenses cover core gateway functions. Advanced threat protection, remediation, internal mail defense, and CASB are separate add-ons. The total cost for complete protection often exceeds initial quotes.
Operational overhead:
- Deployment labor (40+ hours vs. under 1 hour)
- Ongoing portal management across multiple interfaces
- Troubleshooting delivery issues from MX routing
Consolidation opportunity: API-based platforms often provide unified protection across email, collaboration apps, and DLP with single-console management.
When SEG Architecture Still Makes Sense
This comparison focuses on Google Workspace environments. Legacy SEG architecture may still be appropriate for:
- On-premises Exchange servers
- Hybrid environments with significant on-premises infrastructure
- Organizations with existing deep integration into SEG vendor ecosystems
- Specific compliance requirements mandating gateway-style inspection
Making the Decision
For cloud-native Google Workspace environments, key questions to evaluate:
-
Do you need internal email visibility? If compromised accounts are a concern, API-based visibility is valuable.
-
How important is preserving Google's native security? If you're paying for Google Workspace security features, disabling them creates waste.
-
What's your deployment timeline? Weeks-long infrastructure projects vs. same-day protection involves different risk calculations.
-
Do you need collaboration app protection? Unified email and Drive/Docs protection simplifies security architecture.
-
How do you handle email authentication? If strict DMARC enforcement matters, architectural impacts on SPF are significant.
Conclusion
The architectural paradigm has shifted. Legacy Secure Email Gateways were designed for a world of on-premises mail servers and perimeter-based security. Google Workspace operates differently—it's cloud-native, API-driven, and comes with substantial built-in security.
Forcing a gateway architecture onto this modern infrastructure creates friction: disabled native security, authentication workarounds, internal traffic blind spots, and complex deployment projects.
API-based solutions like Check Point Harmony align their architecture with the platforms they protect. This means better internal visibility, preserved email authentication, faster deployment, and unified collaboration security.
The right choice depends on your specific environment, but for organizations committed to cloud-native Google Workspace, the architectural advantages of API-based email security are substantial.
Software
- Check Point Infinity: Learn more about Check Point's integrated security platform, including Harmony Email & Collaboration
Related Resources
- Email Authentication Complete Guide: SPF, DKIM, and DMARC implementation
- Email Gateway Security Configuration Guide: Gateway deployment best practices
- Google Workspace Security Best Practices: Hardening your Google environment
- Why Employees Click Phishing Emails: Understanding the human factor
Tools
- Email Header Analyzer: Analyze email authentication results
- SPF Record Checker: Validate SPF configuration
- DMARC Record Checker: Check DMARC policy
- DKIM Record Checker: Verify DKIM setup
