DMARC

What to Do in the First 24 Hours After a Client's Domain Gets Spoofed

September 1, 2026

Rodney Hall, COO— AI-assisted and reviewed prior to publication.

The call usually comes in the same way: a client's accounts-payable contact says a vendor is asking why an invoice email "looks weird," or a customer forwards a message that claims to be from the client but clearly isn't. By the time anyone notices, the spoofed messages have often been landing in inboxes for hours or days. What happens in the next 24 hours determines whether this becomes a contained incident or a drawn-out reputation and financial mess.

What is the single most important action in hour one?

The first move is not blocking the sender, it's checking the client's DMARC record and reporting data to determine whether the spoofed mail is passing authentication at all. If DMARC is missing or set to p=none, the domain has no enforcement in place, and the priority shifts immediately to getting a policy live rather than chasing individual messages.

This distinction matters because domain spoofing and account takeover are not the same problem, and they demand different first steps. Spoofing means an attacker is forging the client's domain in the From header without ever touching their mail system, which is exactly the scenario RFC 7489 built DMARC to address by tying policy enforcement to SPF and DKIM alignment. Account takeover means the attacker has real credentials and is sending from inside the client's own mailbox, which no DNS record can stop on its own.

Confirm what actually happened before touching anything

Pull a sample of the suspicious messages and check the raw headers for SPF, DKIM, and DMARC results rather than trusting how the message looks in the inbox. A message that fails alignment but still landed in an inbox usually means the domain's DMARC policy is set to monitor-only or doesn't exist, which is common since many domains start at p=none to collect data before enforcing anything.

Cross-reference this against DMARC aggregate reports if they're already being collected, since those reports show the sending IPs, volumes, and pass/fail results for every source claiming to use the domain. The Federal Bureau of Investigation's Internet Crime Complaint Center has tracked business email compromise losses reported through IC3 across all 50 states and 186 countries, which is a reminder that this isn't a hypothetical risk being triaged, it's an active fraud category with real financial victims on the other end of a convincing-looking email.

If reports aren't already flowing, this is also the moment to confirm whether the client's domain has any DMARC record at all. A quick DNS lookup for the _dmarc TXT record answers this in seconds, and its absence explains a lot about how the spoofing succeeded in the first place.

Should the DMARC policy be changed immediately?

Not without checking alignment data first. Jumping straight to p=reject on a domain with unverified legitimate senders can silently block the client's own marketing platform, help desk tool, or invoicing system, turning a spoofing incident into a self-inflicted outage.

The safer sequence inside the first few hours is to move a p=none policy to p=quarantine with a low percentage tag if aggregate data is thin, then widen enforcement as confidence grows that legitimate senders are properly aligned. Google's own guidance for Workspace admins walks through this exact escalation path and notes that troubleshooting a DMARC issue starts with checking SPF and DKIM settings and making sure outgoing messages pass those checks in alignment with the domain. If the client is already at p=reject and mail is still getting through with a spoofed header, the report data becomes less about tuning and more about confirming the forged traffic is failing everywhere it should and handling it as an incident rather than a configuration problem.

For domains that already send meaningful volume to Gmail addresses, there's an added wrinkle worth flagging to the client: Google requires a valid DMARC record for bulk senders and expects the organizational domain to align with either SPF or DKIM, a requirement Google spells out directly in its sender guidelines FAQ. A spoofing incident is often the first time a client learns their domain was never fully compliant with that baseline.

Lock down SPF and DKIM records the same day

SPF and DKIM are the two authentication mechanisms DMARC depends on, and both are worth auditing the same day as the policy change. A bloated SPF record with unused include: mechanisms is a common gap attackers exploit, and any recent addition the client doesn't recognize should be treated as suspicious until confirmed.

DKIM keys deserve equal scrutiny, particularly if there's any chance a sending platform's credentials were exposed rather than the domain simply being forged. The Messaging, Malware and Mobile Anti-Abuse Working Group recommends that DKIM keys be rotated on a defined schedule, stating that keys should be rotated at least every six months as standard practice, and an active spoofing incident is a legitimate reason to rotate early rather than wait out the calendar. Removing an old or unused selector the same day closes a door that may otherwise stay open indefinitely.

Report the abuse while the trail is still fresh

Domain spoofing that involves a lookalike or cousin domain, rather than the client's real domain, needs a separate reporting track through the registrar and hosting provider. The Anti-Phishing Working Group publishes best-practice guidance for registrars on handling exactly this kind of abuse report, and getting the report filed within the first day materially improves takedown speed compared to waiting until later in the week.

If the incident involves wire transfer fraud tied to the spoofed messages, the client should also be pointed toward the FBI's IC3 reporting channel without delay. The Bureau's own guidance on business email compromise scams stresses that if a fraudulent transfer is discovered, time is of the essence, and contacting the receiving financial institution to request a recall is a step that only works within a narrow window. This is not something an MSP handles directly, but flagging the urgency to the client in those first hours can be the difference between recovering funds and writing them off.

Document everything for the retrospective

Every header sample, DNS snapshot, and timestamp collected during the first 24 hours becomes the basis for the post-incident report the client will eventually want. Screenshots of the DMARC record before and after changes, a list of every IP flagged in aggregate reports, and a note of exactly when each policy change went live all matter later, whether for the client's own records or for an insurance claim.

This documentation habit is also where a lot of MSPs find the gap between reacting to one incident and running an ongoing authentication program. A domain that had DMARC monitoring in place before the spoofing attempt would have surfaced the anomalous sending pattern in aggregate reports well before a client contact noticed something felt off. Building that baseline is part of what the getting-started guide walks through for onboarding a new client domain onto continuous scanning rather than only reacting after damage is already done.

Turning the incident into a standing process

A single well-handled spoofing incident tends to be the moment a client finally agrees to ongoing authentication monitoring instead of a one-time DNS cleanup. That shift matters because CISA's long-standing alert on business email compromise makes clear this is a persistent, evolving fraud pattern rather than a one-off event, noting that actors use compromised or spoofed accounts to redirect wire transfers as an established and recurring tactic. Treating the 24-hour response as the end of the work rather than the start of a monitoring relationship leaves the client exposed to the next attempt.

For MSPs managing this across dozens of client domains, the operational reality is that manual header checks and DNS lookups don't scale past the first incident or two. Automated scanning that tracks SPF, DKIM, and DMARC posture continuously, and flags policy drift or new unauthorized senders before a client's contact spots something suspicious, turns this reactive playbook into a standing control. Reviewing what that looks like at different client volumes is worth doing on the pricing page before the next incident forces the conversation, and setting up the first domain takes only a few minutes through the signup page once the retrospective from this incident is done.

The first 24 hours after a spoofing report will always involve some scrambling. The goal isn't to eliminate that scramble entirely, since forged mail is fundamentally a receiver-side decision no domain owner fully controls, but to make sure the scramble happens against a documented baseline instead of a blank DNS record and a client asking why nobody caught it sooner.

Further Reading

• www.duocircle.com
• www.hstoday.us