An honest answer from people who have been doing this since 2010.
If you run mail on Microsoft 365 or Google Workspace, you already have spam filtering. Exchange Online Protection is included, it is competent, and for a lot of organisations it is genuinely enough. Anyone who tells you otherwise is selling something.
So the honest question is not whether built-in filtering works. It is whether the specific gaps it leaves are gaps that cost you anything. This page walks through where those gaps actually are, what changes technically if you decide to close them, and where a third-party filter is a waste of money.
This is the one people underestimate. When your mail server is unreachable, senders get bounces or their servers retry until they give up. A filter sitting in front keeps accepting mail and spools it until your server answers again. SpyderMail holds mail for 7+ days. If you have ever lost a day of inbound email to an outage, you already know what that is worth.
Built-in quarantine tends to be an all-or-nothing admin job. A dedicated filter gives every address, including aliases, its own quarantine with its own allow and block lists, and lets each user decide what is spam for them. That is less work for you, not more.
Two detection engines with different rule sets and different update cycles catch different things. If a campaign gets through one, the other has a fair chance of stopping it. This is the genuine security argument, and it is a real one.
When a client's invoices stop arriving, the question is how quickly a human can look at the headers with you. Support quality is the least technical item on this list and often the one that decides it.
You do not need to run an Exchange server to use a filtering service. If someone else hosts your mail, the change is a DNS record in their control panel. Nothing moves.
Outbound scanning matters if a compromised account in your organisation could start sending on your behalf. It protects your domain's reputation rather than your inbox.
We would rather say this plainly than have you find out after signing up.
Today your MX records point at your mail server or your Microsoft 365 tenant. They get repointed at the filtering service, which scans the mail and delivers what is clean onward to exactly where it went before. Mailboxes, clients and calendars do not move.
With SpyderMail you get three MX addresses at different priorities, and Canadian customers land in Canadian data centres. They look like this:
yourdomain.com MX preference = 10, mail exchanger = yourdomain-com.mx1-ca.mailanyone.net yourdomain.com MX preference = 20, mail exchanger = yourdomain-com.mx2-ca.mailanyone.net yourdomain.com MX preference = 30, mail exchanger = yourdomain-com.mx3-ca.mailanyone.net
You can confirm the change has taken with a single command:
nslookup -type=mx yourdomain.com
How long it takes to propagate depends entirely on the TTL on your existing records. Nothing breaks during the change: mail arriving at the old address still gets delivered while DNS catches up.
This step gets skipped and it matters more than anything else on this page. Once mail flows through a filter, configure your firewall to accept inbound SMTP on port 25 only from the filtering service's IP ranges.
If you do not, spammers can look up your server's real address and deliver straight to it, walking around the filter you are paying for. Spammers read MX records as easily as you do. A filter with an open port 25 behind it is a filter you are only partly using.
If your remote users send mail through your server over SMTP, locking port 25 affects them. The usual answer is a second authenticated submission port, 587 or 465, so their mail still originates from your server and still passes SPF checks at the receiving end.
If your remote users connect over VPN, webmail or remote desktop, this does not apply to you.
SPF lets you declare which hosts are allowed to send mail as your domain. If you add outbound filtering, the filter becomes one of those hosts and belongs in the record. Inbound-only filtering does not change your SPF at all.
| Built into Microsoft 365 | Added filter in front | |
|---|---|---|
| Bulk spam and known malware | Handled well | Handled well, by a second engine |
| Mail during an outage | Senders retry or bounce | Spooled and delivered later |
| Per-user quarantine control | Largely an admin task | Per address, including aliases |
| Second detection opinion | One engine | Two, with different rule sets |
| Support when something is wrong | Ticket queue | Depends entirely on the vendor |
| Extra cost | None, you already pay for it | Per user, per month |
| Setup effort | None | One DNS change, one firewall rule |
We have been filtering business email since 2010 and have put more than 6.5 billion messages through the service. Optrics Engineering, our parent company, has been in email security since the early days of the category.
Practically, SpyderMail steps between the internet and your existing mail server. We do not host your mail and we do not want to. What you get is per-user quarantine with daily summary emails that need no password to action, per-user allow and block lists, dual-layer virus scanning, anti-spoofing, 7+ days of mail bagging, geographically redundant data centres, and spam and virus definitions updated hourly.
The part we would actually put money on is the support. You get a person during office hours, the service is monitored 24/7 with staff on call, and there is no charge for SpyderMail-related support. That is the difference a small operator can offer and a large one structurally cannot.
If you are on Microsoft 365 specifically, we have a page on how SpyderMail sits alongside your tenant. If you want the full technical detail of what the service does, how it works covers it, and the setup guide has the MX, firewall and SPF specifics in full.
30 days, every feature enabled, one MX record change to start and one to stop.