Hosted email security is the deployment answer to a question buyers rarely ask out loud: where does the filtering actually run? In the hosted model, the security vendor runs the gateway in their cloud, your domain's mail records point at it, mail is inspected there, and only what passes is forwarded to your mailbox platform. The alternative is filtering inside the platform itself, native or API-integrated. The distinction sounds like plumbing and occasionally decides everything: a hosted gateway filters before mail touches your platform, works identically across mixed platforms, and keeps working, queuing mail, when the platform itself is down; the integrated model sees internal mail and platform context the gateway cannot. Small organisations meet the hosted model mostly through providers who resell it, so this guide explains what the choice implies, what the gateway genuinely adds, and the cutover facts to check before pointing your mail records at anyone.
How the hosted gateway sits in the flow
Your domain's MX records, the public signpost saying where your mail goes, point at the vendor's cloud instead of your platform. Everything inbound is scored, authenticated and sandboxed there; clean mail forwards on, held mail waits in the vendor's quarantine. Outbound can route the same way for filtering and signing. The immediate consequences: the vendor is now in your mail path for better and worse, their uptime is your mail uptime, and their quarantine is where missing mail is found, which is why the operational questions in the email security services guide apply doubly here.
What it adds, and for whom
Three genuine additions. Pre-platform filtering: bulk and known-bad mail never lands on your platform at all, which also trims what the platform's own tools must process. Platform independence: an organisation running mixed mailbox platforms, or migrating between them, gets one policy and one quarantine across both. And continuity: gateways queue inbound mail when the destination platform has an outage, releasing it after. The subtraction is context: a gateway cannot see internal mail between your own users, where account-takeover fraud often travels, which is what the API-integrated products see and the reason larger deployments frequently run both.
The cutover facts to check
Before any MX change: confirm existing SPF, DKIM and DMARC records will be updated to include the gateway, or authentication breaks the day you cut over; confirm where quarantine lives, who reviews it and the release turnaround; confirm queuing behaviour during platform outages, retention and maximum hold; and confirm the exit, what reverting MX records involves and whether held mail is exportable. Then write the result into your own documents: the mail policy naming the gateway, the quarantine procedure naming its reviewer. The free policy sheet on this site counts both into your set, and Hardenvo Pro generates them with the vendor, the reviewer and the turnarounds filled in as your answers.
Questions people ask about hosted email security
What is hosted email security?
Email filtering that runs in the security vendor's cloud: your MX records point at their gateway, mail is inspected and quarantined there, and clean mail forwards to your mailbox platform. It contrasts with filtering native to or API-integrated with the platform.
What are the advantages of a hosted email gateway?
Filtering before mail reaches the platform, one policy and one quarantine across mixed or migrating platforms, and mail queuing during platform outages. The trade is lost internal-mail visibility, which API-integrated tools keep, and a vendor now sitting in your mail path.
What should I check before switching MX records to a gateway?
That SPF, DKIM and DMARC will be updated for the gateway, who reviews the quarantine and how fast releases happen, how long mail queues during an outage, and what exit involves. Write the answers into your mail policy; the free sheet counts it into your set.