DMARC

How MSPs Miss Revenue When DMARC Policy Enforcement Breaks Third-Party Marketing Automation That Clients Don't Know They're Running

November 11, 2026

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

A client calls the help desk convinced their email marketing platform is broken. Leads have stopped arriving, a product launch sequence never landed, and nobody on the client's staff can explain why. The actual cause, discovered days later, is that the MSP tightened the client's DMARC policy to p=reject the week before, and a marketing automation tool the sales team signed up for on a corporate card eighteen months ago was never included in the SPF record or given an aligned DKIM key.

The direct answer: enforcement breaks third-party marketing automation when a client's sales or marketing team quietly added a sending platform that IT never authenticated. The moment the domain moves to quarantine or reject, that platform fails alignment, mail drops silently, and the client loses revenue the MSP rarely gets paid to fix.

This is not a rare edge case. It is one of the most common and least discussed failure modes in DMARC rollouts, and it costs MSPs both client trust and recurring revenue they could otherwise be billing for.

Why Does Policy Enforcement Break Tools Nobody Told IT About?

Enforcement breaks these tools because DMARC only passes when the sending source is both authenticated and aligned with the domain in the visible From address, and marketing platforms frequently send on a client's behalf without meeting that bar. Per RFC 7489, the governing standard for DMARC, identifier alignment requires the domain validated by SPF or DKIM to match the organizational domain in the message's From header. A marketing tool that was added to the SPF record years ago but never configured for DKIM, or one that sends with a return path the client never touched, can pass SPF or DKIM in isolation while still failing DMARC outright.

Marketing staff rarely loop in IT when they adopt a new sending platform. They connect a trial account, import a contact list, and start sending, often using the company domain as the From address because that is what the platform's onboarding wizard defaults to. The MSP's DNS inventory, built from whatever SPF includes and DKIM selectors existed at the last audit, has no record of the tool at all.

What Counts as Shadow Marketing Automation?

Shadow marketing automation is any platform sending mail as the client's domain that the MSP has not explicitly authenticated and tracked in its DMARC visibility tooling. It is a subset of the broader shadow IT problem that security frameworks like the CIS Controls have long flagged as a source of unmanaged risk, except here the blast radius is revenue instead of just exposure.

Common examples an MSP is likely to discover only after enforcement include:

• Email service providers such as Mailchimp or Constant Contact connected by a marketing coordinator for a single campaign
• CRM-linked senders such as HubSpot or Pardot, often added by sales operations independent of any IT ticket
• Event and webinar platforms that send calendar invites and reminders from the client's domain
• Transactional senders embedded in e-commerce or billing software that nobody classified as "email" in the first place
• Legacy newsletter tools still active from a previous marketing hire who has since left the company

Mailchimp's own help documentation notes that the platform authenticates campaigns automatically to guard against spam and forgery, but that automatic signing only covers domains the account owner has explicitly verified and connected, as described in Mailchimp's domain authentication guide. A client who never completed that verification step is sending unauthenticated mail under a domain the MSP believes is fully locked down.

How Alignment Failures Turn Into Lost Revenue

The mechanism is straightforward once isolated: the platform sends, the receiving mailbox provider evaluates SPF and DKIM, finds no aligned pass, and applies the client's own DMARC policy against the message. A p=reject policy means the message is dropped outright rather than delayed or flagged, so there is no bounce the marketing team can act on and no quarantine folder to check.

HubSpot's own knowledge base is explicit that DMARC is "an email authentication protocol that you implement outside of HubSpot," meaning the platform will not retroactively fix alignment on the client's behalf, as laid out in HubSpot's guidance on using a DMARC policy. HubSpot separately confirms that while DKIM, SPF, and DMARC are not required to send through the platform at all, a client cannot send with their own domain in the From address until that domain is properly connected, as explained in HubSpot's overview of email authentication. Every client running an unconnected or partially connected integration is one policy change away from a silent outage.

Who Owns the Blame When Campaigns Vanish?

The MSP owns the blame in the client's eyes, regardless of who signed up for the marketing tool, because the MSP is the one who changed the DNS record that triggered the failure. This is an uncomfortable reality, but it is also the reason DMARC rollouts deserve the same change-management discipline as a firewall rule change, not a quick DNS edit pushed after a single security newsletter prompted urgency.

Google's own sender guidance reinforces why MSPs are under pressure to enforce in the first place. Since February 2024, Google has required that senders transmitting more than 5,000 messages a day to Gmail accounts authenticate with SPF, DKIM, and a published DMARC record, a requirement laid out directly in Gmail's email sender guidelines. That pressure is legitimate and growing, but it is a reason to inventory every sending source first, not a license to flip policy to reject without that inventory complete.

Building Visibility Before You Flip the Switch

Visibility means knowing every domain, subdomain, and IP sending mail as the client before enforcement begins, not discovering gaps from a support ticket after the fact. Google's own guidance confirms that alignment is evaluated specifically against the organizational domain in the From header, which is exactly the detail that gets lost when a marketing tool was set up outside IT's purview, as detailed in Gmail's sender guidelines FAQ.

A practical sequence for an MSP preparing a client for enforcement looks like this:

• Pull at least 30 days of DMARC aggregate reports and list every reporting source, not just the ones already in the SPF record
• Interview marketing, sales, and finance stakeholders directly, since they are the ones most likely to have added a sending tool without a ticket
• Stage the policy at quarantine for a full reporting cycle before moving to reject, so failures surface as spam-folder complaints rather than silent drops
• Document each legitimate third-party sender with its required SPF include and DKIM selector before the final policy change

ActiScan's getting-started guide walks through exactly this sequence, mapping every discovered sender against the client's published records before any policy change is recommended. That turns a guess into a documented decision the client can sign off on before DNS changes anything.

Turning Discovery Into a Billable Service

Discovery of shadow marketing senders is not overhead to absorb quietly. It is a defined, recurring engagement that belongs on an invoice, because the alternative is an MSP eating the cost of a client's lost campaign revenue for free. Framing this work as domain authentication assessment, billed quarterly or bundled into a security retainer, converts a support headache into a line item clients already understand the value of once a campaign has gone dark even once.

Packaging it well starts with clear tiers tied to domain count and reporting depth, which is why ActiScan's pricing page breaks discovery and monitoring into plans sized for a single client domain up through full MSP portfolios. An MSP that can show a prospect a list of every third-party sender touching their domain, authenticated or not, is making a sales case that a generic security scan cannot match.

None of this guarantees a client's marketing platform will never break again, and no scanning tool replaces the judgment of whoever is actually managing the DNS change. What it does is remove the single biggest blind spot in DMARC rollouts: the sending source nobody remembered to ask about. MSPs that want to see their own clients' hidden senders before the next policy change can start with a scan through ActiScan's signup page rather than waiting for the next support ticket to reveal the gap.