MSP Operations

Client Retention Runs Through the Report, Not Just the Fix

August 31, 2026

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

An MSP spends three weeks moving a client's DMARC policy from p=none to p=quarantine, cleans up two rogue SPF includes, and rotates a DKIM key that was about to expire. The client's inbox behaves exactly as it did the day before. Nothing broke, nothing visibly changed, and that is precisely the retention risk: work that succeeds by becoming invisible.

Client retention runs through the report because a fix a client cannot see is a fix a client cannot value at renewal time. The technical remediation protects the domain, but only a report that translates that remediation into risk avoided, policy progress, and a forward plan gives the client a reason to keep paying for the service rather than shop it out at the next contract cycle.

Why do technically safer clients still walk away?

Because a large share of email-authentication work is deliberately invisible. SPF alignment, DKIM signing, and DMARC policy staging happen in DNS records, not in the inbox, so a client who never receives a spoofed invoice never learns whether that absence is proof the MSP is working or evidence that nothing was ever at risk in the first place.

That ambiguity is expensive to leave unresolved. Research summarized in Harvard Business Review on customer economics notes that depending on the study and industry, acquiring a new customer is anywhere from five to 25 times more expensive than retaining an existing one. When a client can't distinguish a well-run security program from a quiet one, price becomes the only variable left to negotiate on, and a cheaper competitor only has to promise the same invisible outcome to win the account.

The fix itself does not correct this. A client reading a renewal invoice with no supporting evidence is being asked to trust that eight months of DNS changes mattered. A short, recurring report that shows the domain's authentication posture moving from none to enforced, with the spoofing attempts that were actually blocked along the way, replaces that trust exercise with a paper trail the client can point to.

What belongs in a report that actually protects the account?

It has to answer three questions a business owner actually asks: what was at risk, what changed, and what happens next. A raw DMARC aggregate report does none of that on its own, since the format defined in the DMARC specification is built for machines rather than executives.

The IETF's standards-track documentation for DMARC aggregate reporting describes the underlying data precisely for this reason: the report is an XML document that contains extensible elements allowing for other types of data to be specified later, sent from mail receivers back to the domain owner. That structure is exactly what a client should never see directly. A retention-grade report sits on top of it and translates the same underlying evidence into something a non-technical stakeholder can act on:

• A trend line showing the percentage of mail passing authentication over the reporting period, not just a pass/fail snapshot.
• The domain's current enforcement stage (none, quarantine, or reject) plotted against where it started.
• A plain-language count of blocked or flagged spoofing attempts, tied to the specific senders involved.
• A forward plan naming the next policy step and a realistic date for reaching it.

Getting a first version of that baseline in front of a client does not need to wait for a quarterly review. A scan run through ActiScan's getting-started guide can produce the first before-and-after data point within a day of onboarding a domain, which gives the account a starting line to measure every later report against.

How do 2024 and 2025 bulk-sender rules change what a report has to prove?

They raise the stakes on the same data a retention report already needs, because authentication failures now carry immediate delivery consequences instead of theoretical ones. Since February 2024, Google has required senders of 5,000 or more daily messages to Gmail addresses to authenticate their mail, and its own guidance confirms that as of February 1, 2024, all email senders who send email to Gmail accounts must meet the requirements in this section, with DMARC required specifically for bulk senders. Yahoo followed with equivalent rules on the same timeline.

That shift means a client's DMARC posture is no longer just a security metric, it is a deliverability gate. A report that shows SPF and DKIM alignment trending upward is now directly defending the client's ability to reach Gmail and Yahoo inboxes at all, which is a far easier value proposition to sell at renewal than "we reduced theoretical spoofing risk."

The federal government provided the template for this kind of phased, reportable enforcement years earlier. CISA's Binding Operational Directive 18-01 required agencies to publish DMARC and then escalate policy over time, and the directive's own text confirms that BOD 18-01 requires federal agencies to set a DMARC policy of p=reject, following an interim period at a weaker setting. MSPs walking commercial clients through the same none-to-reject path are running a scaled-down version of a process a federal regulator already proved works, and a report is the artifact that shows a client exactly where they sit on that same curve.

Building the reporting habit into the service, not bolted onto it

Reporting cadence should be a design decision at the start of the engagement, not an afterthought added when a client asks what they're paying for. Deciding how often a report goes out, and how much detail on SPF, DKIM, DMARC, and BIMI status it includes, is largely a function of which service tier a client sits in on the pricing page, and that mapping should be explicit in the sales conversation rather than left for the client to infer.

The scanning and reporting layer only works as a retention tool if it runs continuously rather than as a one-time audit. MSPs building this into a repeatable practice across a portfolio of domains can set the first client up through signup and have baseline data captured before the next scheduled business review, so the review opens with a scorecard instead of a status update nobody asked for.

The fix earns the client's trust once. The report earns it every renewal cycle after that, and in a market where authentication requirements from Google, Yahoo, and federal regulators keep tightening, the MSPs who can produce that evidence on demand are the ones clients have the least reason to leave.