DMARC

When a Client's Domain Gets Spoofed: An MSP's First 48 Hours

September 9, 2026

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

When a client calls to say someone is sending fake invoices from their domain, the clock starts on a response that will shape whether the incident becomes a contained embarrassment or a client-losing crisis. The first 48 hours determine whether spoofed mail keeps landing in partner inboxes, whether the client's own deliverability collapses, and whether the MSP looks like the professional who fixed it or the vendor who let it happen.

The right first move is never a DNS change. It is evidence collection: pull the message headers, confirm the exact domain or subdomain impersonated, and check the client's current SPF, DKIM, and DMARC records before anything else. That baseline determines whether the fix is a policy tweak, an authentication rebuild, or a credential-compromise response, and getting it wrong wastes the hours that matter most.

What Should an MSP Do in the First Hour After a Spoofing Report?

The first hour belongs to classification and containment, not remediation. Freeze any planned DNS or mail-routing changes so the investigation is not muddied by unrelated edits, then pull the raw headers from at least one reported message to confirm the sending source.

Spoofing reports rarely arrive with clean evidence. A client forwards a screenshot, a partner calls asking why they got a fake wire-transfer request, or a spam trap flags the domain. The MSP's job is to convert that noise into a specific question: is this exact-domain spoofing, a look-alike domain, or a compromised mailbox sending real authenticated mail. Those are three different problems with three different fixes, and confusing them burns time the client does not have.

Business email compromise remains one of the most financially damaging categories the FBI's Internet Crime Complaint Center tracks. Its recurring public service announcement on the subject has been updated annually since 2013 and continues to log new complaint data and loss figures each year, which is a reminder of how long this exact attack pattern has been profitable for criminals.

Reading the DMARC Reports Before Making Any Changes

DMARC aggregate reports are the most useful artifact in the first few hours because they show every source claiming to send as the domain, not just the one message the client happened to see. RFC 7489 built this reporting function specifically so receivers can give domain owners feedback about how their domains are being used and where authentication is failing.

Before changing a single DNS record, an MSP should pull the last several days of aggregate reports and separate legitimate senders such as payroll platforms, CRM tools, and marketing systems from anything unrecognized. This is also the moment to check whether the client's policy has ever reached enforcement. Most domains never get that far. Research from Red Sift's global DMARC tracking, which examined more than 73 million domains, found that only a small fraction had reached a policy of quarantine or reject even as basic record publication climbed, which means visibility exists on paper long before real blocking does.

That gap matters because a domain sitting at p=none provides visibility but no blocking. If the incident is a spoofed-domain phishing run and the policy has never moved past monitoring, the aggregate reports will show the attack in progress while receivers keep delivering it anyway. This is usually the moment an MSP has to explain that DMARC without enforcement is a smoke detector without a sprinkler system.

Fixing SPF and DKIM Without Breaking Legitimate Mail

Remediation centers on tightening SPF and DKIM so only verified infrastructure can pass authentication for the domain. In practice this means auditing every include: mechanism in the SPF record against the sender list surfaced by the DMARC reports, removing stale entries from decommissioned platforms, and rotating any DKIM selector that could have been exposed.

SPF evaluation under RFC 7208 is capped at ten DNS lookups, and a domain that has accumulated third-party services over years frequently exceeds that limit without anyone noticing until an incident forces a full audit. A record that silently fails validation because of a lookup overflow offers no real protection even though it looks complete in the zone file. Cleaning this up under incident pressure is delicate, since cutting an include: too aggressively can break a legitimate vendor's mail mid-crisis, so each removal should be checked against actual sending activity in the aggregate data rather than assumption.

DKIM rotation matters most when a compromised mailbox, not pure spoofing, is behind the incident, since a stolen credential can be used to sign outbound mail that will pass every check. Where the client uses a shared or long-lived private key, rotating the selector cuts off that path immediately. None of this replaces a password reset and MFA enforcement on the affected account, which should happen in parallel, not after.

How Fast Should the Domain Move to DMARC Enforcement?

Enforcement should follow evidence, not a fixed timeline. Once the aggregate reports confirm every legitimate source is passing SPF or DKIM in alignment, the policy can move from p=none toward p=quarantine and then p=reject, but moving before that confirmation risks silently dropping real client mail during the exact week trust is already shaky.

A rushed jump to reject can feel like the responsible move during a crisis, but if a legitimate sender is still misconfigured, the client's own invoices or payroll notices start disappearing instead of just the attacker's. The safer sequence raises the enforcement percentage gradually, watches the reports for a clean run, then commits to full rejection once the picture is stable.

The pressure to move fast is real, though. Google and Yahoo's bulk sender rules, which took effect for high-volume senders in February 2024, made DMARC presence a deliverability requirement rather than an optional control, and Yahoo has stated directly that spoofed emails will count toward the mail it evaluates for enforcement against a sending domain.

Notifying Partners and Regulators Without Overreacting

Once containment is underway, the MSP needs to help the client decide who gets told and when. Partners who received spoofed invoices or fraudulent payment requests should get a direct, specific warning describing what the fake message looked like, since a vague caution to be careful with incoming mail tends to get ignored.

Whether the incident triggers a formal regulatory notification depends on what data, if any, was exposed, and that determination belongs to the client's legal counsel, not the MSP. What the MSP can responsibly own is the technical narrative: what was spoofed, what failed, what was fixed, and what evidence exists. Joint guidance from CISA, the NSA, FBI, and MS-ISAC recommends DMARC enforcement as a baseline control and notes that DMARC reports provide a mechanism for notifying the owner of a spoofed domain, including where the abuse originated.

Why This Keeps Happening to Under-Protected Domains

Most domains that get spoofed successfully were never at enforcement in the first place. EasyDMARC's 2025 adoption research, which analyzed roughly 1.8 million domains across Fortune 500 and Inc. 5000 companies, found DMARC adoption grew substantially between 2023 and 2025 while enforcement policies grew at a slower pace, leaving a large share of published records still permissive by default.

The financial stakes behind that gap are well documented. The FBI's Internet Crime Complaint Center has tracked business email compromise losses for more than a decade, and its most recent public advisory frames it as a scam that has cost victims tens of billions of dollars since 2013. For MSPs, that history is the strongest argument for moving every client domain toward enforcement before an incident forces the issue rather than after.

Building the Habit Before the Call Comes In

The clients who weather a spoofing incident with the least damage are almost always the ones whose domains were already at p=quarantine or p=reject when the attack started, because the receiving mail servers did the blocking automatically instead of relying on a scramble after the fact. That reality should shape how MSPs price and package domain security, not just how they respond to it.

Building this into a standard offering rather than an emergency add-on is largely a workflow problem: continuous monitoring of DMARC aggregate data, alerting on new or unrecognized senders, and a documented path from none to reject for every client domain. Tools built for that pattern let a technician move through the audit steps above across dozens of client domains instead of one at a time, which is the difference between a 48-hour scramble and a same-day fix. An MSP evaluating that kind of tooling can walk through setup in the getting-started guide, compare service tiers on the pricing page, and get a client domain under monitoring today by creating an account through signup.

The 48 hours after a spoofing report will never feel comfortable, but they do not have to feel improvised. A domain with clean SPF, rotated DKIM, and an enforced DMARC policy going into the incident turns a potential multi-day crisis into a documented, contained event, which is precisely the outcome every client is paying an MSP to deliver.