The hardest deliverability conversation an agency has is "your domain just got listed on Spamhaus." The right response in the first 30 minutes is the difference between a small client conversation and a churn event. This post is the runbook we hand new agency owners; it assumes you have already gotten the alert, the listing is real, and the client is about to find out.
The runbook is sequential. Steps marked (parallel) can run while later steps are also running.
Minute 0–2 — Verify the alert is real
Spamhaus has three list components most relevant to email senders: SBL (manual listings of known spam sources), CSS (automated listings for snowshoe and high-complaint senders), and PBL (policy listings of dynamic IP ranges that should not send mail directly). The aggregated lookup list is ZEN.
Before you do anything else, confirm the listing is real and identify which list. False positives at this layer are rare but they do happen, especially when a third-party check uses a stale local cache.
Use the free blocklist checker and check both the sending IP and the sending domain against ZEN, Barracuda BRBL, SpamCop SCBL, SORBS, and at least two others. Note which lists show a hit and what the listing reason is — Spamhaus surfaces the reason as part of the lookup.
If only one source disagrees with the rest, treat the lone source as suspect. If two or more agree, treat the listing as real and continue.
Minute 2–5 — Stop the bleed
Open the affected sub-account in GoHighLevel. Pause every active campaign and every active workflow that triggers email. Specifically:
- Pause scheduled campaigns
- Disable email triggers in active workflows
- Suspend re-engagement automations
- Stop any drip sequences mid-flight
You are not pausing forever. You are stopping the volume so you do not compound the listing while you are working out the cause. Sending into a Spamhaus listing increases the signals that put you there.
If the agency runs the same domain across multiple sub-accounts, pause sending in all of them. A listing on a domain affects all senders using that domain.
(parallel) Snapshot the state. While you are pausing, capture a screenshot of the GoHighLevel email stats for the last 30 days, the current daily-limit utilisation, and the bounce rate. You will need these for the post-incident review.
Minute 5–12 — Identify the cause
This is the diagnostic phase. There are five common causes of a Spamhaus listing for an agency sub-account, in rough order of frequency:
Cause 1: Spam trap hit. Someone sent to a known spam trap address. Traps are real-looking addresses that exist solely to catch senders using bad lists. Spamhaus operates a network of them and a single hit on a "fresh" trap (one that has been live for under 30 days) is enough to trigger CSS. Multiple hits over a short window will trigger SBL.
Cause 2: High complaint volume. Recipients clicked "Mark as spam" at a rate above ~0.3% of opens over a recent campaign. This is a complaint-driven listing, usually CSS, and resolves in 24–48 hours if you stop sending and the complaints stop.
Cause 3: Compromised account. A workflow, integration, or login was compromised and started sending unsolicited mail from the sub-account. Look for unusual send volume in the last 24 hours, login events from unfamiliar IPs, or workflow changes you did not make.
Cause 4: Inherited reputation problem on a shared IP. GoHighLevel's LC – Email is shared infrastructure; a listing of the underlying sending IP is technically a GHL platform issue, not your domain. Check whether the listing is against the IP or the domain. If it is the IP and you are on shared infrastructure, you have less control and the path is different (covered below).
Cause 5: Bad list import. A recent CSV import contained a high concentration of stale, scraped, or appended addresses, including some traps. The bounce rate from that import will be visibly elevated.
Triage by checking, in order:
- The blocklist record — is it the IP or the domain?
- The 24-hour campaign log — any unusual sends?
- The recent imports — anything from a non-standard source?
- The complaint rate from the most recent send.
By minute 12 you should know which cause you are dealing with.
Minute 12–20 — Stabilise
Now do the cause-specific stabilisation.
If Cause 1 (spam trap): identify the import or list source that introduced the trap. Add every address from that source to the suppression list for the sub-account, regardless of bounce status. Do not send to that source list again until it has been re-verified through a paste-or-upload check, and even then with a small graduated send.
If Cause 2 (complaints): identify the campaign that drove complaints. Pull the audience list and check whether the recipients had recent engagement (opens, clicks). If most of the audience had not engaged in 60+ days, the campaign was a re-engagement send to a stale segment — that is a list-hygiene problem, not a copy problem. Tighten the engagement window and do not bulk-send to the unengaged segment until reputation recovers.
If Cause 3 (compromise): rotate every credential touching the sub-account (GoHighLevel password, integration API keys, marketplace OAuth tokens). Audit the workflows for unauthorised changes. Audit the login history. Notify the client immediately with what was seen and what was done.
If Cause 4 (shared IP): open a support ticket with GoHighLevel referencing the specific listing and asking for the platform's response. While that is in flight, look at whether you can route this domain's mail through a dedicated IP option if the platform offers one — agencies above a volume threshold often get this option.
If Cause 5 (bad import): suppress every address from the offending import, document the source for the client, and walk through the CSV scrubbing workflow on the next import.
Minute 20–25 — Submit the delisting request
Spamhaus has a self-service delisting form on their site. The form asks for the listed IP or domain, a description of what changed, and confirmation that the sending will not resume in the same shape. The form is processed by a real reviewer; padded or evasive submissions are rejected.
Two things make a delisting request likely to succeed:
- Honesty about cause. Do not say "we don't know what happened" if the cause is "we sent to a list with traps in it." The reviewer can usually see the latter and a denial of cause delays the resolution.
- Concrete remediation. "We have suppressed the offending list source, added pre-import verification, and the affected campaign is paused" is the right shape. "We will be more careful" is not.
For Cause 1 (trap) and Cause 2 (complaints), expected resolution is 24–48 hours from a clean submission. For Cause 3 (compromise), expect 48–72 hours and additional verification. For Cause 4 (shared IP), the platform owner submits the request, not you.
If the listing is on Barracuda BRBL or SpamCop SCBL in addition to Spamhaus, submit delisting requests to each. Each list has its own form and its own review pipeline; they do not propagate.
Minute 25–30 — Tell the client
This is the hardest 5 minutes. The right shape:
- What happened — in plain language, not jargon
- What we have done — concrete, in past tense
- What we expect — timeline for resolution
- What we will do differently — the prevention work, scoped
A reasonable opening:
Earlier this morning your sending domain was listed on Spamhaus. We have paused all outgoing email from your account, identified the cause as [a recent import / a complaint spike / etc.], and submitted a delisting request. We expect the listing to clear within 24–48 hours; we will not resume sending until it has cleared and we have verified the underlying cause is fixed. The prevention work is [add pre-import verification / tighten the re-engagement segment / rotate credentials].
Send this in writing, even if you also call. Clients want a paper trail and an honest write-up. The agencies that lose clients to deliverability incidents are the ones that go silent for 24 hours hoping the listing self-resolves.
After the incident — the prevention work
Once the listing has cleared and sending has resumed under graduated volume, schedule the prevention work for the same week:
- Add pre-import verification to the agency's intake checklist if it was not already there. The verifier flow covers this.
- Set up daily blocklist monitoring on every sub-account so the next listing alerts you in under an hour, not from the client. The agency reputation scorecard handles this.
- Tighten the engagement window for re-engagement campaigns to 60 days; this catches most of the stale-list problems that drive complaints.
- Audit DKIM, SPF, DMARC across every sub-account. Authentication misconfiguration does not cause Spamhaus listings directly, but it amplifies the impact when complaints spike.
What you do not do
A few things that look helpful but are not:
- Do not change the sending domain to dodge the listing. Spamhaus tracks senders, not just identifiers. Switching to a fresh subdomain to keep sending will get the new subdomain listed within hours and burns trust with the platform.
- Do not re-submit the delisting request every 12 hours. Submitting once and waiting is faster than submitting four times in a panic.
- Do not blame the client. Even if the cause was their export, your job as the agency is to handle the situation. Save the conversation about list-source hygiene for the post-incident review, not the day-of email.
- Do not bulk-resume sending the moment the listing clears. Ramp from 10% of normal volume to 100% over 5–7 days. Mailbox providers watch listings and a clean delisting followed by a volume spike looks like evasion.
What MailerMonk does at this layer
The agency reputation scorecard checks any sending domain against Spamhaus ZEN, Barracuda BRBL, SpamCop SCBL, SORBS, and three others, alongside the SPF / DKIM / DMARC / MX status, in one request. For 20+ sub-account agencies, the dashboard runs these checks daily across every sending domain you manage and alerts on changes. Pre-import verification is at /agency/verifier. The agency landing at /integrations/ghl/connect walks through the connection.
The runbook above does not require any specific tool — most of it is process. But process without observability is just hope; the monitoring layer is the part that gives you the 30-minute window in the first place.