Scaling from 20 domains to 200 without adding headcount

A growing client base is a good problem until the routine work stops scaling with it. A missing DMARC rua= address, an absent TLS-RPT record, MTA-STS never turned on past testing mode — none of these individually take long to fix, but multiplied across 200 domains and a rotating cast of clients' own DNS changes, that routine hygiene starts eating a real chunk of a technician's week, every week.

The team didn't want to automate everything — publishing an SPF change or escalating a DMARC policy to reject without review felt like the wrong thing to hand to a machine. They wanted the boring, safe stuff off their plate, not a black box making judgment calls.

Auto-fix draws that exact line. Turned on per domain, per check, from Settings, it only ever publishes fixes that are purely additive — a missing DMARC rua= reporting address, a missing TLS-RPT record, MTA-STS in testing mode — the kind of change that can never affect what mail is authorized to send as the domain. Anything that changes what's actually authorized (an SPF mechanism, a DMARC policy escalation, MTA-STS enforce mode) stays exactly where it was: a manual, one-click "Publish for me" a person still has to decide to click.

Before Auto-fix will touch a domain, ownership verification has to pass first — a TXT record confirming the tenant actually controls it, checked automatically or on demand. It's a deliberate gate: nothing gets auto-published to a domain ActiScan hasn't confirmed belongs to this tenant, even one that's connected to a DNS provider account with broader access.

As the client base grew from 20 domains to 200, the fleet-health rollup at the top of the dashboard kept the whole picture visible in one place — open issues across every domain currently in view, ranked by how many domains each one affects, so a systemic problem (say, a mail-platform migration that broke SPF for a batch of clients at once) stands out immediately instead of getting lost in 200 individual rows.

The routine, additive fixes just happen — the moment a scan finds one missing, it's published and verified by a fresh DNS lookup, not just trusted from the publish call's own response. Every attempt, applied or not, lands in the Auto-fix history log with the before and after value, so there's a real audit trail behind "why does this domain's DNS look different than last month" without anyone having to remember what they changed by hand.

The technician time that used to go to routine hygiene goes to the fixes that actually need a human decision — and the client base kept growing without the monitoring workload growing at the same rate.