MSP Operations
The First 24 Hours: Running Incident Response When a Client Domain Gets Spoofed
September 17, 2026
Rodney Hall, COO— AI-assisted and reviewed prior to publication.
The phone call always sounds the same. A client's finance director got a "wire instructions changed" email that looked exactly like it came from their CEO. Or a customer forwarded a phishing message with the client's logo, their domain in the From header, and a link to a fake invoice portal. Either way, the MSP is now the first call, and the clock on containment started the moment that message hit an inbox.
Domain spoofing incidents are not rare edge cases anymore. The FBI's Internet Crime Complaint Center logged 859,532 complaints in 2024 with reported losses exceeding $16 billion, a 33 percent jump from the year before, and phishing and spoofing remained the single most reported crime category in that dataset, according to the FBI's own summary of the 2024 Internet Crime Report. For an MSP managing dozens of client domains, the question is not whether one of them gets spoofed. It is whether the team has a repeatable process ready when it happens.
The right first move when a client's domain is being spoofed is not to change DNS. It is triage: confirm whether the client's own mail infrastructure was compromised, preserve message evidence, and pull DMARC aggregate data to separate real senders from impersonators before touching any policy record.
What Happens in the First Hour?
The first hour is about proof, not policy. Before anyone edits a TXT record, the technician on point needs a real sample of the spoofed message, including full headers, and needs to know whether the client's own SPF, DKIM, and DMARC records currently exist and what they say. Pulling the current DMARC record and checking recent aggregate reports takes minutes and tells the team whether the domain already has any enforcement in place or is sitting wide open at p=none.
This matters because DMARC only ever evaluates mail that claims to be from the client's domain in the visible From header. Per RFC 7489, the DMARC policy tag applies specifically to messages that fail both SPF and DKIM alignment, and a domain owner can request one of three receiver actions: take no specific action, treat the mail as suspicious, or reject it outright, with rejection happening during the SMTP transaction itself rather than after delivery, as the RFC's own language on policy actions makes explicit. If the domain has no DMARC record at all, there is no lever to pull yet, and step one becomes publishing a monitoring record, not an enforcement one.
Is This Spoofing or a Compromise?
These are two different incidents that require two different responses. Spoofing means an attacker is faking the client's domain in the From header without ever touching the client's actual mail servers or accounts. Compromise means an attacker has valid credentials, an API key, or a foothold inside the client's own sending infrastructure, and the mail genuinely originates from systems the client controls.
The distinction changes everything downstream. A DMARC policy change can suppress spoofed mail that fails alignment, but it does nothing for messages sent through a compromised mailbox or a hijacked marketing platform, because that mail will pass SPF and DKIM since it really did come from an authorized source. Checking sign-in logs, forwarding rules, and OAuth grants on the suspected sending account belongs in this first hour alongside the DNS check, not after it.
Reading the DMARC Reports Before Moving to Enforcement
Aggregate reports are the fastest way to find out who is actually sending mail on the domain's behalf, legitimate or not. Every domain with an active rua tag receives daily XML summaries from major receivers showing which sending IPs passed or failed SPF and DKIM alignment, and during an active spoofing event those reports become a rough map of the attack's scale and origin.
The instinct to jump straight to p=reject the moment spoofing is confirmed is understandable but risky if the client's legitimate senders have not been fully inventoried. Marketing platforms, invoicing tools, and helpdesk software that send mail "from" the client's domain will break instantly under a reject policy if they are not properly aligned, turning a security incident into a self-inflicted outage. Google's own guidance on message handling confirms that when a message fails DMARC, the enforcement action taken depends entirely on the policy the sending domain has published, which means a hasty move to reject with an incomplete sender inventory produces exactly the same kind of failure for good mail that the client is trying to stop for bad mail, per Google's email sender guidelines FAQ.
The table below reflects the general shape of a first-day response for an MSP with an established scanning workflow already in place.
| Window | Primary focus |
|---|---|
| Hour 0-1 | Preserve evidence, confirm compromise vs. spoofing, pull current DMARC/SPF/DKIM state |
| Hour 1-4 | Inventory legitimate senders from aggregate reports, notify affected client contacts, alert their email provider |
| Hour 4-24 | Move policy incrementally if senders are confirmed clean, document the incident, brief the client on next steps |
How Fast Should Policy Move to Enforcement?
Fast enough to stop new damage, slow enough not to break legitimate mail the client depends on. If the domain is already at p=quarantine or p=reject, the technical control is already doing its job and the incident work shifts to monitoring impact and confirming the attacker doesn't have an alignment bypass through a forgotten SPF include. If the domain is at p=none, the realistic move during an active incident is often a partial policy with a pct tag or a quick jump to quarantine rather than an untested leap to full reject, since a wrong move here can silently drop the client's own invoices and password resets.
CISA's own directive to federal agencies is worth citing precisely because it does not pretend this is instant: agencies were given a full year to move from an initial p=none record to p=reject, specifically because rushing that transition without validating every legitimate sender causes real mail to bounce, and CISA's BOD 18-01 page describes reject as a policy whose entire purpose is to cause delivery failure for mismatched mail, which is exactly why it demands a clean sender list first. An MSP running incident response under pressure from a panicked client should borrow that same discipline rather than skip it.
The IETF's newer DMARCbis document set, RFC 9989, RFC 9990, and RFC 9991, formalizes DMARC as a Standards Track protocol and reorganizes the aggregate and failure reporting mechanics that this whole triage process depends on, and the failure-reporting RFC explicitly carries forward the same policy-evaluation logic that made the original RFC 7489 useful for exactly this kind of forensic work, according to the RFC 9991 specification text. The mechanics an MSP relies on during an incident have not changed, only the standards document numbering behind them.
Notifying the Client and Documenting the Incident
Evidence collected in the first hour needs to go somewhere useful, both for the current incident and for any insurance, legal, or regulatory follow-up. A short, consistent list works better under time pressure than an ad hoc one:
- Full headers and raw source of at least one representative spoofed message
- Screenshots of the phishing content, landing page, or fraudulent invoice as received
- Timestamps of first detection, client notification, and any policy changes made
- Aggregate DMARC report data covering the days immediately before and during the incident
- Names of any third-party platforms confirmed as legitimate senders during the audit
Clients remember how an MSP communicates during a crisis longer than they remember the technical fix itself. A same-day written summary that explains what happened, what was changed, and what happens next builds the kind of trust that turns a stressful incident into a retention conversation instead of a churn risk. For MSPs building this into a standing service line rather than a one-off favor, laying out DMARC deployment as a phased engagement, starting with a monitoring baseline before any client agrees to enforcement, is covered in ActiScan's own getting-started guide for exactly this reason.
Hardening the Domain After the Fire Is Out
Once the immediate incident is contained, the real work is making sure the same domain doesn't show up on next month's call. That means finishing the move to enforcement across every domain the client owns, including parked and defensive domains attackers commonly target because nobody expects mail from them.
A short hardening checklist for the days after the incident:
- Confirm every legitimate sending platform has been added to SPF and has DKIM signing enabled before raising DMARC enforcement further
- Set up continuous monitoring on aggregate and, where supported, failure reports rather than checking manually after the next incident
- Extend the same DMARC posture to parked subdomains and dormant brand domains, not just the primary sending domain
- Schedule a recheck at 30 and 90 days to confirm the policy is holding and no new unauthorized senders have appeared
For an MSP managing this across a growing client book, doing this manually per domain does not scale past a handful of accounts. Portfolio-wide scanning that flags missing or weak DMARC, SPF, and DKIM records before an attacker finds the gap is the difference between reactive firefighting and a service line clients actually pay for, and the plans built for exactly that workload are laid out on ActiScan's pricing page. Teams that want to see how the scanning and alerting looks in practice can start directly from the signup page and run a first pass across an existing client list the same day.
The uncomfortable truth for the MSP industry is that domain spoofing incidents are not going away as email providers tighten enforcement. That tightening is exactly why the first 24 hours matter so much: a disciplined, evidence-first response protects the client's mail flow and the MSP's own reputation for handling the moment when the phone rings unexpectedly.