DMARC

When DMARC Passes But the Client Still Gets Burned: The Revenue MSPs Lose to Authenticated Phishing

November 4, 2026

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

A client's domain passes SPF, DKIM, and DMARC on every outbound message. The aggregate reports look clean. The dashboard is green. Then a phishing campaign goes out through that exact domain, lands in partner inboxes with a perfect authentication score, and the MSP finds out from an angry phone call instead of a monitoring alert. That sequence is becoming common enough that it deserves a name, and it deserves a line item in how MSPs price and scope their security services.

The core problem is simple to state and expensive to ignore: DMARC was built to stop domain spoofing, not to vouch for the safety of a message or the integrity of the account sending it. When an attacker compromises a mailbox, a connected SaaS platform, or an email delivery service that a client's domain is authorized to use, every message that attacker sends still passes SPF, DKIM, and DMARC, because the infrastructure itself really is authorized. Authentication confirms the pipe. It never inspected what traveled through it.

Why does a passing DMARC check no longer mean a message is safe?

Because DMARC was never designed to evaluate message content or account integrity in the first place. The protocol's own specification describes it as a policy mechanism that lets domain owners tell receivers what to do with messages that fail SPF or DKIM alignment, and explicitly notes it does not grant elevated trust to authenticated mail beyond that narrow function, as laid out in RFC 7489. A receiving server checking DMARC is asking one question only: did this message originate from infrastructure the domain owner authorized? If the answer is yes, because the attacker is sitting inside that authorized infrastructure, DMARC has nothing left to say.

Recent incident writeups make the mechanism concrete. Microsoft's threat intelligence team disclosed a campaign it called "authentication laundering," in which phishing mail was relayed through legitimate notification infrastructure and link-redirect services so that it authenticated cleanly, a technique the company detailed as targeting hospitality organizations and documented in reporting on the code of conduct phishing campaign. That campaign reportedly affected more than 35,000 users across 13,000 organizations by routing authenticated messages through a commercial email delivery platform configured on a rented cloud VM, which meant the mail passed exactly the checks defenders had been trained to trust.

How attackers turn a trusted domain into a phishing amplifier

A compromised account with DMARC already at enforcement is, counterintuitively, a better weapon than a spoofed lookalike domain. Lookalike domains get caught by brand-monitoring tools and trained users spot the misspelling. Mail from the real domain, signed with the real DKIM key, passing a real DMARC check, sails past both defenses. One documented case involved a dental practice with a sixteen-year registration history whose single compromised account turned the domain into a phishing delivery mechanism, with researchers noting that any message passing SPF or DKIM gets treated as authenticated even when the account behind it has been taken over.

This is also why Microsoft's own 2026 threat data places so much weight on identity as the entry point rather than on authentication failures. In Defender Experts telemetry, valid account abuse accounted for a fifth of observed initial access activity, and phishing's share of incident response engagements more than tripled year over year according to the company's Digital Defense Report analysis. None of that activity requires breaking DMARC. It requires getting inside the account DMARC already trusts.

For MSPs, the operational lesson is that DMARC enforcement and account security are two separate controls that get bundled into one line item on a security checklist, and clients assume the first one covers the second. It does not. A domain can sit at p=reject, satisfy every requirement in Google's bulk sender guidelines, and still become the delivery vehicle for a campaign that damages a dozen downstream relationships, because Google's enforcement rules only require that SPF, DKIM, and a DMARC record exist and align, not that the account sending the mail is uncompromised.

What does this cost MSPs in dollars, not just reputation?

It costs renewal revenue, and the number is larger than most MSPs budget for. A recent industry survey found that 53% of MSPs lost at least one client in the past 24 months because they could not contain an incident fast enough, with the most common lost-client contract value falling in the $25,000 to $100,000 annual range, according to research published by Coalition. Authenticated phishing is exactly the kind of incident that stretches containment time, because the first instinct of a help desk reviewing headers is to confirm authentication passed and move on, which is the wrong signal to trust when the account itself is the compromise.

The liability exposure compounds the revenue loss. Third-party involvement in breaches now shows up in a growing share of incident datasets, and MSPs sit squarely in that third-party category when a client's authenticated domain gets weaponized against its own partners. Analysis of recent MSP liability cases notes that breaches involving a third party made up 48% of a major annual breach dataset, a sharp increase from the prior year, as reported in coverage of MSP liability litigation trends. When a client's authenticated infrastructure gets abused to phish its own customers or vendors, the contractual question of who was responsible for noticing becomes the center of the dispute, not the technical question of whether DMARC was configured correctly.

The monitoring gap most contracts never close

Most MSP service agreements treat DMARC deployment as a one-time project: publish the record, move from p=none to p=reject, close the ticket. That approach satisfies the letter of frameworks like CISA's Binding Operational Directive 18-01, which requires federal agencies to reach a reject policy on their domains, but it stops short of what the directive's own guidance recommends afterward: using the reporting feedback loop on an ongoing basis to catch problems as they emerge, not just at initial rollout.

Aggregate DMARC reports keep arriving for the life of the domain, and they keep recording every sending source whether or not anyone is reading them. A compromised mailbox or a hijacked connection to a third-party sending platform shows up in those reports as a new or anomalous source, often before a single recipient complains. Treating report ingestion as a recurring operational task, not a one-time audit, is the difference between catching an authenticated phishing wave in its first hours and learning about it from a client's angry vendor three weeks later.

A short list of what separates reactive MSPs from the ones who catch this early:

• Aggregate reports are parsed and reviewed on a defined cadence, not left to accumulate unread in a shared mailbox.
• Every authorized sending source, including third-party platforms and marketing tools, is inventoried and revisited when a client adds or drops a vendor.
• Volume and source anomalies trigger an alert workflow instead of waiting for a client to report suspicious replies.
• Account-level controls like conditional access and session monitoring are scoped as a companion service to DMARC, not assumed to be someone else's job.

This is the gap that purpose-built scanning tools exist to close, because manually parsing XML aggregate reports across dozens of client domains does not scale past a handful of accounts. A platform that is built for this workflow can be live on a new client domain within a single onboarding session, which is the kind of turnaround MSPs need when they are trying to convert DMARC monitoring from a compliance checkbox into a retainable line item. The practical path for a technician starting that process usually runs through a structured onboarding flow rather than a manual DNS audit, and ActiScan's own getting-started guide walks through exactly that sequencing for a first client domain.

Turning the gap into a sellable service, not a liability

The commercial opportunity here is as real as the risk. MSPs that can show a client dashboard-level visibility into who is sending as their domain, flagged in near real time when a new or unusual source appears, are selling continuous assurance rather than a one-time configuration task. That distinction supports a recurring line item instead of a project fee, and it gives the MSP a defensible answer the next time a client asks why a phishing email that "passed everything" still got through. Reviewing how that service tier fits into existing managed security packages is worth doing before the next renewal conversation, and the pricing page breaks down how monitoring scales across a growing client base.

None of this replaces a security team's judgment or guarantees that a determined attacker will be caught before damage occurs. What it does is close the specific, well-documented gap between "authentication passed" and "the account was safe," which is where a measurable share of the industry's most damaging authenticated phishing campaigns currently live. MSPs that treat DMARC reporting as a living signal, not a deployment milestone, are the ones positioned to catch the next compromised-infrastructure campaign before it becomes a lost contract. Getting that monitoring running on a client domain starts with a straightforward signup rather than a lengthy procurement cycle, and the sign-up page is the fastest route to a first working scan.