DMARC

The Vendor List DMARC Enforcement Forces You to Confront

September 30, 2026

Randy Hall, CEO— AI-assisted and reviewed prior to publication.

When an MSP finally flips a client's DMARC policy from monitoring to enforcement, the first calls rarely come from attackers being blocked. They come from the client's own marketing team, asking why the newsletter platform's campaign bounced, or from HR asking why the benefits portal's onboarding email never arrived. The domain was never really theirs alone. Enforcement just made that visible.

That moment is the hidden liability this article is about. Raising a DMARC policy to quarantine or reject does not create new risk, it exposes risk that was already there: vendors sending as the client's domain without SPF or DKIM alignment, often without the client's IT team ever approving that access in the first place.

Why does DMARC enforcement expose vendors nobody knew about?

DMARC enforcement exposes unauthorized senders because most organizations never built a complete inventory of who sends mail on their behalf. Marketing platforms, HR systems, invoicing tools, and CRM integrations frequently get connected by a department outside IT, using the domain's "From" address without ever touching SPF, DKIM, or the security team's radar. The policy defined in RFC 7489, and now carried forward into the newer DMARCbis standard published as RFC 9989, was designed precisely to surface this gap: it lets a domain owner tell receiving mail servers what to do with messages that fail to align, and enforcement is the point where that instruction actually gets enforced rather than merely logged.

Under a monitoring policy of p=none, none of this matters operationally. Unaligned mail still lands in the inbox, and the aggregate reports quietly pile up unread. The failures only become consequential once the policy moves to quarantine or reject, which is exactly the moment most MSPs treat as a deliverability milestone rather than a compliance event.

Who is actually liable when a vendor's mail fails authentication?

Liability does not disappear just because a vendor sent the noncompliant mail. Regulators have made clear that the domain owner, not the vendor, carries the obligation to oversee how third parties handle data and communications on its behalf. The Federal Trade Commission has stated this directly in a vendor oversight enforcement action, with the agency's consumer protection director noting that for regulated companies, "vendor oversight is not just a good idea, it's the law," according to a summary of the settlement covered by Lexology.

That standard was built around data handling, but the underlying logic transfers directly to email authentication. If a payroll vendor, benefits administrator, or claims processor sends unauthenticated mail from a client's domain, and that mail is later spoofed or intercepted because the legitimate channel was never locked down, the client's own compliance posture is what regulators and auditors will examine first. The vendor's mistake becomes the client's exposure, and by extension, the MSP's problem to have flagged.

What the compliance frameworks already assume

Federal guidance already treats DMARC enforcement as baseline hygiene, not a nice-to-have. The Cybersecurity and Infrastructure Security Agency's Binding Operational Directive 18-01 required federal civilian agencies to configure valid SPF and DMARC records, and the directive's own text specifies that agencies were required to move toward a policy stronger than monitoring within a defined enforcement window, as described on CISA's directive page.

NIST's own guidance goes further on the third-party question specifically. NIST Special Publication 800-177 Revision 1, the government's detailed reference on trustworthy email, walks through DMARC configuration as part of a layered approach and makes the point that email cannot be made trustworthy through any single control, which is precisely the gap third-party senders expose when they operate outside SPF and DKIM alignment, as laid out in NIST's published guidance.

Commercial mailbox providers have converged on the same expectation from a different direction. Google's current sender guidelines require domain owners sending 5,000 or more messages a day to authenticate their outgoing mail, a threshold that many client organizations cross without realizing it once every connected vendor platform is counted, according to Google's own sender guidelines. A client does not need to be a bulk marketer to trip this line. Its CRM, its support ticketing tool, and its payroll provider can collectively push it over the threshold even if none of them individually would.

Where the exposure actually hides

The pattern MSPs run into is remarkably consistent across clients regardless of industry. A short list of the usual offenders covers most of what enforcement will surface:

• Marketing automation and email newsletter platforms sending as the primary domain
• HR, payroll, and benefits administration tools that email employees directly from the company domain
• CRM and sales engagement tools configured to send on behalf of individual reps
• Support ticketing and helpdesk systems that reply from a support alias on the domain
• Invoicing, billing, and accounts receivable platforms sending payment notices

Each of these categories carries a different flavor of downstream risk once mail starts failing DMARC checks, which is worth mapping before a client's policy moves to enforcement rather than after.

How MSPs should treat this as vendor risk management, not just email hygiene

Documenting every third-party sender before enforcement turns a deliverability project into a defensible compliance record. That documentation should show which vendors were identified, what authentication method each was given, and when the client's policy moved from none to quarantine to reject, because that timeline is what an auditor, a cyber insurer, or a regulator will eventually ask to see.

Building that record is largely a discovery problem before it becomes a technical one. Reviewing weeks of DMARC aggregate reports to identify every sending source, cross-referencing it against the client's known vendor contracts, and getting DKIM keys issued for each legitimate sender takes longer than most MSPs budget for it, which is why treating the transition from monitoring to enforcement as a phased project pays off more than trying to force it through in a single change window.

This is the gap ActiScan's scanning workflow is built to close for MSPs managing this across a client book rather than a single domain. The platform's getting-started guide walks through how to pull a client's existing DMARC reports and third-party sender list into one view before any enforcement decision gets made, which turns the discovery phase from a manual export-and-cross-reference exercise into something a technician can complete between other tickets. Firms evaluating whether that fits their client mix can compare tiers on the pricing page before ever touching a live production domain.

The bottom line for MSPs

None of this means every client with an unauthenticated vendor is one incident away from a regulatory action. It means the visibility DMARC enforcement creates is also a liability inventory, and the MSP that documents it first is the one positioned to explain it later, whether that explanation goes to the client, an auditor, or a carrier processing a claim.

For MSPs still running client domains at p=none, the honest starting point is treating every enforcement rollout as a vendor audit with an email side effect, not the reverse. Teams ready to move a client book through that process methodically can start from a free ActiScan signup and build the sender inventory before flipping the first policy to reject.