Email Security Sales
DMARC Enforcement Won't Save the Renewal When a Client's Vendor Gets Breached
October 16, 2026
Ric Hall, CRO— AI-assisted and reviewed prior to publication.
An MSP flips a client's DMARC record to p=reject, cleans up the SPF record, rolls out DKIM across every sending platform, and closes the ticket. Six weeks later, the client's payroll processor discloses a breach. An attacker, working from the processor's real mailbox or a domain one character off from it, sends the client's controller a routine-looking update to direct deposit instructions. The money moves. The client calls the MSP first, not the processor, because the MSP is who sold them on being "protected."
That call is where a lot of otherwise well-run security programs lose their renewal. The client's domain was never spoofed. DMARC did exactly what it was built to do. None of that matters to a client who was told their email was secured and then lost six figures to a message that never touched their own domain at all.
The direct answer is this: DMARC enforcement governs only who is allowed to send mail as the client's own domain. It has zero authority over a vendor's domain, a compromised vendor mailbox, or a lookalike domain registered by an attacker. When the breach happens one hop away, in the supply chain, enforcement on the client's own DNS record is structurally unable to intervene.
Why Does DMARC Stop at the Client's Own Front Door?
DMARC was designed to solve one specific problem: proving that mail claiming to be from a domain actually came from a server the domain owner authorized. The protocol, formalized in RFC 7489, ties SPF and DKIM results to the domain shown in the visible From header and lets the domain owner tell receivers what to do when that check fails.
That scope is narrow by design, and it is narrow on purpose. A domain owner can only publish policy for domains they control, which means a client's DMARC record has no say over how a vendor's domain is configured, who sends mail from it, or whether that vendor has enforcement turned on at all. As one recent breakdown of the protocol's limits puts it, DMARC reduces spoofing risk for one specific thing, the exact domain in the From header, and that is the entire scope of what it covers.
That same narrowness means a lookalike domain, a compromised legitimate mailbox, or a vendor's own misconfigured DMARC record all sail through completely untouched by anything the MSP did to the client's domain. The attacker in these cases is not forging the client's identity. They are borrowing a vendor's identity to attack the client from the outside, and the client's own authentication posture, however well enforced, has no jurisdiction there.
What Actually Happens When a Client's Vendor Gets Breached?
When a third-party vendor is compromised, the attacker typically gains two things at once: a channel that passes every authentication check and a trove of intelligence about how the client actually does business with that vendor. Cloudflare describes vendor email compromise as a targeted BEC variant in which attackers impersonate a third-party vendor specifically to steal from that vendor's own customers, often by inserting themselves into an existing, trusted email thread.
The mechanics are not theoretical. Cloudflare's own writeup walks through the 2020 attack on the nonprofit One Treasure Island, in which attackers infiltrated an existing email chain, impersonated the organization's bookkeeper, and redirected a payment, and the organization lost $650,000 in a single wire transfer. That is the pattern MSPs are up against: not a spoofed domain the client's own filters could catch, but a hijacked or cloned identity arriving through a channel the client already trusted.
The dollar figures at the macro level back up why this keeps happening. The FBI's Internet Crime Complaint Center logged business email compromise losses of $2.77 billion across more than 21,000 reported incidents in 2024 alone, part of a decade-long climb that has pushed cumulative reported BEC losses well past $17 billion since the category was first tracked, according to the 2024 IC3 Annual Report. None of that total requires a single domain spoof. Vendor impersonation, lookalike registrations, and compromised legitimate accounts all fall outside what domain authentication alone was ever built to stop.
| Attack pattern | Does the client's DMARC enforcement stop it? |
|---|---|
| Attacker spoofs the client's own domain | Yes, this is exactly what enforcement is for |
| Attacker registers a lookalike of a vendor's domain | No, the client has no authority over that domain |
| Attacker sends from a vendor's real, compromised mailbox | No, the mail authenticates correctly for the vendor |
| Vendor's own DMARC record is weak or absent | No, that is the vendor's configuration, not the client's |
How Should MSPs Reposition the Conversation Before the Breach Happens?
The fix is not abandoning DMARC enforcement. It is refusing to let it stand in as the whole security story, and building the vendor-risk conversation into the service from day one rather than after an incident forces it.
Regulators are already pointing in this direction for anything resembling a regulated client base. FINRA's cybersecurity advisory on third-party provider risk explicitly recommends ongoing monitoring and risk assessments of third-party providers alongside continuous watching for lookalike domains and phishing emails targeting those relationships, treating vendor exposure as a distinct, managed risk category rather than an afterthought. CISA takes the same position from the MSP's own side of the relationship, warning that MSPs need to understand their own supply chain risk and manage the cascading risk it creates for every downstream customer, in its joint advisory on protecting MSPs and their customers from cyber threats.
In practice, that means a few concrete additions to the standard DMARC engagement:
- Extend domain monitoring to the client's named critical vendors, not just the client's own domain, so lookalike registrations and sudden authentication anomalies on vendor-adjacent mail surface before a payment gets redirected.
- Put a verification step in writing for any payment or credential change request, independent of how legitimate the email thread looks, since compromised vendor accounts produce mail that is otherwise indistinguishable from the real thing.
- Set expectations explicitly in the statement of work: DMARC enforcement protects the client's outbound identity, and a separate layer is required to reduce exposure from the vendors the client depends on.
That last point is a sales conversation as much as a technical one. A client who understands upfront that enforcement is one layer of several is a client who calls the MSP as a partner when a vendor breach surfaces, not as the party at fault. Framing it any other way sets up an expectation gap that eventually costs the account regardless of how well the DMARC record itself was built.
Turning the Gap Into a Service Line
This is also where the gap becomes revenue rather than just risk. Vendor domain monitoring, lookalike detection, and authentication visibility across a client's supply chain are a natural tier above baseline DMARC enforcement, and packaging them separately gives MSPs a reason to have the vendor-risk conversation at renewal instead of after a loss. A clear breakdown of what belongs in the baseline package versus the expanded tier is something MSPs can work out directly on the pricing page, scoped to how many critical vendors a given client actually depends on.
Clients rarely distinguish between "that wasn't our layer" and "we weren't protected." The MSPs who get ahead of that confusion are the ones who document the boundary before an incident forces the conversation, starting with a documented enforcement baseline that new technicians can follow consistently, which is exactly what the getting-started guide is built to standardize across an MSP's client book. For teams that have not yet mapped vendor exposure into their DMARC workflow, the fastest way to see where that gap currently sits is to run a scan through the signup page and compare what is actually enforced against what the renewal conversation assumes is covered.
None of this guarantees a client never loses money to a vendor-side breach. What it does is move the MSP from the party left holding blame for a layer it never sold to the party that flagged the risk, scoped a defense for it, and can point to the contract that said so.