How to Whitelist a Domain in Imunify360 to Disable the CAPTCHA Check

Let’s get straight to the point. Your domain is serving real traffic — maybe an online store, a customer portal, or an API consumed by apps — and Imunify360 keeps throwing a CAPTCHA at everyone who lands on it. Legit visitors get annoyed and bounce. Your integrations can’t solve a CAPTCHA at all, so they just fail silently. The fix is clean: whitelist the domain so the CAPTCHA check is skipped for it entirely. Here’s the exact workflow, no fluff.

One quick note before the steps. I’m going to assume you’re on WHM — that’s where the domain whitelist lives on cPanel servers. If you’re running Imunify360 on a standalone Nginx or LiteSpeed box, the logic is identical, but the menu path can differ slightly between versions.

Why Is the CAPTCHA Showing Up in the First Place?

Imunify360 is a security suite for hosting servers. Think of its CAPTCHA check as a bouncer at a club entrance. When a visitor’s IP has a bad reputation, comes from an ASN that’s frequently abused by bots, or the site is under an active attack, Imunify360 serves a verification page before letting the visitor through. The intent is good — keep automated traffic out. The side effect is that real users get caught in the net too.

Here’s the scenario I keep seeing in tickets. A client’s site sits behind a shared IP pool. One server in that pool gets abused by a spam bot, the whole block gets flagged, and now every legitimate visitor behind that IP hits a CAPTCHA. The client can’t understand why traffic dropped overnight. It wasn’t a server failure and it wasn’t an SEO penalty — it was a security feature doing its job a little too well. This is exactly the situation that domain whitelisting solves.

The impact on a production site is measurable: conversion drops, support tickets pile up with “why is your site asking me for a CAPTCHA”, and any API or mobile app calling your domain starts throwing errors. For a service that depends on stable access, that’s not a minor annoyance — it’s a business problem.

So the rule of thumb is simple. CAPTCHA exists to filter automated traffic. If your domain’s traffic is genuinely human and trusted, you’re paying a cost you don’t need to pay. Whitelisting the domain disables the CAPTCHA check for that domain only, while every other protection layer — ModSecurity, the WAF, brute-force protection — stays fully active. Best of both worlds, assuming you pick the right domains.

Before You Whitelist — Ask These Two Questions

Number one: is this domain public and attack-prone? If yes, think hard before disabling the CAPTCHA. Number two: is your traffic actually tripping the check? If nobody is complaining, there’s nothing to fix. Whitelisting a domain that never had a problem is adding risk for zero benefit.

Practical examples of good whitelist candidates: internal portals, client panels, staging or dev domains, and API endpoints consumed by first-party applications. These are the ones that get hurt by CAPTCHA and never benefit from it. If you want the full picture on what Imunify360 does beyond CAPTCHA, our article on how Imunify360 works covers it in depth.

How to Whitelist a Domain in Imunify360 — Step by Step

Alright, here are the steps. Follow them in order, and you’ll be done in about five minutes.

Step 1 — Log Into WHM

Open https://your-server-ip:2087 and log in with a root or reseller account that has access to the Imunify360 plugin. Regular cPanel-level accounts won’t see this setting — it’s a server-level configuration.

Step 2 — Open the Imunify360 Plugin

In the WHM sidebar, scroll to the Plugins section, or type “Imunify360” in the search box in the top-right corner, then click the icon. You’ll land on the dashboard with tabs like Dashboard, Incidents, Attacks, Firewall, WebShield, and Settings. If the dashboard doesn’t load, check /var/log/imunify360/ for errors before going further.

Step 3 — Go to WebShield

Click the WebShield tab. This is where the WAF, ModSecurity, and CAPTCHA settings live. Heads-up: in some Imunify360 versions, the CAPTCHA settings moved under Settings —> WebShield. If you can’t find them, that’s the first place to look. Version differences are the number one reason people get lost in this process.

Step 4 — Find the CAPTCHA Section

