Secure email gateway vs API-based email security: which do you need?

Email security products now come in two main shapes. A secure email gateway (SEG) sits in front of your mail server and filters everything on the way in. API-based tools, often called integrated cloud email security, plug into Microsoft 365 or Google Workspace and work inside the mailbox. This guide explains how each works, where each is genuinely stronger, and when it makes sense to run both.

How does a secure email gateway work?

A gateway works at the MX record level. When someone sends you mail, their server looks up your domain's MX record to find where to deliver it (RFC 5321). With a gateway, that record points to the gateway instead of your mailbox provider.

The flow looks like this:

1. The sending server connects to the gateway.
2. The gateway checks the connection, the sender's authentication, the content, attachments and links.
3. Spam and threats are quarantined or rejected.
4. Clean mail is relayed to your real mail server: Microsoft 365, Google Workspace, Exchange, cPanel or anything else that speaks SMTP.

Because the gateway is a separate hop, your mail platform has to be told about it. Microsoft documents this as "MX record points to third-party spam filtering" and strongly recommends Enhanced Filtering for Connectors, so Microsoft 365 can still see the original sender's IP address and evaluate SPF, DKIM and DMARC (Microsoft Learn). Google Workspace has an equivalent inbound gateway setting. Our guides cover both: Microsoft 365 with a third-party filter and Google Workspace inbound gateway setup.

How does API-based email security work?

An API-based tool doesn't change your MX record. Mail is delivered to your mailbox platform as normal, and the platform's own filtering runs first. The tool then connects to the mailboxes through the platform's API, such as the Microsoft Graph mail API, to read messages, analyze them and move or delete the ones it judges harmful.

Microsoft describes this pattern directly: some services "use the Microsoft Graph API to scan messages after they're delivered to user mailboxes," which "also allows the non-Microsoft service to remove messages that they believe to be malicious or unwanted" (Microsoft Learn). The same page warns that this integration "typically requires granting the non-Microsoft service full access to mailboxes."

Exact behavior varies by vendor. Some act within seconds of delivery; some also scan internal mail and files. Ask each vendor how quickly it acts and what a user can see before it does.

Secure email gateway vs API: side-by-side comparison

Where does API-based security win?

Be honest about the strengths, because they're real.

• No MX change. Deployment is a consent screen, not a DNS change. There's no mail-routing risk during setup.
• Post-delivery clean-up. When a message turns out to be malicious after it arrived, an API tool can remove it from every mailbox. A gateway that has already passed the message on can't reach into the mailbox to fetch it back.
• Internal and compromised-account mail. If an attacker takes over a colleague's account and sends phishing internally, that mail never crosses the MX. An API tool with mailbox access can see it.
• Works with the platform's own filtering. The platform's native protection stays first in line, unchanged.
• Mailbox context. Access to the mailbox gives the tool more signals about normal communication patterns.

Where does a secure email gateway win?

• Threats are stopped before delivery. Malware and phishing that the gateway catches never reach a mailbox, a phone notification or a synced device.
• Any mail server. A gateway protects cPanel, on-premises Exchange and other SMTP servers just as well as cloud platforms. API tools depend on the vendor supporting your platform's API.
• Outage protection. If your mail server is down, a gateway can hold incoming mail and deliver it later. Mail platforms without a gateway in front rely on the sending servers to retry.
• One policy across platforms. Organizations with domains on several mail systems get one set of rules, allow and block lists, and one quarantine model.
• Narrower access. A gateway handles mail in transit. It doesn't need ongoing read and delete rights over every mailbox.
• Connection-level controls. It can reject at the SMTP stage, apply geographic or attachment-type filters, and refuse mail before accepting it.

The trade-offs that come with a gateway

A gateway is another hop, so it must be set up carefully:

• Lock down direct delivery. If your platform still accepts mail from anyone, attackers can skip the gateway. Microsoft recommends a Partner inbound connector that only accepts mail from the filtering service; Google offers "reject all mail not from gateway IPs". See our guide to blocking direct-to-tenant bypass.
• Keep authentication visible. Without Enhanced Filtering (Microsoft) or the correct inbound gateway settings (Google), your platform sees every message as coming from the gateway's IP address. Google notes it doesn't enforce the sender's DMARC policy on mail that arrives through an inbound gateway, so the gateway has to do that job.
• Plan the MX change. Changing MX records is low-risk when done in the right order. Lower the TTL first, switch the records, and keep the old route working until the change has spread.

Can you use both together?

Yes, and many organizations do: a gateway at the edge to stop most threats before delivery, and an API layer for internal mail and post-delivery clean-up. Microsoft fully supports the gateway-in-front pattern with Enhanced Filtering, and lists API integration as a separate supported option (Microsoft Learn).

Layering has costs. Microsoft lists them plainly: more cost, more complexity, and a rising rate of false positives as more products are added. To keep it manageable:

1. Decide who owns each verdict. For example: the gateway owns spam and malware at the edge; the API tool owns internal mail and retroactive removal.
2. Avoid double link rewriting. Microsoft advises against two products wrapping the same links, because it can break link checks and one-time links.
3. Give users one place to look. Two quarantines confuse people. Choose which one users see and route the other to admins.
4. Keep a single false-positive process. Users should report a wrongly blocked message once, and someone should know which product caught it. Write the process down before you need it.

One pattern to avoid: routing mail out of Microsoft 365 to a filter and back in again (in-and-out routing). Microsoft "strongly recommend[s] avoiding this configuration" because messages return looking like new mail, fail authentication and confuse reporting.

How do you choose between a gateway and an API tool?

Our recommendation: if your main problem is junk and phishing reaching inboxes, or any domain is on cPanel, Exchange or another server without a supported API, choose a gateway; if account takeover and internal phishing worry you more, add an API tool. Work through these questions with your real setup in front of you.

1. Where are your mailboxes? If any domain is on cPanel, Exchange or another server without a supported API, you need a gateway for those domains.
2. What does your platform already include? Check what native filtering you already have; see Microsoft 365 built-in protection vs a gateway.
3. Is your main gap before or after delivery? Too much junk reaching inboxes points to a gateway. Account takeover and internal phishing point to an API tool.
4. How comfortable are you granting mailbox-wide access? If that's a hard no for policy reasons, an API tool is harder to approve.
5. Do you need mail held during outages? That's a gateway feature.
6. How is it priced? Per user or per domain changes the total a lot for some organizations. Our per-domain vs per-user pricing comparison shows the math.
7. Who will run it? A small business without IT staff needs simple quarantine digests and clear setup steps more than a long feature list. Our vendor-neutral checklist for choosing a spam filter lists the questions to ask each provider.

Whatever you choose, it sits on top of the basics: SPF, DKIM and DMARC for your own domains, MFA for every account, and a clear reporting route for users. NIST SP 800-177 Rev. 1 remains a solid reference for those foundations.

Next steps

• Run your domain through the MX Lookup to see where your mail is routed today.
• Run the Email Health Check to check SPF, DMARC and transport settings before adding any layer.
• If you use a gateway, confirm direct delivery to your mail platform is locked down.
• If you're weighing an MX-based gateway with per-domain pricing, see how iBlockSpam works.

iBlockSpam is an MX-level gateway; the portal demo shows what you'd manage day to day, and pricing is per domain with unlimited mailboxes (a mailbox count, not unlimited message volume).

Read our other guides on choosing a spam filter.