MSP Operations

Why MSPs Who Win DMARC Enforcement Still Lose Clients to Inbound Email Fraud

October 19, 2026

Ric Hall, CRO— AI-assisted and reviewed prior to publication.

An MSP spends three months moving a client from p=none to p=reject. The DMARC aggregate reports are clean. SPF and DKIM align on every sending source. The project closes, the invoice goes out, and everyone moves on. Four months later the client's controller wires $94,000 to a "vendor" whose invoice arrived from a domain that looked almost right. The MSP did exactly what it promised. The client got hit anyway. Nobody technically failed, and that is the problem.

This happens because DMARC enforcement and inbound fraud protection solve two different problems, and most MSP service catalogs only cover one of them. Enforcing DMARC stops criminals from forging the client's own domain to attack other people. It does nothing to screen what lands in the client's own inbox from lookalike domains, compromised vendor accounts, or freemail addresses impersonating an executive. That second category is where almost all the money actually disappears.

What Does DMARC Enforcement Actually Protect?

DMARC enforcement protects the client's outbound reputation, not their inbox. The protocol, defined in RFC 7489, gives a domain owner a way to tell other mail servers what to do with messages that claim to come from that domain but fail SPF or DKIM checks. It is a policy statement about outgoing identity, built so that receivers elsewhere on the internet can reject forged mail carrying the client's name.

Google's own Workspace documentation draws this line explicitly, describing authentication setup as something that protects an organization's outgoing email and stops spammers from impersonating that organization to others, which is a distinct function from the inbound filtering that Workspace handles separately through its spoofing and authentication safety settings. A client's domain can be locked down tight at p=reject and still receive a flawless-looking invoice-fraud email from a vendor's compromised mailbox or a domain registered yesterday that swaps one letter in the real supplier's name. DMARC has no opinion about either of those messages because neither one is forging the client's own domain.

Where Is the Money Actually Disappearing?

It is disappearing almost entirely through inbound channels that DMARC enforcement never touches. The FBI's Internet Crime Complaint Center recorded business email compromise losses of roughly $2.77 billion in 2024 across more than 21,000 complaints, and the bureau's longer-running tracking shows the category has been one of the two or three costliest crime types it monitors every year since 2019, according to the 2024 IC3 Annual Report.

Almost none of that loss comes from someone forging the victim's own domain. It comes from a message that arrives looking like it belongs, sent from a domain the client does not own and the client's own DMARC record cannot govern. Microsoft's security documentation separates this exact scenario out as domain impersonation, noting that messages from a lookalike domain are able to pass regular SPF, DKIM, and DMARC checks because the impersonated domain is a real, independently registered one and the mail is technically authentic to itself, a distinction covered in Microsoft's guide to impersonation insight in Defender for Office 365. The email is not forged. It is simply from somewhere the client never agreed to trust, and outbound DMARC policy was never built to catch that.

Australia's national cyber security agency lists the mechanics plainly: criminals commonly register a domain name that looks very similar to a target business, because contacts may recognize the pattern and assume it is the real one, a tactic described in the ACSC's guidance on preventing business email compromise. A dropped letter, an added hyphen, a swapped top-level domain. None of it triggers a DMARC failure anywhere, because the sending domain authenticates perfectly against itself.

What Inbound Authentication Scanning Actually Catches

Inbound authentication scanning evaluates the mail arriving at a client's mailbox against a different question than DMARC answers. Instead of asking "is this really from the domain it claims," it asks "does this sender, this domain, and this pattern of behavior match what we'd expect from a legitimate counterpart," layering domain similarity detection, sender history, and authentication-result inspection on every inbound message rather than just the client's own outbound stream.

CISA's phishing guidance for small and midsize organizations points at the same gap from the defender's side, recommending that organizations pair authentication controls with ongoing technical filtering specifically because phishing remains the dominant delivery mechanism across credential theft and BEC campaigns regardless of how well a domain's own outbound posture is configured, a point laid out in the CISA, NSA, FBI, and MS-ISAC phishing guidance published in 2025.

In practice, the gaps an inbound layer closes tend to fall into a small, repeatable set:

• Lookalike and cousin domains that differ from a real vendor or partner by one character, a hyphen, or a swapped TLD
• Freemail or newly registered domains sending as a named executive with no prior mail history to that recipient
• Compromised vendor mailboxes sending real invoices with altered payment details, which pass every authentication check because the account itself is genuine
• Display-name spoofing where the visible sender name matches a known contact but the underlying address does not

Microsoft's Defender for Office 365 documentation describes impersonation protection as a dedicated layer built to catch exactly this pattern, flagging senders who are not configured as impersonation-protected but who nonetheless mimic a protected user's display name or domain, a capability outlined in Microsoft's anti-phishing policy configuration guide. That is a second, separate control plane from DMARC, and most clients running Microsoft 365 or Google Workspace under default settings have it either turned off or left unconfigured.

The Coverage Gap in One View

The table is not an argument against DMARC enforcement. Every client should still reach p=reject, because it closes off the client's domain as a weapon against their own customers and partners. But selling DMARC as the whole email-security engagement leaves the client exposed to the exact fraud pattern that produces the insurance claims, the wire-fraud police reports, and the uncomfortable call asking why the MSP didn't mention this risk.

Turning the Gap Into a Service Line

This is the part that matters for growth, not just risk reduction. Every client already paying for DMARC monitoring and enforcement is a client who has demonstrated willingness to spend on email authentication, has already been educated on why spoofing matters, and is primed for the next conversation about what DMARC does not cover. That conversation is far easier to have before an incident than after one.

An MSP that packages inbound authentication scanning alongside DMARC enforcement is selling a complete story instead of half of one: outbound domain protection for the client's reputation, inbound scanning for the client's wallet. Tiering that bundle is straightforward to model against existing per-domain DMARC pricing, and a clear breakdown of how that fits into a managed services rate card is laid out on the pricing page. Technicians who have already walked a client through SPF, DKIM, and DMARC setup are not starting from zero on the inbound side either. The same DNS and mail-flow context carries over, and the getting-started guide walks through enabling inbound scanning across a client's existing authenticated domains without re-doing the outbound work.

The uncomfortable truth for MSPs is that "we handled your email security" is a claim clients remember precisely at the moment it turns out to be only half true. Closing that gap before a client finds it the hard way is cheaper in every sense than explaining it afterward, and the fastest way to see where the current gap sits across a client book is to run the scan. Setting that up takes less time than the original DMARC rollout did, and the signup page is where that starts.

Authentication enforcement and inbound fraud detection were never competing priorities. They were always two halves of the same client promise. MSPs who treat them as one project are the ones still fielding the "how did this happen" call months after the DMARC project closed.