A secure email gateway is an email security product that inspects inbound and outbound mail for spam, phishing, malware and data loss before it reaches or leaves user mailboxes. Two very different readers end up looking that up: one is evaluating email security for their own organization, the other is trying to reach someone who sits behind a gateway and wants to know what it means for their outreach. This guide covers both.
The second question is the one almost nobody answers. Published material on gateways is written from inside the organization running one, which makes sense, since that is who buys them. Seen from outside, the effect is less about mail being filtered and more about address validity becoming unobservable, because the gateway answers on the mailbox's behalf.
This guide works through what a gateway is and how the two deployment models differ, how common they are among large enterprises and which vendors those enterprises run, what a gateway does to a legitimate sender trying to confirm an address, and how Proofpoint, Mimecast and Cisco IronPort differ in practice. That last comparison comes from our own measurement of all Fortune 500 primary corporate domains.
Key takeaways
- A secure email gateway is an email security product that inspects inbound and outbound mail for spam, phishing, malware and data loss before it reaches or leaves user mailboxes, deployed either in the mail path via the MX record or through an API integration with the mailbox platform.
- Most large enterprises run one. In our census of all 500 Fortune 500 primary domains, 276 (55%) sat behind a gateway, and Proofpoint accounted for 222 of those (80%).
- The problem a gateway creates for senders has little to do with filtering. Because the MX record points at the gateway, it answers on the mailbox's behalf, so whether a specific address exists stops being observable from outside.
- A test send will not settle it. A gateway can be configured to reject an invalid recipient during the SMTP conversation, bounce it later, or drop the message entirely, and only the first of those produces the immediate failure a sender is watching for.
- Behavior varies by deployment, not by vendor. Among gateway-fronted Fortune 500 domains, 145 of 222 Proofpoint deployments behaved as catch-all (65.3%) while none of the 21 Mimecast deployments did, and every one of these products can be configured either way.
What is a secure email gateway?
A secure email gateway is an email security product that sits between the internet and an organization's mailboxes, inspecting inbound and outbound mail for spam, phishing, malware, and data loss before it reaches or leaves a user's inbox. You will also see it called a SEG, the abbreviation the security industry uses in conversation, or an email security gateway. All three names describe the same product.
The vendor definitions agree on the substance. Cloudflare describes a product that blocks malicious email "before they reach recipients' inboxes", Proofpoint calls it a server "through which all incoming and outgoing emails pass", and Abnormal frames it as filtering "inbound and outbound email traffic".
What those definitions share is a point of view: each describes the gateway from inside the organization it protects. A gateway behaves very differently seen from outside, and that side is where this article spends its second half.
How does a secure email gateway work?
There are two deployment models, and they place the gateway in different positions relative to the mail path.
Plenty of organizations run both, using an MX-based gateway for perimeter filtering and an API-based product for post-delivery remediation and visibility into internal mail. Either model can be delivered as a cloud service or, less commonly now, as an on-premises appliance, which is a separate question from where the product sits in the mail path.
The MX-based model is the one the rest of this article depends on. When a domain's MX record points at a gateway, the gateway is what answers whenever anything contacts that domain, including any attempt to establish whether a particular address exists. The mailbox host sits behind it and is never reached directly. An API-based deployment does not sit in the mail path at all, so it creates none of the same ambiguity.
What does a secure email gateway do?
A gateway's function list is broad, and most of it is inbound threat inspection:
- Spam and graymail filtering, separating unwanted bulk mail from legitimate traffic.
- Malware scanning of message bodies and attachments.
- Anti-phishing and business email compromise detection, which looks for impersonation and payment-redirection attempts rather than for malicious files.
- URL and attachment sandboxing, opening a suspicious link or file in an isolated environment to see what it does before a user can, and in some products stripping the active content and rebuilding a safe version of the file instead of judging the original.
- Content filtering, applying organizational policy to what is allowed to pass in either direction.
- Data loss prevention, scanning outbound mail for information that should not leave the organization.
- Quarantine and user reporting, holding borderline messages and giving recipients a way to release or flag them.
- Post-delivery remediation, pulling a message out of inboxes after it has already been delivered, which an API-based deployment can do and an MX-based one cannot.
- Encryption and archiving, for compliance and retention.
Two of those run on outbound mail rather than inbound. A gateway is usually described as an inbound filter, but data loss prevention and content policy apply to messages leaving the organization as well, which is why a reply from a contact behind a gateway can be held or modified on its way back to you.
What does a secure email gateway miss?
Gateways are built around signals: known-bad links, malicious attachments, sender reputation, and patterns that look like spam. What consistently gets through is the attack carrying none of those, most often business email compromise, where a plain text message asks someone to change payment details and contains nothing a scanner can flag.
There is also a structural blind spot in the MX-based model. Mail between two colleagues at the same organization never leaves it, so it never passes a gateway sitting at the perimeter, which is part of why API-based products are sold alongside gateways rather than only against them.
How common are secure email gateways, and which vendors do enterprises run?
Among the largest US companies, a secure email gateway is the normal configuration. In our census of all 500 Fortune 500 primary corporate domains, 276 (55%) sat behind a gateway, 235 (47%) behaved as catch-all, and 344 (69%) were one, the other, or both. Only 156 domains (31%) ran a standard setup with neither.
The study is a census of all 500 companies rather than a sample, so there is no sampling margin of error, built on roughly 4.9 million individual validations. It is point-in-time as of late June 2026, and the full methodology is published with the study.
Among the 276 gateway-fronted domains, the vendor split is heavily concentrated:
Proofpoint accounts for four out of every five gateway deployments in the census. Barracuda and MessageLabs each appear once. The census counted which gateways these companies run, so a single appearance says something about adoption.
Underneath the gateway, the mailbox layer is more concentrated still. Microsoft 365 hosts 412 of the fortune 500 domains (82%), rising to roughly 85% once likely-Microsoft configurations are counted, against 17 (3%) on Google Workspace. The single most common enterprise email architecture is therefore a gateway sitting in front of Microsoft 365, which is the configuration the next two sections are about.
What does a secure email gateway do to legitimate senders?
A secure email gateway is built to stop malicious mail, and that is the job it is usually measured on. The side effect for legitimate senders sits somewhere else entirely: because the gateway answers on the mailbox's behalf, working out whether a given address exists becomes difficult.
Two questions get conflated here. (1) Whether your message gets filtered is a content, authentication, and reputation question, with levers you control: SPF, DKIM and DMARC alignment, sending volume, domain history, and what the message actually says. (2) Whether the recipient address is real is a data question, and none of those levers touch it. Almost everything published about gateways answers the first and leaves the second alone.
The mechanism is the MX record. Because it points at the gateway, the gateway is what answers a connection and a recipient probe, not the mailbox host behind it. Many gateways accept mail for any address at the domain and defer the recipient decision to the server behind them, so the acceptance carries no information about whether that mailbox exists. What a verification tool reports back then depends on its vocabulary: catch-all, accept-all, unknown, or risky, all describing the same non-answer.
Not every gateway behaves this way. A gateway can be configured to check each recipient against the organization's directory during the SMTP conversation and reject unknown addresses cleanly, which is why two domains running the same product can respond very differently. That is a deployment decision rather than a property of the software, and it is what the vendor comparison below actually measures.
Why does a test email tell you nothing behind a gateway?
When a gateway cannot deliver your message, it does not necessarily tell you so. Cisco's gateway documentation lists three dispositions for a recipient that fails a directory check: reject it during the SMTP conversation, send a delayed bounce, or drop the message entirely. Only the first of those produces the immediate failure a sender is watching for.
Many enterprise mail systems and gateways are configured to suppress non-delivery reports rather than return them, so a message to an address that does not exist is quietly discarded. Nothing comes back, and nothing coming back is not evidence that the person is real.
The delayed bounce is the second case. A gateway set to accept first and bounce later takes the message during the SMTP conversation, so the send looks successful, then returns the failure minutes or hours afterward, by which time a sequence has usually moved on. Treating the absence of an immediate bounce as confirmation is unreliable, and it is least reliable on exactly the enterprise domains where confirmation matters most.
How do Proofpoint, Mimecast, and Cisco IronPort differ in practice?
Every gateway below can be configured either to validate recipients against the directory or to accept mail and defer the decision, so what follows is how Fortune 500 enterprises set these products up. The rates are point-in-time, and a domain's behavior changes the day its administrators change a recipient validation setting.
A domain is counted as catch-all if it accepted mail addressed to a recipient that cannot exist, whether it accepted outright or accepted and bounced later. That classification is behavioral rather than configuration-based, and the Fortune 500 census carries the full method.
Proofpoint is where most of the enterprise population sits, and 145 of its 222 domains behaved as catch-all (65.3%). Every one of those cases was an accept-then-bounce, where the gateway takes the message during the SMTP conversation and returns the failure some time afterward instead of refusing it outright. The configuration that appears most often is Proofpoint in front of Microsoft 365, and it is also the least resolvable: of the 204 resolvable domains running it, 135 behaved as catch-all and 69 cleanly rejected unknown recipients.
Mimecast is the outlier. None of the 21 Mimecast-fronted domains behaved as catch-all, with 19 cleanly rejecting unknown recipients and 2 undetermined. Twenty-one domains is a small sample and the finding should be read as such, but the pattern is consistent, and the likely explanation is that these deployments validate recipients against the directory during the SMTP conversation instead of accepting and deferring.
Cisco IronPort recorded the highest rate in the set, 22 of its 31 domains (71.0%), all of them accept-then-bounce. Barracuda and MessageLabs appear once each, and a rate cannot be computed from a single domain.
Why are these configuration outcomes rather than vendor behavior?
Every product in the table can be set up either way, so the differences above reflect administrator decisions rather than software defaults. The same gateway produces opposite outcomes depending on how recipient validation was configured.
That makes these results a snapshot rather than a property. A domain that cleanly rejected unknown recipients in late June 2026 may accept and defer today, and the reverse is equally possible. The practical reading is that a gateway vendor tells you the odds, not the answer for any specific domain, which is why the address itself still has to be checked.
How should B2B teams handle contacts behind a secure email gateway?
There are two ways to get this wrong, and they cost differently. (1) Treating an unresolvable address as sendable produces delayed bounces that land after the campaign has finished, sequence steps spent on nobody, and reply rates measured against a denominator that was never real. (2) Discarding every unresolved address removes a large share of the enterprise TAM.
Resolving these addresses takes more than the standard verification checks. A legacy verifier tool that opens an SMTP conversation, reads the gateway's response, and reports it will return unknown on exactly the domains where the gateway was configured to accept and defer, because that is an honest reading of what the server actually said. Getting a conclusive result requires secondary diagnostics on the configuration itself, to establish whether a specific mailbox exists behind a server that accepts every address. The decision rules for what to do with each result, including when to send and when to suppress, are covered in our catch-all verification guide.
Allegrow is built for that layer. It runs secondary diagnostics against the receiving configuration instead of stopping at the gateway's response, which is what resolves an accept-everything domain into a conclusive valid or invalid for a specific address. Alongside that result, it flags spam traps, abuse addresses, and dead mailboxes as distinct outcomes. We ran that approach against ten other tools on a 10,000-record catch-all benchmark and Allegrow found the most real contacts of any tool tested, with the full results and method published here.
The sending side still matters, and it is a separate problem from the data side. A gateway filters on threat and spam signals, so the objective is to be a sender with a reputation that has no reason to be stopped: aligned SPF, DKIM and DMARC; a warmed sending domain with consistent volume; messages that read like they were written for the recipient; and bounces and complaints handled promptly. Our sender domain reputation guide covers that side in depth.
Conclusion
A secure email gateway is an inbound security control, and most large companies run one. Its side effect for legitimate senders has little to do with filtering: address validity simply stops being observable from outside. A gateway raises the odds that a domain answers “accepts” for every address, and the per-vendor rates show that outcome turns on how a deployment was configured rather than on which product was bought.
The practical consequence is that enterprise contacts need resolving conclusively before they enter a sequence, because the usual confirmation signal, an immediate bounce, is the one a gateway is least likely to give you.
To see how much of that applies to your own list, start a 14-day free trial and run Allegrow against up to 1,000 of your contacts. The ones worth pointing it at are the gateway-fronted enterprise domains your current tool hands back as catch-all or unknown, since those are the accounts where an answer is worth most and hardest to get.
Frequently asked questions about secure email gateways
What is a secure email gateway?
A secure email gateway is an email security product that inspects inbound and outbound mail for spam, phishing, malware and data loss before it reaches or leaves user mailboxes. It is deployed either in the mail path, with the domain's MX record pointing at it, or through an API integration with Microsoft 365 or Google Workspace.
Does a secure email gateway block cold emails?
Not for being cold outreach. A gateway filters on threat and spam signals, so legitimate, authenticated mail from a sender with a reasonable reputation is not blocked simply because the recipient did not ask for it. The more common practical problem is confirming that the address exists at all.
Can you verify an email address behind Proofpoint or Mimecast?
It depends on how that specific domain was configured rather than on which gateway sits in front of it. Some deployments check recipients against the directory and reject unknown addresses cleanly. Others accept every address and defer, which is where standard tools return unknown and specialized B2B verification like Allegrow can still reach a conclusive result.
How do you tell if a domain is behind a secure email gateway?
Look up the domain's MX records. If they point at a provider such as Proofpoint, Mimecast or Cisco rather than at Microsoft or Google directly, mail for that domain routes through a gateway before reaching the mailbox host. An API-based deployment will not show up this way, since it sits outside the mail path.
Do you still need a secure email gateway with Microsoft 365?
Many organizations do and many no longer do. Microsoft 365 includes native filtering, so some teams run an API-based product for post-delivery remediation instead of an MX-based gateway, while others keep the gateway for perimeter inspection before delivery. The choice changes how the domain answers a sender, which is what this page covers.
