Case Study
Catching a DMARC break before the client did
Auto-rescan, change-aware alerts, and a PSA ticket that opened itself under the right client.
Illustrative scenario, not a specific verified customer — grounded in ActiScan's real capabilities and how MSPs typically use them. An MSP running scheduled monitoring across a client base connected to ConnectWise Manage.
Next scan cycle
Time to detect the break
None
Manual triage required
Correct client, automatically
Ticket opened under
The situation
A client migrates mail platforms, or a well-meaning IT contractor "cleans up" DNS records they didn't fully understand, and a DMARC record that was passing for months quietly disappears. Nobody on the client's side notices right away — mail still sends, it just stops being authenticated the way it was. By the time it shows up as a deliverability problem, inbox placement has already been dropping for days.
Catching that kind of silent regression has traditionally meant someone manually re-checking every client domain on a schedule, which doesn't scale past a handful of clients and always lags behind the actual change.
What changed
Every domain in this client's group has an auto-rescan interval set — daily, for domains the MSP considers higher-risk. On the next scheduled scan, the DMARC check comes back failing where it passed the scan before.
Because the check is compared against the domain's own last scan, not evaluated in isolation, this registers as a newly-failing check — not just "failing," which would be true of dozens of pre-existing warnings across the client base and wouldn't stand out. A newly-failing check shows up on the Alerts page, as a banner at the top of the Domains dashboard, and — since this MSP has Slack connected as an alert channel — as a message in the team's monitoring channel within the same scan cycle it happened.
This client's group also has ConnectWise connected, with its primary domain mapped to the matching ConnectWise company. The newly-failing check doesn't just alert — it opens a ticket automatically, under the correct client, with no one on the MSP's team manually creating or triaging it first.
The outcome
The MSP's team picks up the ticket, republishes the missing DMARC record (or, since a DNS provider is connected, does it in one click via "Publish for me"), and closes it out — all before the client's own deliverability metrics had dropped enough for anyone on their side to notice something was wrong.
What could have been an awkward "why didn't you catch this" conversation instead becomes a line in the next quarterly review: a real incident, caught and closed, with a timestamped ticket history to show for it.
Questions
What counts as "newly failing"?
A check that passed on the domain's previous scan and fails on this one. A check that was already failing last time doesn't re-alert every single scan — that would bury the one change that actually matters under routine noise.
Does this require a specific PSA?
No — ConnectWise Manage, Autotask, and HaloPSA are all supported, and more than one can be connected at once if different teams use different systems.
What if a domain isn't in any group, or its group has no PSA mapping yet?
It simply doesn't create a ticket — ActiScan never falls back to a default or generic client, since a ticket filed under the wrong company is worse than no ticket at all.
See it on your own domains
Run a free scan first, or start a trial to see the full workflow this case study describes.