Scroll down to the CAPTCHA block. You’ll typically see:

• Enable CAPTCHA for suspicious visitors (toggle)
• CAPTCHA type — image, reCAPTCHA, or invisible
• Domains to disable CAPTCHA check (text field)

The field you need is the last one.

Step 5 — Add the Domain to the Whitelist

In the “Domains to disable CAPTCHA check” field, type the domain name. The expected format is one domain per line, without http:// or https://. Example: example-store.com

Quick tip: some Imunify360 versions accept wildcards like *.example-store.com to cover subdomains in one shot. Support varies by version, so test carefully. When in doubt, whitelist the root domain first, verify, then add more.

Step 6 — Save and Verify

Hit Save. Imunify360 reloads its configuration automatically — no server restart needed in most cases. Then verify: open the site from a browser that used to trip the CAPTCHA. It should load straight through now.

For a more technical check, run curl from an IP that previously triggered the CAPTCHA:

curl -sI https://example-store.com | head -20

If the whitelist is working, you won’t see the characteristic CAPTCHA response — typically a 200 status with a verification HTML body, or a redirect to a challenge page. If it still shows up, move to the troubleshooting section below.

CLI Alternative — If You Prefer the Terminal

Imunify360 ships a command-line agent. Whitelisting an IP or ASN is straightforward:

imunify360-agent whitelist ip 203.0.113.10
imunify360-agent whitelist asn AS63949

The domain whitelist for CAPTCHA lives in the configuration file, typically /etc/sysconfig/imunify360/config.ini. After editing it, reload with:

imunify360-agent update-config

Warning: don’t edit config.ini unless you’re comfortable with it. A malformed line can break the entire Imunify360 configuration. If you’re not confident, use the GUI — that’s what it’s for. And if you do edit it, back it up first:

cp /etc/sysconfig/imunify360/config.ini /etc/sysconfig/imunify360/config.ini.bak

Troubleshooting — Whitelist Saved, CAPTCHA Still Showing

This is where most people get stuck. The domain is in the list, it’s saved, and the CAPTCHA still appears. Here’s a checklist of the usual culprits:

One more thing people forget: if the site sits behind a CDN like Cloudflare, Imunify360 sees Cloudflare’s IPs, not your visitors’ IPs. That’s exactly why domain-based whitelisting is the right tool here — it works no matter which IP shows up. An IP whitelist would be useless in that setup. For the reverse workflow — allowing only specific IPs — read our guide on whitelisting IPs in Imunify360.

What Happens Under the Hood

Understanding the mechanics helps you debug faster. When you save a domain in the whitelist field, Imunify360 stores it as part of the WebShield CAPTCHA configuration. On each incoming request, WebShield checks the domain against that list. Whitelisted? The request passes straight through, no challenge. Not whitelisted and the IP looks suspicious? The CAPTCHA page gets served.

Because the check is domain-based — it matches the HTTP Host header — it stays fast under high traffic and behaves predictably behind proxies and CDNs. No extra process in the request path, no per-request bottleneck. That’s the design, and it’s why a domain whitelist beats an IP whitelist for most real-world setups.

Is Whitelisting a Domain Safe?

Ask yourself one honest question before you do this: “Do I trust every visitor on this domain?” Whitelisting turns off the CAPTCHA check for that domain completely. On a high-value public site that gets attacked regularly, that’s a trade you should make very carefully.

For genuinely trusted domains — internal portals, client panels, first-party API endpoints — this is a sensible, low-risk change. Your users get a clean experience, and you stop getting “why is there a CAPTCHA here” tickets. If you also want to harden the WAF side, our guide on tuning ModSecurity in WHM is a good next read.

FAQ

To wrap this up: before you close the ticket, make sure you’ve done all of it — whitelist saved, verified with curl, and the security trade-off reviewed. If the CAPTCHA still shows for a legitimate visitor after that, walk the troubleshooting table from top to bottom. That’s the whole job. Done.