Running 20+ GoHighLevel sub-accounts? Monitor deliverability without 20 logins

Most GoHighLevel agencies grow past the point where the per-sub-account UX scales. At five sub-accounts, you can hop between accounts in the location switcher and eyeball the email stats. At twenty, you are looking at four hours a week just to do the round-trip across accounts and read the same four metrics in twenty places. By thirty, deliverability problems are silently compounding because you cannot see them all at once.

This post is the operational pattern we see working for agencies in the 20–60 sub-account range. It covers what to monitor, how often, where the data lives, and which steps actually need automation versus which are fine as a weekly walkthrough.

What you are actually watching for

Reduce monitoring to four signals per sub-account and you will catch 95% of deliverability problems before they hit the client.

Bounce rate over the last 30 days. Threshold: under 2% green, 2–5% amber, over 5% red. This is the cheapest leading indicator of list quality and authentication drift. Bounces precede placement degradation by roughly 7–14 days at typical agency volume.

Authentication health. SPF, DKIM, DMARC must all resolve, parse, and align on the sending domain. If any of the three drift — usually because a registrar UI or a third-party tool overwrites the record — the sub-account starts soft-failing DMARC, which mailbox providers translate into placement penalties before bounces start showing up.

Blocklist status. Specifically Spamhaus ZEN (which aggregates SBL, CSS, XBL, PBL), Barracuda BRBL, and SpamCop SCBL. Each of these is checked by mailbox provider scoring algorithms in different ways. A listing on ZEN or Barracuda will lose you 10–40% inbox placement within hours; a listing on SCBL is roughly 15-minute resolution time but is still worth knowing.

Daily-limit utilisation. GoHighLevel sub-accounts have per-day send limits. Approaching the cap and getting throttled creates queue backlogs that show up as soft bounces in reporting. If a sub-account is consistently above 80% of cap, you need to negotiate a higher limit before the queue builds up, not after.

You can extend this list — feedback-loop complaint rate, list growth rate, suppression-list size — but the four above are the floor. The goal is a single dashboard view where each row is a sub-account and each column is one of the four signals, colour-coded.

How often to check

The honest answer is "more often than you think and less often than you fear."

Daily, automated: authentication checks, blocklist checks, bounce-rate snapshot. These should run on a cron and ping you only on threshold violations. There is no benefit to a human reading a green dashboard every day.
Weekly, human: walk through the dashboard once per week. Read the trend lines, not just the colour codes. A sub-account that is green-amber-amber-amber-green-green is healthier than one that is green-green-green-green-green-amber, even though both end at green. The eye catches that, automation often does not.
Per-incident, on demand: when a client reports "my emails aren't getting through" — and they will — you need to be able to drill into one sub-account in under two minutes. The dashboard view should support a one-click drill-down to the per-sub-account detail.

If your monitoring system requires a human to read it daily, it will be neglected by week three. Build for a weekly cadence with daily automation underneath.

The per-sub-account detail you actually need

When something goes amber or red, you need this information in one place to triage:

Last 30 days of bounce rate, broken into hard and soft if available
Live values of SPF, DKIM, DMARC for the sending domain, with the parsed result (alignment status, lookup count, key length, policy)
Blocklist status across the major lists with the delisting URL if listed
Last 5 campaigns with date, recipients, bounce count, complaint count
Daily limit and last 7 days of send volume against the limit
The Google Postmaster Tools tier for the domain, if the domain is enrolled
A button to run a one-click verification of a paste-or-upload list against the sub-account's suppression list

If you have to log into GoHighLevel, then DNS tools, then Postmaster Tools, then the verifier, then the suppression export — you have already spent 30 minutes on triage and the client is impatient. The whole point of an agency-tier tool is to make this one screen.

What to automate vs do by hand

A useful heuristic: automate the detection, do the resolution by hand for the first 50 incidents. The reason is that resolution requires judgement — a Spamhaus listing on a specific sub-account might be your problem (poor list hygiene), the client's problem (a former employee scraped a list), or someone else's problem (a shared IP listing that has nothing to do with you). Each of those needs a different conversation. Once you have run that conversation 50 times, you will see the patterns and the automation becomes obvious.

Things that should be fully automated:

Daily DNS resolution of SPF, DKIM, DMARC for every sending domain
Daily blocklist queries against the major lists for every sending domain and IP
Bounce-rate computation per 30-day window per sub-account
Threshold-based alerting (email + Slack + sometimes SMS for red events)
Domain reputation snapshots from any source you can integrate (Postmaster, Talos, etc.)

Things that should stay human-in-the-loop until you have process maturity:

Delisting requests. A bot can submit them, but a human should read the listing reason first.
Client communication. Auto-emailing a client "your domain is on Spamhaus" without context creates panic and does not help.
Authentication record changes. Even small DNS edits can break sending; a human gate prevents the kind of incident where a malformed SPF record knocks out an entire sub-account for 12 hours.
Suppression list pruning. Aggressive automated pruning has caused more problems than it has solved.

How MailerMonk fits this pattern

The MailerMonk agency dashboard is built around exactly this monitoring shape:

A grid view at /agency/dashboard with one row per sub-account and the four signals above colour-coded.
Per-sub-account drill-down with the SPF / DKIM / DMARC parsed values, blocklist status, and 30-day bounce trend.
A /agency/reputation scorecard that runs the full DNS + blocklist check against any sending domain in one place — useful when you want to spot-check before a campaign goes out, not just on the daily cron.
A /agency/verifier paste-or-upload list verifier per sub-account so you can check imports without leaving the agency view.

Authentication checks run continuously in the background; blocklist checks happen daily by default and on-demand when you drill into a sub-account. The bouncer integration sits behind the verifier so you get the same five-bucket breakdown described in the CSV scrubbing post.

If you want to see what monitoring 20+ sub-accounts looks like with this shape, the GoHighLevel agency landing walks through the connection flow and the sub-account sync.

A brief note on what we are not solving

Monitoring is a leading-indicator layer. It does not fix bad lists, it does not fix unauthenticated mail, and it does not negotiate with mailbox providers when you have already burned reputation. What it does is give you 14 days of warning before a problem becomes visible to the client, which is enough time to do the actual fixing.

If you read your dashboard once a week and the same sub-account is amber for three weeks running, monitoring has done its job. The next step is the underlying remediation work — list scrubbing, authentication tightening, suppression hygiene. Treat the monitoring layer as the smoke alarm, not the fire department.

What to do today

Pick the four metrics above and write them down.
Stand them up for your top three sub-accounts (highest revenue or highest volume).
Run the dashboard for a week and watch how the colour codes move.
If you find one issue you would not otherwise have caught, the system has paid for itself.

The agencies that compound at this layer treat deliverability monitoring not as an add-on service but as part of the table-stakes offering — and they upsell into the underlying remediation work that the monitoring surfaces.