DMARC

The Vendor Onboarding Bottleneck: Why DMARC-Enforcing Clients Still Can't Safely Add New Marketing Platforms

October 7, 2026

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

A client at p=reject feels safe. The dashboard is green, the audit checkbox is ticked, and the security team has moved on to the next project. Then marketing signs a contract with a new outreach platform, pastes an include line into DNS without telling anyone, and two weeks later invoices stop reaching customers. Nobody touched the DMARC policy. The policy did exactly what it was told to do.

That gap between "DMARC is enforced" and "DMARC is safe to operate" is where most vendor onboarding failures live. A domain at p=reject cannot safely add a new marketing or sales platform without someone first checking SPF capacity, DKIM alignment, and sender overlap. Skipping that check either breaks legitimate mail or forces the client to loosen enforcement, undoing months of hardening work.

Why does adding one marketing platform put the whole domain at risk?

It happens because SPF has a hard ceiling that most marketing teams have never heard of. Sender Policy Framework evaluation is capped at 10 DNS-querying mechanisms per check, a limit defined directly in RFC 7208, the IETF standards-track specification that governs SPF. Every include: statement a vendor asks for, plus everything nested inside that vendor's own record, counts against that single shared budget.

A domain running Google Workspace, a CRM, a help desk, and two transactional senders can already be sitting at eight or nine lookups before marketing ever gets involved. The next vendor onboarding, whatever it is, is the one that tips the record into a permanent error. When that happens, receiving servers stop evaluating SPF entirely and treat the result as a failure for every sender on the domain, not just the new one. Under DMARC enforcement, that failure cascades into real rejections at the SMTP level for legitimate mail that has nothing to do with the new platform.

What happens when a vendor is added without an alignment check?

The new platform's mail often authenticates perfectly, just not for the client's domain. Marketing tools frequently send through their own infrastructure while putting the client's brand in the visible From header, which means SPF can pass for the vendor's return-path domain while DKIM is missing entirely. Google's own guidance is explicit that for a message to pass DMARC, the From domain must align with either the authenticated SPF domain or the DKIM domain, not merely show a passing check somewhere in the chain, a requirement laid out in Google's bulk sender guidelines FAQ.

This is not a theoretical edge case. Google requires any domain sending 5,000 or more messages a day to Gmail recipients to authenticate with SPF and DKIM and to publish a DMARC record, a bar formalized in Gmail's email sender guidelines. A client who meets that bar today can fail it the moment a new campaign tool goes live unaligned, and the client usually finds out from a support ticket, not a monitoring alert.

The stakes are not limited to marketing deliverability either. Government buyers increasingly expect the same discipline from vendors they do business with. The Cybersecurity and Infrastructure Security Agency's Binding Operational Directive 18-01 set the precedent that federal domains must reach DMARC enforcement, and that posture has filtered into vendor security questionnaires well beyond federal contracting. A client that drops out of enforcement to fix a broken onboarding is not just risking a few bounced emails, it is risking a compliance attestation.

Who actually owns this risk inside a typical client?

Nobody does, structurally, and that is the core of the bottleneck. Marketing owns the vendor relationship and the contract. IT owns the DNS zone. Security, where it exists at all in an SMB, owns the DMARC policy. None of the three groups has full visibility into how a new include statement interacts with the other two, and the client rarely has the internal depth to close that gap on their own.

This is the same structural gap behind a wider industry pattern. Sophos's 2024 survey of 350 MSPs across four countries found that participating providers rank a shortage of in-house cybersecurity skills as the single biggest risk to both their own business and their clients' organizations, ahead of stolen credentials and unpatched vulnerabilities, according to the MSP Perspectives 2024 report. Clients without that skill in-house are not going to catch an SPF lookup overflow before it ships. They are going to call whoever answers the phone after it breaks.

That dynamic plays out the same way in adjacent research on MSP technology adoption. A recent analysis found that a significant share of MSPs report major setbacks when adapting to more advanced security technologies, a pattern consistent with how DMARC enforcement gets stood up once and then quietly drifts out of alignment as the client's vendor list changes, as described in IBM's coverage of MSP security adoption challenges. DMARC is not a project with an end date. It is a living configuration that has to track every vendor the client ever signs.

What should happen before a new vendor gets added to SPF or DKIM?

A short, repeatable check before DNS changes ship, not after support tickets arrive. The sequence does not need to be complex, it needs to happen every single time, which is exactly the step that gets skipped when it lives in someone's head instead of a process.

• Count the current SPF lookups and confirm there is room under the 10-mechanism ceiling before adding the vendor's include.
• Confirm the vendor supports DKIM signing with a selector on the client's domain, not just SPF on their own return path.
• Check the vendor's own record for nested includes that could push the total over budget even if the top-level addition looks small.
• Hold any DMARC policy change in monitoring mode until a full reporting cycle confirms the new sender authenticates cleanly.

None of these steps require a security degree. They require someone checking consistently, which is precisely what falls apart in a client environment with no dedicated owner and an MSP that only looks at DMARC reports reactively.

Turning the bottleneck into a service line

This is where the onboarding bottleneck stops being a liability and starts being a reason for a client to pay for ongoing email security rather than a one-time DMARC setup project. Every new marketing platform, CRM migration, or outbound sales tool is a recurring trigger for exactly the kind of check most clients cannot run themselves and most MSPs have been doing manually, inconsistently, or not at all.

Packaging that check as a standing service changes the sales conversation from "we set up your DMARC record" to "we keep your DMARC record safe every time your business changes vendors." A client evaluating marketing platforms a few times a year has a few times a year in which they could silently break compliance, and an MSP that proactively scans for SPF capacity and alignment issues before DNS changes ship is selling continuity, not a project. ActiScan's scanning platform was built around that recurring need, flagging lookup counts and alignment gaps automatically so the check does not depend on someone remembering to run it.

Firms exploring this as a line item can review tiered options on the pricing page, most of which map cleanly onto per-domain monitoring that scales with a client's vendor count rather than a flat annual engagement. New teams onboarding their first batch of client domains typically start with the getting-started guide, which walks through connecting DNS records and establishing a baseline before enforcement tightens. From there, creating an account through the signup page is the fastest way to see what a client's current SPF budget actually looks like, often before the next vendor contract gets signed instead of after it breaks something.

The bottleneck is real, and it is not going away as marketing stacks get more fragmented and DMARC enforcement becomes more common across both regulated and unregulated industries. What changes is whether an MSP treats it as an occasional emergency call or as the recurring revenue opportunity it actually is.