SpamExperts is a cloud-based email security solution that filters inbound and outbound email before messages reach your mail server or are delivered to external recipients. By detecting spam, phishing attempts, malware, and other email-borne threats, it helps protect business communications, improve email reliability, and reduce unwanted messages. Understanding how SpamExperts fits into the email delivery process makes it easier to determine whether it is the right solution for strengthening your organization’s email security.
Try SpamExperts Email Security →
What SpamExperts Is and Where It Sits in Your Mail Flow
SpamExperts is not a plugin that lives inside your mailbox; it’s a separate filtering layer positioned between the internet and your existing mail server, evaluating every message before your server ever sees it. Understanding that position is the key to understanding everything else about the product.
A Gateway, Not a Mailbox Feature
Most people’s first experience with spam filtering is the “Report Spam” button in Gmail or Outlook, a filter that runs after a message has already reached the mailbox and sorts it into a folder. SpamExperts works differently. It’s deployed as a mail exchange (MX) gateway, meaning your domain’s DNS is pointed at SpamExperts’ servers instead of directly at your own mail server. Every inbound message for your domain routes through that gateway first, gets evaluated, and only legitimate mail is forwarded on to your actual mailbox. Spam, malware, and other unwanted traffic never touches your server’s resources at all.
This distinction matters for two practical reasons. First, filtering happens before delivery rather than after, so a rejected connection never consumes your mail server’s bandwidth, disk space, or processing time. Second, because the gateway is separate from your mail server, SpamExperts can be deployed in front of almost any backend, Microsoft 365, Google Workspace, cPanel-based hosting, or a self-managed Exchange server, without requiring changes to how that backend itself operates. The gateway model is also what makes N-able SpamExperts available as either a hosted cloud service running across redundant, geographically distributed data centers, or as a self-hosted “Local Cloud” deployment for organizations that need to keep filtering infrastructure on their own premises. N‑able SpamExperts is designed to safeguard networks from inbound spam and malware and can be deployed in a redundant cloud environment or on-premises.
Where It Fits Relative to Your Existing Setup
Adding SpamExperts doesn’t mean replacing your email provider or migrating mailboxes anywhere. Your Microsoft 365 or Google Workspace subscription, your mailbox storage, and your calendar and collaboration tools all stay exactly where they are. What changes is a single set of DNS records: your domain’s MX records point to SpamExperts instead of directly to Microsoft or Google, and outbound mail is routed through SpamExperts’ smart hosts before it leaves your network. Everything else about the day-to-day email experience, the inbox, the interface, the mail client, stays unchanged for end users.
This “layer on top” architecture is why SpamExperts is commonly deployed by hosting and managed service providers as a value-added service across many client domains simultaneously, rather than as a single-tenant tool. A provider can filter mail for dozens or hundreds of domains through a single control panel, applying a consistent policy without touching each client’s underlying mail server configuration. For a business evaluating SpamExperts directly, the same principle applies on a smaller scale: it adds a protective layer without disrupting the email platform already used by the business.
How Cloud-Based Spam Filtering Works, Step by Step
Filtering a message isn’t a single check; it’s a sequence of evaluations that happen in milliseconds, each one capable of rejecting a message before it ever reaches the next stage. Knowing the sequence explains why legitimate mail rarely gets delayed while junk gets stopped early.
The Filtering Sequence, From Connection to Delivery
The process begins before a message’s content is even transmitted. When a remote server attempts to connect and send mail for your domain, SpamExperts first evaluates connection-level signals: the sending IP address’s reputation, whether it appears on real-time blacklists, and whether the connecting server’s behavior matches known spam-sending patterns. A meaningful share of junk mail is rejected at this stage, during the SMTP handshake, before a single byte of the message body is accepted. Rejecting at this pre-DATA phase is deliberate; it means the sending server, not SpamExperts, bears the cost of the failed attempt, and legitimate senders whose mail was temporarily rejected will typically retry automatically per standard SMTP behavior.
Messages that pass connection-level checks move to content and authentication analysis. This stage evaluates the message envelope and headers against authentication records (covered in detail later in this guide), checks message content against pattern-matching and heuristic rules, and screens attachments for known malware signatures. Messages that fail decisively at this stage are rejected outright; messages that fail marginally or trigger some but not all criteria are quarantined rather than delivered or discarded, giving the recipient a chance to review and release a message that was flagged incorrectly.
Why Layered Filtering Reduces False Positives
A single-technique filter, one that relies purely on keyword matching, for instance, either lets too much spam through or blocks too much legitimate mail, because any one signal in isolation is easy for spammers to game and easy for genuine senders to trip accidentally. Layering multiple independent checks changes the math: a message has to fail several unrelated tests simultaneously to be rejected outright. In contrast, a message that fails only one or two ambiguous checks lands in quarantine instead of being silently deleted. This is why quarantine exists as a distinct outcome from outright blocking; it’s the system’s way of handling uncertainty rather than forcing a binary decision on every message.
This layered approach also adapts over time. When a recipient releases a quarantined message and marks it as legitimate, or reports a delivered message as spam that slipped through, that feedback retrains the filtering engine’s pattern recognition for future messages with similar characteristics. Administrators overseeing multiple domains benefit from this shared learning across the aggregate traffic the platform processes, which is part of why a centrally managed filtering service tends to improve faster than a single mail server relying only on its own local traffic history.
Inbound Filtering: How Spam Gets Stopped Before the Inbox
Inbound filtering is half of SpamExperts that most people picture when they hear “spam filter”, the system standing between the outside world and a recipient’s mailbox. It’s built to catch a wide range of unwanted traffic, not just spam.
What Counts as “Inbound Threats” Beyond Plain Spam
Commercial spam, unsolicited advertising, is only one category that inbound filtering handles. The same gateway also screens for messages carrying malicious attachments or links (detection specifics for this category belong to a dedicated malware discussion elsewhere in this cluster), directory harvest attacks where a sender probes a domain for valid email addresses by mass-guessing usernames, and backscatter, automated bounce messages generated when spammers forge your domain as the sender (“From”) address on mail they send to invalid addresses elsewhere. Backscatter, in particular, is a category many businesses don’t realize is a problem until their domain’s reputation starts to degrade because other mail servers are auto-replying to forged messages that were never actually sent by them.
Inbound filtering also handles graymail, newsletters, marketing mail, and automated notifications that aren’t malicious but that recipients often don’t want cluttering a primary inbox. Because graymail sits in a gray zone between “wanted” and “unwanted,” SpamExperts’ handling of it is typically governed by adjustable sensitivity thresholds rather than a fixed rule, allowing an administrator to tune how aggressively borderline content is filtered versus delivered to the recipient for manual sorting.
What Happens to a Message Once It’s Flagged
A flagged inbound message follows one of three paths, and which path it takes depends on how confidently the system classified it. Messages matching known-bad signatures with high confidence are rejected at the connection level and never enter your infrastructure. Messages that fail content-based checks after being accepted are routed to quarantine rather than deleted outright, an IMAP-backed store the recipient or an administrator can search and review. Quarantined messages are stored for 14 days by default, giving recipients a reasonable window to catch and release any misclassified messages before they’re automatically purged. A third category, messages classified as spam with lower confidence, can be tagged rather than blocked, delivered to the inbox with a modified subject line or header so mail client rules can sort them, depending on how an administrator configures that domain’s sensitivity settings.
Release from quarantine isn’t just a delivery action; it’s also a training signal. When a recipient releases and trains a quarantined message, it’s delivered to the original recipient, and the correction is reported back to the filtering system to improve future classification accuracy. This closes the loop between a single recipient’s judgment and the broader filtering model, which is one reason why accuracy in a given domain tends to improve the longer the filter has been actively used and corrected, rather than left on default settings indefinitely.
Outbound Filtering: Protecting Your Sending Reputation
Inbound protection gets most of the attention, but outbound filtering exists for a different and arguably higher-stakes reason: a single compromised mailbox sending spam from your domain can get your entire domain blacklisted, breaking deliverability for every legitimate sender on it.
Why Outbound Filtering Is a Reputation Problem, Not Just a Security One
Email reputation is tracked per sending IP address and, increasingly, per sending domain, by receiving mail servers and blacklist services across the internet. If even one compromised account on your domain starts sending spam, a common outcome of a phished password or a malware-infected device, the volume and pattern of that outbound traffic can trigger automatic blacklisting of your domain or sending IP within hours. Once blacklisted, every other user on that domain may find their entirely legitimate email bouncing or landing in recipients’ spam folders, often for days, until the domain is delisted. Outbound filtering is designed to detect and block outgoing spam before it leaves your network, so a single compromised account doesn’t undermine deliverability for the whole organization.
The mechanics mirror inbound filtering but apply to traffic leaving rather than entering: outbound messages are evaluated against the same content, pattern, and behavioral signals, and a domain’s administrator can set connection and recipient-count limits, a maximum number of outgoing connections per hour or recipients per day, specifically to catch the volume spikes characteristic of a compromised account being used to blast spam. Administrators can configure limits on outgoing connections per minute, hour, day, week, and month, along with a maximum number of recipients a user can send to daily, precisely to prevent this kind of bulk abuse.
Quarantine Response Options for Outgoing Mail
When an outgoing message is caught as spam, an administrator chooses how the sender is notified, and that choice has real operational consequences. If the quarantine response is set to “Rejected,” the legitimate sender receives a bounce message informing them their mail was blocked, even though the message remains stored in the outgoing quarantine; if set to “Accepted,” the SMTP response indicates acceptance and the sender receives no bounce notice at all, even though the message is still blocked and held in quarantine. The rejected setting is more transparent to a legitimate sender who made an innocent mistake. In contrast, the accepted setting is often preferred when the outgoing account may be compromised, since it avoids tipping off the misuser that their messages are being intercepted.
Administrators are kept in the loop separately from the sender through an abuse report mechanism that notifies a designated contact address whenever messages land in the outgoing quarantine, so a spike in outbound spam attempts is flagged to IT even before a recipient or blacklist service notices anything unusual. This administrator-facing visibility is what turns outbound filtering from a passive backstop into an early-warning system for account compromise, often the first concrete signal that a particular mailbox has been breached, well before the compromise shows up anywhere else.
Outbound Quarantine Response Settings vs. What the Sender Sees vs. Best Fit
| Response Setting | What the Legitimate Sender Sees | Best Fit For |
|---|---|---|
| Rejected | A bounce notification that the message was blocked | Transparent handling for likely innocent mistakes |
| Accepted | No notification; message silently held in quarantine | Suspected account compromise, to avoid alerting misuse |
The Detection Technology Behind SpamExperts
“Advanced filtering” is a phrase every vendor in this category uses, and it explains almost nothing on its own. What actually determines whether a message gets caught is a specific, describable set of techniques working together, and understanding them is what separates an informed buyer from one relying on marketing language.
The Core Techniques, Named and Explained
Reputation-based filtering checks the sending IP address and domain against real-time blacklists and historical sending behavior data; servers with a track record of sending spam get flagged or rejected before content is even evaluated. Content and heuristic analysis examines the message body, subject line, and structure against pattern libraries built from previously classified spam, looking for the phrasing patterns, formatting tricks, and structural markers that correlate with unwanted mail. Authentication verification checks the message against published SPF, DKIM, and DMARC records for the claimed sending domain (explained in full in the next section) to catch messages forged to appear to come from a domain they didn’t actually originate from. The inbound filter is driven by a continuously updated Intelligent Protection & Filtering Engine built specifically to keep pace with emerging threats, meaning the pattern libraries and reputation data behind these checks are refreshed on an ongoing basis rather than set once and left static.
Behavioral and volumetric analysis rounds out the core set, tracking sending patterns over time rather than evaluating any single message in isolation, a sudden spike in messages from one account, an unusual burst of connections from a normally quiet sending IP, or a pattern of nearly identical messages sent to sequential or non-existent addresses. This category of detection catches directory-harvest attempts and compromised-account abuse, since neither necessarily triggers content-based rules on any individual message. Still, both create a detectable pattern across many messages.
How the Techniques Combine in Practice
No single technique operates alone in a real evaluation; a message typically has to fail multiple independent checks to be rejected outright, which is the mechanism referenced earlier as the reason layered filtering produces fewer false positives than any one technique used in isolation. In practice, that means a legitimate marketing email from a well-reputed sending domain with correct authentication records will usually pass even if its content resembles promotional language. In contrast, a message from an unreliable or untrusted IP address with broken authentication and spam-like content will be rejected before a human even reads it.
The practical implication for a business is that filtering accuracy depends partly on factors outside SpamExperts’ own configuration, specifically, whether your own outbound authentication records (SPF, DKIM, DMARC) are set up correctly, since a poorly configured DMARC record on your own domain can cause your own legitimate outbound mail to fail authentication checks at other organizations’ filters, independent of anything SpamExperts is doing on the inbound side. This is a common gap: organizations get inbound filtering right but never audit their outbound authentication posture, weakening the deliverability of the mail they send.
Getting Inbound and Outbound Filtering Configured Correctly the First Time
Pointing MX records to a new gateway and setting sensible outbound limits may sound simple. Still, a misconfigured DNS cutover can bounce legitimate mail for days, and default sensitivity thresholds rarely match a specific domain’s actual traffic patterns. As an Authorized Reseller and Certified Sales Partner for SpamExperts, Hiya Digital handles this configuration directly, validating DNS changes before cutover, setting outbound limits appropriate to your actual sending volume, and tuning quarantine sensitivity based on your domain’s real traffic rather than defaults built for an average case. That upfront correctness is the difference between a filtering layer that quietly works and one that generates support tickets for months.

