This is the technical playbook for moving from ESET Mail Security for IBM/HCL Domino to SpamSentinel before the July 31, 2026 End of Life. Same architecture, same server, same operational model. No MX changes, no DNS rollback, no gateway introduced to the diagram. The smallest migration the email security industry knows how to ship.
ESET Mail Security ran natively on the Domino server. SpamSentinel runs natively on the Domino server. The mail flow is identical:
Sender's mail server
|
v
[ MX lookup -> your Domino server ]
|
v
HCL Domino + SpamSentinel installed
|
| scan, score, quarantine, log
v
Notes mail file / iNotes / HCL Verse
The complete list of core SpamSentinel product components, including required changes to notes.ini, EXTMGR_ADDINS, Domino services, and mail templates, is on the SpamSentinel support center.
A server restart is required at install. Most automated updates after that do not require a post-update restart.
Before cutover, document what ESET is actually delivering in your environment. This protects you from quietly dropping a feature you depend on and gives your auditors a clean before-and-after.
| ESET feature | SpamSentinel equivalent |
|---|---|
| Antispam engine | SpamSentinel antispam engine, tunable per environment, with InboxGenius preferred-sender learning to reduce false positives. |
| Antiphishing module | SpamSentinel antiphishing, native on Domino, still tuned and still shipped against current campaigns. |
| Attachment antimalware | SpamSentinel antimalware scanning, plus built-in macro blocking specifically focused on macro-bearing attachments, one of the most persistent delivery patterns in email-borne malware. |
| User-defined rules | Tunable rule engine, content-aware policies, practical knobs for the false-positive cases that actually show up in your environment. |
| Per-user quarantine release | Domino-native quarantine and end-user release path. Same operational model. |
| Logging and reporting | Domino-native log databases and reports. |
A common discovery during this inventory: "we use ESET for X" turns out to mean "we use ESET's quarantine UI, but the actual detection has been doing very little extra since 2023." That is useful information, not a problem. SpamSentinel replaces both, with detection that has continued to ship updates.
Surfaced here so you do not find them mid-deployment. We answer these the same way on every quote.
A typical small or mid-sized Domino environment runs this in 3 to 5 calendar weeks with 10 to 30 hours of admin time, weighted toward the configuration and validation phase.
Request a quote. The right SpamSentinel deployment specs depend on your Domino version, server topology, user count, and a handful of questions a Domino expert needs to ask. You answer those on the form. We come back the same day with a number and a deployment plan, not a discovery-call funnel.
Install SpamSentinel in a disabled state while ESET continues handling mail scanning. Configure SpamSentinel settings, policies, and rules. No disruption to mail flow during this phase — ESET remains active and unchanged.
Swap the EXTMGR_ADDINS entry in notes.ini from ESET to SpamSentinel and restart Domino. SpamSentinel is now actively scanning. The cutover requires a Domino restart but no DNS or MX changes.
After 7 days of clean SpamSentinel operation, remove ESET from the Domino servers. Run the ESET uninstaller, reclaim the CPU and memory, and update your asset inventory and audit documentation.
Rollback at any point during the pilot: Swap the EXTMGR_ADDINS entry in notes.ini back to ESET, restart Domino, and you are back where you started. No mail was misrouted, because the MX records never changed.
None of these are showstoppers. All of them are the kind of detail that catches Domino administrators off guard if they are not flagged in advance. The DuoCircle expert walks through each one with you during onboarding.
If you have Notes mail rules that act on ESET headers like X-EsetResult, they stop firing once ESET is disabled. Audit your rules against the Notes design before cutover. SpamSentinel emits its own headers, and the DuoCircle expert will tell you what they are during onboarding so you can update the rules in advance.
Long-standing anti-spam products accumulate allow-list and block-list entries — at both the sender and domain level — that made sense years ago but no longer reflect current mail flow. These lists can number into the thousands and often include senders who no longer exist, domains that have changed ownership, and blanket domain allows that now create security gaps. Before migrating to SpamSentinel, we review these with you and help decide what is still useful and what is just clutter. Since ESET and SpamSentinel use fundamentally different detection technologies, conditions that caused a false positive under the old product are unlikely to be a factor in the new one — carrying over every legacy rule defeats the purpose of a fresh start.
Install SpamSentinel on every Domino server listed in your MX records or configured as an SMTP gateway — including any standby servers that could be pressed into service during an outage. A clustered Domino server that only serves as a file replica and never handles SMTP routing does not need SpamSentinel. Configure and validate each mail-handling server individually during the migration.
If your Domino server receives inbound mail through intermediate SMTP relay servers, SpamSentinel needs to know about them. Without this configuration, RBL lookups and SPF evaluation may score the relay server's IP address instead of the original sender's, leading to incorrect spam verdicts. Similarly, internal servers that relay outbound mail through Domino should be excluded from spam scanning to avoid flagging legitimate internal traffic. Identify your relay topology during configuration so SpamSentinel evaluates the right source IPs.
SpamSentinel supports administrator-defined processing logic using Domino formula language — the same @formula syntax your team already knows. Run custom rules against each message before or after scanning, or use selection formulas to exclude specific messages from scanning entirely. Not every environment needs this, but for shops with specialized routing or compliance requirements, the extensibility is there without waiting on a vendor feature request.
Some shops use the ESET EOL as a trigger for a broader architectural change, moving from on-server scanning to a cloud gateway in front of Domino. That is a legitimate decision. It is bigger than the SpamSentinel path and not always the right call.
All of these run as MX-based gateways and work back-end agnostic, so they sit in front of Domino without platform-specific integration:
Not relevant for Domino: API-based products built for Microsoft 365 and Google Workspace (Avanan, Vade, and similar) integrate via Microsoft Graph or the Gmail API and do not have a meaningful HCL Domino integration.
A gateway cutover is fundamentally different from a SpamSentinel install: procurement and tenant provisioning (1 to 2 weeks), pilot routing through a subdomain or per-user (1 to 2 weeks), MX cutover with 300-second TTLs and 48 to 72 hours of monitoring, lock Domino's SMTP inbound to only accept mail from the gateway IPs, decommission ESET. Total calendar time: 4 to 8 weeks. Reversible at the DNS layer if needed.
See the full vendor comparison →Taking the on-server path (what we recommend for most Domino shops): request a SpamSentinel quote. Same-day response from an expert who has actually deployed SpamSentinel on Domino. We tell you yes or no quickly and line up the deployment if it is yes.
Taking the gateway path: see the replacement comparison. We will tell you honestly when one of our competitors is the better fit for your shop.
Not sure which is right for you: use the quote form anyway and tell us in the notes. A short conversation with a Domino expert saves weeks of evaluating against the wrong shortlist.
Tell us your Domino version, your user count, and your existing setup. We come back the same day with a real number and a deployment plan. The SpamSentinel path runs 3 to 5 weeks and comfortably fits inside the ESET EOL window.