AegisAI Lab · Lab Note 003
Two ways in: connect through Google's APIs and leave mail flow alone, or put a gateway in front of Gmail and change your MX records. Here are the exact Admin console steps for both.
You can add a third-party email security layer to Google Workspace in one of two ways. An API-based integration connects to Gmail through Google's APIs, inspects mail inside the mailbox and changes nothing about how mail is delivered. A secure email gateway sits in front of Gmail: you point your MX records at the gateway and configure Gmail's inbound gateway setting to accept mail from it. Choose the model first, because it decides which Admin console settings, DNS records and tests the rest of the project needs.
Sources: FBI IC3 2025 Internet Crime Report; Google Workspace Admin Help, Set up an inbound mail gateway.
Adding a third-party email security layer to Google Workspace comes down to three decisions: the deployment model, the access you grant it, and how you prove it works before it touches every mailbox.
An API layer reads and acts on mail that Gmail has already accepted. A gateway inspects mail before Gmail sees it. The comparison table below sets out the trade-offs.
For an API layer, a super administrator authorizes the vendor's client ID and OAuth scopes. For a gateway, someone with the Gmail Settings administrator privilege adds the gateway's IPs to Inbound gateway, and your DNS owner updates the MX records.
Start with a small group in monitor mode, compare the layer's verdicts with what users actually received, check SPF, DKIM and DMARC results in the headers, and only then switch on automatic remediation for everyone.
Both models assume Google Workspace's own protections stay on. For the wider picture of how platform security and an added layer divide the work, see our guide to email security for Microsoft 365 and Google Workspace.
An API-based layer is the lower-risk change because mail delivery never depends on it. A gateway gives you a pre-delivery block point, at the cost of DNS work and a new dependency in the mail path.
| Question | API-based integration | Secure email gateway (MX change) |
|---|---|---|
| Where it sits | Connected to Gmail through Google's APIs, alongside the mailbox | In front of Gmail, in the delivery path |
| MX record change | None | Required MX records point to the gateway |
| Admin console work | Authorize client ID and OAuth scopes (super administrator) | Inbound gateway IPs, TLS, spam header rules (Gmail Settings administrator) |
| When it inspects mail | After Gmail accepts it; can remove messages already in inboxes | Before Gmail accepts it; can block or quarantine before delivery |
| Internal mail between your own users | Visible, because it reads the mailbox | Usually not seen, because it never crosses the gateway |
| If the vendor has an outage | Mail still flows; inspection pauses | Inbound mail can queue or bounce |
| Authentication impact | None on SPF, DKIM or DMARC | Gmail stops enforcing sender DMARC for gateway mail; SPF and DKIM need care |
Many teams start with an API layer because it can be piloted without touching DNS. If you are moving away from an existing gateway, our secure email gateway migration guide covers the cut-over.
An API-based layer is connected by a super administrator, who grants the vendor's app access to Gmail data in the Google Admin console. Google's domain-wide delegation guide sets out the steps. Follow your vendor's instructions where they differ.
Ask for the OAuth client ID and the exact OAuth scopes the integration needs. Google advises that the scopes be "appropriately narrow". Question any scope that is broader than reading and moving mail.
Only a super administrator can manage domain-wide delegation. If multi-party approval is on for your organization, a second super administrator must approve the change.
Go to Menu › Security › Access and data control › API controls, then click Manage Domain Wide Delegation.
Click Add new, paste the client ID, add each OAuth scope, then click Authorize. An error usually means the client ID is not registered with Google or a scope is duplicated or unsupported.
Complete the vendor's Google Workspace setup, choose a pilot group, and confirm it can see new messages arriving in those mailboxes.
Some vendors install as a Google Workspace Marketplace app instead. The flow is shorter, but review the same thing: which scopes are requested, and whether they match what the product actually does.
A gateway deployment has two halves: DNS, so that mail reaches the gateway first, and Gmail's Inbound gateway setting, so that Gmail trusts the gateway and reads its verdicts. Google's inbound mail gateway guide is the reference.
Go to Menu › Apps › Google Workspace › Gmail › Spam, Phishing and Malware, select your top-level organization, scroll to Inbound gateway and click Edit. You need the Gmail Settings administrator privilege.
Add each public IP address or range the gateway sends from. Gmail does not accept private IP addresses here. If mail passes through more than one gateway, add them all.
Select Automatically detect external IP so SPF and spam checks use the original sender's IP, Reject all mail not from gateway IPs to close the bypass path, and Require TLS for connections.
If the gateway tags suspicious mail with a header, enter that header as a regular expression under "Message is considered spam if the following header regexp matches", so Gmail acts on the gateway's verdict.
Google says changes can take up to 24 hours, though they usually apply sooner. Track them in the Admin console audit log.
Close the direct-to-MX bypass
Google's MX servers stay reachable after you change your MX records. Attackers can deliver to them directly.
Intended path
MX records point to the gateway
Bypass path
Sender connects straight to Google
Test the lockdown: from an outside system, send a message straight to Google's MX servers for your domain. It should be rejected. A gateway that can be skipped this way protects only the mail that happens to route through it, which is why attackers look for these gaps. Our threat research shows how attackers bypass a secure email gateway.
Adding the gateway's IP to an allowlist does not change how Gmail delivers or filters mail. Configure the Inbound gateway setting instead.
Paraphrased from Google Workspace Admin HelpTo inspect outgoing mail as well, add an outbound gateway at Apps › Google Workspace › Gmail › Routing › Outbound gateway. This applies to the top-level organization only; use a routing rule if you need it for part of the organization. Google's outbound gateway guide says the gateway should accept mail only from Google Workspace IPs, so it does not become an open relay.
An API-based layer needs no authentication changes. A gateway does, because it changes the path mail travels and the IPs that send it. Our explainer on SPF, DKIM and DMARC architecture covers the background.
p=none, read the reports, fix alignment for every sending service, then move to quarantine and reject.Pilot the new layer on a small group first. Then you can measure what it catches, and what it gets wrong, before it acts on everyone's mail.
Business email compromise is why this testing matters. It caused $3,046,598,558 in reported losses across 24,768 complaints in 2025, and a typical BEC message has no attachment or link to scan. For a scorecard to use during the pilot, see how to evaluate email security vendors.
AegisAI uses the API model. It connects to Google Workspace (or Microsoft 365) through the API, with no MX change and no rerouting of mail. Google's own protections stay in place, and AegisAI investigates the messages that get through them. To learn more about the approach, read cloud email security for Google Workspace, or book a demo to see it on your own mail.
Choose a deployment model, then grant access in the Google Admin console. For an API-based layer, a super administrator authorizes the vendor's client ID and OAuth scopes under Security, API controls, Domain-wide delegation. For a gateway, point your MX records at the gateway and add its IPs under Gmail, Spam, Phishing and Malware, Inbound gateway. Pilot on a small group before full rollout.
Only for a gateway. An API-based integration connects through Google's APIs and leaves your MX records and mail flow unchanged. A secure email gateway needs your MX records to point to the gateway so it receives mail before Gmail does.
An API-based integration is quicker to pilot, sees internal mail and keeps mail flowing if the vendor has an outage. A gateway can block messages before they are delivered, but it adds DNS changes, a dependency in the mail path and extra SPF, DKIM and DMARC work. Many teams start with an API layer.
An API-based layer needs a super administrator to authorize its OAuth client ID and scopes through domain-wide delegation or a Marketplace app install. Google advises keeping the scopes appropriately narrow. A gateway needs the Gmail Settings administrator privilege to configure the Inbound gateway setting.
In the Inbound gateway setting, add every gateway IP and select "Reject all mail not from gateway IPs". Then test by sending a message from an outside system directly to Google's MX servers for your domain. It should be rejected.
No. Google states that Gmail does not enforce the sender's DMARC policy for mail that arrives through an inbound gateway, although it still uses the authentication results. Your gateway should enforce DMARC for inbound mail.
Run it in monitor mode on a pilot group that includes finance and executives. Check the message headers for SPF, DKIM and DMARC results and the layer's verdict, compare its findings with messages users reported, and for a gateway confirm that direct-to-MX delivery is rejected. Then turn on remediation group by group.
AegisAI uses the API model. It connects to Google Workspace through Google's APIs, with no MX record change and no rerouting of mail. Google's own protections stay in place, and AegisAI investigates the messages that get through them.