Who SpamExperts Is Built For
A gateway-based filtering platform serves one kind of buyer well and another poorly; recognizing which category a business falls into is the fastest way to know whether this is the right tool at all.
The Common Thread Across Adopters
Across the range of organizations that adopt dedicated email filtering, a recurring pattern shows up: it’s rarely the first line of defense a business sets up, and almost always a response to something that already went wrong with a built-in filter. A business running only the spam filtering bundled into its existing mailbox platform typically switches to a dedicated gateway after a specific triggering event, a phishing message that got through and led to a compromised account, a period of persistent false positives where legitimate customer email was landing in spam, or a compliance requirement (from an industry regulator, a cyber-insurance policy, or a client contract) that mandates dedicated email security controls beyond what a mailbox provider includes by default.
This pattern matters because it means the buying decision is rarely proactive risk management in the abstract; it’s a response to a specific, often costly incident. Recognizing that a built-in filter’s limitations are the actual trigger, rather than “email security” as a vague category, helps frame what dedicated filtering needs to solve: not marginally better spam catching, but closing a specific gap that already caused a problem.
Where Dedicated Filtering Adds the Most Value
The clearest fit is any organization with a domain-wide dependency on email as a primary communication and transaction channel, meaning a phishing incident or extended deliverability outage carries real financial or reputational cost, not just inconvenience. That includes organizations handling sensitive client data where a compliance framework requires demonstrable email security controls, organizations that have already experienced a compromised-account incident and need outbound monitoring specifically to prevent a repeat, and organizations sending high volumes of transactional or customer-facing email where deliverability failures directly affect revenue. Detailed guidance scoped specifically to small businesses and to educational institutions, two categories with meaningfully different needs and constraints from the general case, is covered in dedicated posts elsewhere in this series.
Conversely, a very small operation with minimal email-based risk exposure and a built-in filter that has never caused a problem may reasonably conclude dedicated filtering isn’t yet justified. The honest framing here is that email security spending should track actual risk exposure and incident history, rather than a blanket assumption that every organization needs the same tier of protection regardless of size or how email is used.
SpamExperts for Hosting Providers and MSPs
Hosting providers and managed service providers represent a distinct buyer category from single-domain businesses; they’re not filtering one mailbox environment; they’re reselling or bundling filtering across many client domains at once, and that changes what matters most in the platform.
Multi-Tenant Management as the Core Requirement
A hosting provider managing spam filtering for hundreds of client domains needs centralized administration far more than any single-domain buyer does: a single control panel to provision new domains, apply a consistent baseline policy, and monitor aggregate filtering activity across the entire client base, rather than logging into a separate interface for each domain. SpamExperts’ architecture is built around exactly this kind of domain-level and admin-level hierarchy: a super-administrator tier that oversees the whole platform, domain-level controls that individual client administrators can access for their own domain, and email-level access for individual end users to manage their own quarantine, three tiers of access mapped directly onto how a reseller’s client base is actually structured.
This tiered structure is also what makes white-labeling and branded deployment realistic for a reseller. Interface branding (including branded MX hostnames rather than generic SpamExperts hostnames appearing in a client’s DNS records) lets a hosting provider present filtering as a native part of their own hosting stack rather than as a visibly third-party bolt-on, which matters for a reseller’s own brand positioning with their end clients.
Why Filtering-as-a-Service Fits the MSP Business Model
For an MSP, dedicated email filtering solves a specific operational problem beyond security: it removes spam-related support tickets from the MSP’s queue. A significant share of routine helpdesk volume for any MSP managing client email is spam- and phishing-related, a client reporting suspicious mail, asking why a legitimate message landed in spam, or dealing with a compromised account sending junk to their contact list. Filtering at the gateway level, before mail reaches a client’s mailbox at all, directly reduces that ticket volume, yielding a concrete operational cost saving beyond the security benefit itself.
The reseller economics also differ distinctly from the end-buyer economics: an MSP purchasing at volume and reselling to clients as part of a broader managed-services bundle has a different cost structure and margin considerations than a single business buying directly for itself. Package tier and pricing structure specific to that decision are covered in a dedicated pricing post elsewhere in this series, as they depend on volume and bundling considerations that fall outside the general definitional scope of this guide.
Filtering Technique vs. What It Evaluates vs. Typical Trigger
| Detection Technique | What It Evaluates | Typical Trigger Example |
|---|---|---|
| Reputation-based filtering | Sending IP and domain history against real-time blacklists | Server previously flagged for spam sending |
| Content and heuristic analysis | Message body, subject, and structural patterns | Phrasing or formatting matching known spam libraries |
| Authentication verification | SPF, DKIM, and DMARC records for the claimed sender | Failed or missing authentication for the sending domain |
| Behavioral/volumetric analysis | Sending patterns over time, not single messages | Sudden spike in volume from a normally quiet account |
Email Authentication Standards SpamExperts Relies On
Spam filtering isn’t just about analyzing message content; a significant share of what determines whether a message is trustworthy depends on whether the sending domain can prove it actually sent the message. That’s what authentication standards exist to establish.
SPF, DKIM, and DMARC, in Plain Terms
Sender Policy Framework (SPF) is a DNS record published by a domain owner that lists which mail servers are authorized to send email on that domain’s behalf; a receiving server checks the sending IP address against that list, and a mismatch is a strong signal that the message is forged. DomainKeys Identified Mail (DKIM) works differently; it attaches a cryptographic signature to outgoing messages, generated using a private key the sending domain controls, and the receiving server verifies that signature against a public key published in DNS; a valid signature proves the message wasn’t altered in transit and genuinely originated from a server holding that domain’s private key. Domain-based Message Authentication, Reporting, and Conformance (DMARC) sits on top of both; it’s a policy record telling receiving servers what to do when a message fails SPF or DKIM checks (quarantine it, reject it outright, or take no action). It also enables reporting back to the domain owner about authentication failures happening across the internet for their domain. Authoritative technical details on how these three standards are defined and should be implemented are available at dmarc.org, the industry reference maintained by the organizations that jointly developed the DMARC specification.
SpamExperts checks all three of these records as part of its inbound evaluation pipeline for every message claiming to be from a given domain, and DKIM signing is configurable directly at the domain level for outbound mail passing through the platform. Domain administrators select a DKIM selector, either the platform’s default or one generated through the DKIM certificate generation tool, and then publish the resulting TXT record to their domain’s DNS to activate signing for outbound mail.
Why Authentication Gaps Undermine Filtering Even When It’s Working Correctly
A domain with no SPF record, no DKIM signing, and no DMARC policy is significantly easier to spoof, meaning attackers can send phishing emails that appear to come from that domain without ever compromising anything on the actual mail server. This is precisely the scenario that backscatter and business email compromise attacks exploit: forging a “From” address on a domain with weak or absent authentication, since nothing stops the forgery from passing basic checks at the receiving end. Setting up proper authentication is therefore not a separate security project from spam filtering; it’s a prerequisite that makes the filtering that does exist meaningfully harder to circumvent.
The practical consequence for deliverability specifically is that a domain with a correctly configured DMARC policy set to enforcement (reject or quarantine, rather than the weaker “none” monitoring-only mode) sees dramatically less of its own domain used in spoofed phishing sent to third parties, and often sees improved inbox placement for its own legitimate outbound mail at major receiving providers like Gmail and Microsoft 365, both of which weight DMARC enforcement into their own inbound filtering decisions. Given how directly this affects a business’s outbound deliverability, DMARC configuration status is one of the first things to audit alongside any spam-filtering deployment, rather than treating the two as unrelated projects.
Quarantine, Logs, and Day-to-Day Visibility
Filtering that operates invisibly, with no way to review what was blocked or search historical activity, creates its own risk; a legitimate message misclassified as spam and silently discarded is a real business cost. Visibility tooling exists specifically to make filtering decisions reviewable rather than opaque.
What the Quarantine and Log Search Actually Show
The spam quarantine is a searchable, IMAP-backed store of every message the system blocked and held rather than outright rejected at the connection level, accessible to email-level users to view their own inbound messages blocked and stored as spam, with query filters available to narrow results and mass actions available for handling multiple messages at once. Beyond individual mailbox visibility, a separate log search function lets an administrator search all incoming mail activity for a domain, filterable by sender name, host, sending IP, recipient, and date range, which is the tool used to investigate a specific delivery question (“did this expected message actually arrive, and if not, what happened to it?”) rather than browsing the quarantine folder generally.
This distinction between quarantine and log search matters operationally: quarantine shows messages that were held for review, while log search shows the full record of every connection attempt and its outcome, including messages rejected outright at the SMTP level that never reached quarantine. A support investigation into “why didn’t I receive an expected email” typically starts in log search rather than quarantine, since a hard-rejected message, the most common outcome for high-confidence spam, won’t appear in the quarantine folder at all.
Actions Available on a Quarantined or Logged Message
From either the quarantine or the log search interface, an administrator or end user has several available actions on a given message: release it to deliver as normal, release and train it (which both delivers the message and reports the correction back to improve future classification, as covered earlier in this guide), block the sender outright and remove the message, or release and whitelist the sender so future messages from that address bypass filtering entirely. Each action is represented by a distinct icon in the search results, with some actions restricted for email-level users versus domain or super-administrator accounts, reflecting the same tiered permission structure described earlier for multi-tenant hosting deployments.
For a business evaluating this tooling, the practical takeaway is that quarantine and log visibility function as an audit trail as much as a delivery-recovery tool, a documented, searchable record of every filtering decision made on a domain’s mail traffic, which is directly relevant to any compliance requirement around demonstrable email security controls, a topic covered in more depth in a dedicated compliance-focused post elsewhere in this series.
Deployment Models: Gateway Filtering vs. Built-In Provider Filters
Every major email platform, Microsoft 365, Google Workspace, and most hosting-provider webmail, ships with some baseline spam filtering already active. Understanding what a dedicated gateway adds on top of that baseline at the category level is the last piece needed to evaluate whether SpamExperts belongs in a given mail flow at all.
What Built-In Filtering Typically Covers and Where It Stops
Built-in filtering in a mailbox platform generally handles the most obvious, high-volume spam and known malware signatures reasonably well, since these providers process enormous volumes of mail and have correspondingly large reputation datasets. Where built-in filtering tends to be weaker, as a general category rather than a claim about any specific named provider, is in administrator-level control granularity, outbound filtering depth (most consumer and even many business-tier mailbox platforms focus overwhelmingly on inbound protection), and cross-domain visibility for anyone managing more than one domain’s mail traffic. Built-in filtering is also generally not deployed as a separate MX-level gateway; it operates as a feature within the platform itself, which means there’s no equivalent to the pre-DATA-phase connection rejection described earlier in this guide, since the mail has already been accepted by the platform’s own infrastructure by the time filtering runs.
A named, feature-by-feature comparison against specific competing platforms and dedicated alternatives is outside the scope of this guide and covered in a separate comparison post elsewhere in this series; what’s relevant here is the structural distinction, gateway-based filtering versus platform-native filtering, rather than any specific vendor-versus-vendor claim.
When a Dedicated Gateway Layer Is Worth Adding on Top
The case for adding a dedicated gateway layer on top of an already-capable built-in filter usually comes down to three factors covered throughout this guide: outbound filtering depth (since built-in inbound protection does nothing to stop a compromised account from damaging your domain’s reputation through outbound spam), cross-domain administrative control (relevant specifically to hosting providers, MSPs, and any organization managing multiple domains centrally), and the audit-trail and quarantine visibility depth needed to satisfy a specific compliance requirement. None of these factors is universal; a single-domain business with no compliance mandate and no history of compromised-account incidents may reasonably find built-in filtering sufficient on its own.
Where a dedicated gateway is added, it typically runs as a genuine additional layer rather than a replacement; MX records point to SpamExperts first, and SpamExperts forwards clean mail on to the existing platform (Microsoft 365, Google Workspace, or otherwise), meaning both layers of filtering are active simultaneously rather than one replacing the other. Compatibility specifics for each of those two major platforms are covered in dedicated posts elsewhere in this series.
Frequently Asked Questions
What is SpamExperts?
SpamExperts is a cloud-based email security platform, now owned and operated by N-able, that filters inbound and outbound email traffic for a domain before messages reach mailboxes or leave the network. It’s deployed as a gateway, meaning a domain’s MX records point to SpamExperts rather than directly to the mail server, and can run either through N-able’s hosted cloud infrastructure across multiple redundant data centers, or as a self-hosted “Local Cloud” deployment on an organization’s own premises. It works alongside any existing email platform, including Microsoft 365, Google Workspace, and traditional hosting-based mail servers, without requiring mailbox migration or changes to the underlying platform itself.
How does SpamExperts work?
SpamExperts evaluates every message through a sequence of checks before delivery: connection-level reputation screening against real-time blacklists, content and heuristic pattern analysis, authentication verification against SPF, DKIM, and DMARC records, and behavioral analysis for volume and pattern anomalies. Messages matching high-confidence spam signatures are rejected during the SMTP handshake, before the message body is even accepted. Messages that fail some but not all checks are quarantined rather than rejected outright, giving recipients or administrators a window to review and release any misclassified messages. The default quarantine retention period is 14 days on the standard hosted cloud service.
Is SpamExperts a cloud-based service or installed software?
It’s available in both forms. The default and most common deployment is N-able’s hosted cloud service, running across geographically redundant data centers with no infrastructure to install or maintain on the customer’s side. A “Local Cloud” option also exists for organizations that need filtering infrastructure to remain on their own premises, typically larger hosting providers or organizations with specific data-residency requirements, and that self-hosted version allows some settings, including quarantine retention duration, to be customized beyond the hosted cloud’s defaults.
Does SpamExperts filter both incoming and outgoing email?
Yes, and this two-way coverage is one of its defining features compared with filters that focus on inbound protection alone. Inbound filtering screens messages arriving at a domain’s mailboxes, catching spam, phishing attempts, malware, and directory-harvest attacks before delivery. Outbound filtering screens messages leaving the domain, specifically designed to catch a compromised mailbox being used to send spam before that activity damages the domain’s sending reputation and triggers blacklisting that would affect every legitimate sender on the same domain.
What size businesses use SpamExperts?
Adoption spans from small businesses managing a single domain through large enterprises and hosting providers managing filtering across hundreds of client domains simultaneously. The platform’s tiered administrative structure, super-administrator, domain-level, and individual email-user access, supports both ends of that range: a small business typically only interacts with domain-level and email-level controls. At the same time, a hosting provider or MSP uses the super-administrator tier to provision and manage multiple client domains from a single interface. Dedicated guidance for small-business deployments, specifically, where needs and configuration differ from those in an enterprise or reseller context, is covered elsewhere in this series.
Can SpamExperts work alongside my existing mail server?
Yes, this is the core of how it’s designed to be deployed. SpamExperts sits in front of an existing mail server or hosted mailbox platform as a filtering gateway rather than replacing it. Setup involves repointing a domain’s MX records to SpamExperts and configuring outbound mail to route through SpamExperts’ smart hosts; the existing mail server or platform continues handling actual mailbox storage, calendaring, and the end-user mail client experience exactly as before. Step-by-step setup instructions are covered in a dedicated configuration guide elsewhere in this series.
Does SpamExperts store or read the content of my emails?
Filtered inbound messages that are quarantined rather than delivered are held in an IMAP-backed quarantine store, accessible to the recipient and, depending on permission tier, to a domain administrator, for the duration of the retention period, 14 days by default on the hosted cloud service. The filtering engine evaluates message content as part of the classification process described throughout this guide (pattern matching, heuristic analysis, and authentication checks), which necessarily involves automated inspection of message content and headers to determine spam classification, separate from any human review.
How is SpamExperts different from a simple spam folder built into webmail?
A webmail spam folder filters messages after they have already been fully accepted and delivered by your mail server; the filtering occurs within the mailbox platform itself. SpamExperts filters before delivery, at the MX gateway level, so high-confidence spam is rejected during the SMTP connection and never consumes your mail server’s storage or processing resources. This gateway position also enables outbound filtering, cross-domain administrative control, and detailed connection-level log search, none of which a mailbox-native spam folder is architecturally positioned to provide, since it only ever sees mail after acceptance.
What happens to a message SpamExperts identifies as spam?
The outcome depends on classification confidence. High-confidence spam is rejected outright during the SMTP handshake and never delivered or stored anywhere. Messages that fail some but not all filtering criteria are routed to quarantine, where they are held for 14 days by default rather than deleted, giving the recipient a chance to review and release anything misclassified. Lower-confidence matches can alternatively be tagged and still delivered to the inbox with a modified subject line, depending on how sensitivity is configured for that specific domain.
Do I need technical expertise to understand how SpamExperts protects my domain?
No day-to-day technical expertise is required to use the platform’s default configuration; quarantine review and message release are handled through a standard web interface, and default filtering thresholds are built to work reasonably well without manual tuning. Some technical understanding becomes relevant when configuring DNS records during initial setup (MX records, SPF, DKIM selectors) or when adjusting outbound connection limits and sensitivity thresholds beyond the defaults, which is typically where a reseller or IT partner’s implementation support adds the most practical value over a fully self-managed setup.
Glossary
SPF (Sender Policy Framework): A DNS record listing which mail servers are authorized to send email for a domain, used by receiving servers to detect forged sending addresses.
DKIM (DomainKeys Identified Mail): A cryptographic signature attached to outgoing messages, verified against a public key in DNS, proving a message wasn’t altered in transit and originated from a server holding the domain’s private key.
DMARC (Domain-based Message Authentication, Reporting, and Conformance): A policy record that tells receiving servers what to do when a message fails SPF or DKIM checks, and enables authentication-failure reporting back to the domain owner.
SEG (Secure Email Gateway): A filtering system deployed at the mail exchange (MX) level, evaluating messages before they reach a mail server, rather than filtering within a mailbox platform itself.
Quarantine: A holding area for messages that failed some but not all spam-detection criteria, stored for a defined retention period (14 days by default on SpamExperts’ hosted cloud) rather than being rejected or delivered outright.
Backscatter: Automated bounce messages generated by other mail servers in response to spam that forged your domain as the sender address, even though the original spam was never actually sent by you.
MX record: A DNS record specifying which server should receive email for a domain; pointing this record at a filtering gateway is what routes inbound mail through that gateway before it reaches the actual mail server.
Directory harvest attack: An attempt by a sender to discover valid email addresses on a domain by mass-guessing usernames and observing which attempts succeed versus bounce.
The Hiya Digital Team is a collective of IT infrastructure specialist engineers, certified systems administrators, and cloud architects driven by a singular mission: building corporate communication systems that just work. As an Authorized Google Partner, the team handles complex global hosting deployments, secure email migrations, and advanced data compliance architectures for businesses across 40+ countries.
With over two decades of technical experience spanning custom premium business email configurations, OX AppSuite deployments, and enterprise-level network security, the Hiya Digital Team writes to demystify domain infrastructure. Their content focuses on actionable technical strategies, anti-phishing security protocols, and seamless cloud collaboration setup, all backed by real-world deployment experience and 24/7 technical support accountability.

A Gateway, Not a Mailbox Feature
Why Outbound Filtering Is a Reputation Problem, Not Just a Security One
Multi-Tenant Management as the Core Requirement
What Built-In Filtering Typically Covers and Where It Stops















