A compromised customer site doesn't just hurt that one account — once Yandex or a phishing feed flags a domain on your IP, the listing follows the shared address and starts dragging down deliverability and search visibility for neighbours. Reputation Management is the Imunify360 feature that tells you which domains on the server have been blacklisted, before the abuse desk emails you.
This is for admins already running Imunify360 on a shared box who want an early-warning signal on customer compromises. It covers exactly which engines Imunify checks, how to read the affected-domains table, where the notifications come from, and — importantly — what Reputation Management does not watch, so you don't mistake it for mail-RBL monitoring.
What Reputation Management actually checks
Once a day, the agent collects the list of domains hosted on the server, sends it to the central Imunify360 API over a cron job, and gets back any matches from four reputation sources:
- Yandex Safe Browsing — malware and dangerous-site flags
- PhishTank — community-verified phishing URLs
- OpenPhish — automated phishing-URL feed
- Phishing.Database (the
mitchellkrogzproject) — aggregated phishing domains
Note what's missing: there is no Google Safe Browsing (Google retired free programmatic access), and there are no email RBLs — no Spamhaus, no Barracuda, no SORBS. So Reputation Management is a web and phishing reputation tool, not a spam-blacklist monitor.
Read the affected-domains table
Open the Imunify360 admin UI and pick Reputation Management from the left menu. A badge next to that menu item — and a counter at the top of the page — shows how many domains are currently flagged. Zero is the state you want.
When something is listed, the table gives you one row per affected domain:
| Column | What it tells you |
|---|---|
| Username | The cPanel/Plesk account that owns the domain — your remediation target |
| URL | The exact path that was flagged, not just the bare domain |
| Threat type | Which engine and category triggered (e.g. phishing, malware) |
| Detected | Timestamp of the match, so you can correlate with logs |
The Actions column has a copy-to-clipboard icon for the flagged URL — handy when you're pasting it into a ticket or a malware scan.
The single most useful field is URL. A flag on /wp-content/uploads/.well-known/
almost always means an uploaded phishing kit, whereas a flag on the document root points at
a deeper compromise. Use the path to jump straight into the right place rather than scanning
the whole account.
Wire up notifications
Reputation Management is only an early-warning system if someone sees the warning. It rides
the standard Imunify360 notification pipeline rather than having its own toggle, so set a
real inbox under Settings → General → Notifications (or in
/etc/imunify360/imunify360.conf) and make sure the admin contact is a monitored address,
not a root mailbox nobody reads.
Confirm the agent and its scheduled jobs are actually running — a stalled agent silently stops checking:
imunify360-agent version
systemctl status imunify360
If you want to see the current configuration the agent is using, dump it with the same CLI you'd use for any other tuning (full command list in the agent CLI reference):
imunify360-agent config show
When a domain shows up: remediation
A listing is a detective signal — by the time it appears, the site is already compromised and already being penalised. Work the row top to bottom:
- Find the payload. Take the flagged URL and run a targeted malware scan on that account. Don't trust a clean top-level scan; phishing kits hide in upload directories and cache folders. The full clean-up sequence is in the malware cleanup and remediation workflow.
- Remove and harden. Delete the kit, patch the entry point (usually an out-of-date plugin or a stolen FTP credential), rotate the account's passwords, and force a fresh set of keys.
- Request delisting. Removal from a feed isn't automatic — submit the cleaned URL to the relevant source (PhishTank and OpenPhish both take removal/dispute requests). For a Google "this site may harm" interstitial, point the customer at Google Search Console's security-issues report and its hacked-site recovery guide.
- Re-scan next cycle. The table clears on the next daily run once the upstream feed drops the entry, so don't expect the counter to reset the minute you delete the file.
False positives
Phishing feeds are noisier than malware engines — a legitimate login page that mimics a bank's branding, or a security researcher's sandbox, can get listed. If you've manually confirmed a flagged URL is clean, treat it like any other Imunify miscategorisation and submit it as a false positive rather than ignoring the row, so the signal stays meaningful.