Introduction
Almost every article about DMARC for MSPs is a sales argument: why your clients need it, why you should sell it, why the recurring revenue is real. This one is the counter-essay. There are client profiles where DMARC-as-a-managed-service breaks down — where the unit economics don't work, where the client's own situation makes the engagement unprofitable or operationally risky, where the right answer is to decline the work and recommend something else. Knowing which clients those are is what makes the rest of your engagements profitable.
This article is the credibility-building companion to the DMARC for MSPs pillar and the deeper-than-strictly-comfortable take on which prospects to walk away from.
Why this topic matters
The economics of a managed-service practice are dominated by a small number of unprofitable engagements. A client who consumes triple the operational time without paying triple the fee can erase the margin from three or four well-fitting clients. Identifying the bad-fit profiles before contract is much cheaper than discovering them mid-engagement, and a much better experience for both sides — the client doesn't have a bad engagement; the MSP doesn't have a bad reference.
Saying no is also a sales technique. Prospects who hear an MSP decline poorly-fitting work read the MSP as more credible, not less; they trust the recommendations they do get more. The downstream conversion rate on engagements the MSP says yes to goes up.
Profile 1: The single-domain micro-client with no senders
The client: A two-person consultancy with one domain (smallco.com). They send email through Gmail or M365 personal-tier; they have no marketing platform, no CRM, no transactional sender, no SaaS that touches email. They might receive 200 emails a day total; they might send 30.
Why DMARC-as-a-service doesn't fit: The technical work is genuinely small (one SPF, one DKIM, one DMARC TXT — could be done in an afternoon), but the recurring overhead doesn't shrink to match. The platform license costs the same as for a larger client; the monthly report review takes nearly the same time even if there's nothing to report; the QBR cadence still applies. Your loaded cost per month on this client is probably $40-60; charging $50/month leaves zero margin, charging $200/month is unjustifiable to the client.
What to do instead: One-time engagement. Charge the audit and rollout as a fixed-fee project ($1,500-$3,000), deliver the DNS records, hand the client a written runbook, and decline the recurring service. Optional: a yearly "checkup" SKU at $500-$1,000 for an annual posture review. Some MSPs find a "pay-as-you-go" model works here — charge per intervention rather than monthly.
When to reconsider: If the micro-client is growing — about to hire ten people, about to spin up marketing tooling, about to acquire a sub-domain. Growth is what makes the recurring engagement work; flatlined micro-clients are project work.
Profile 2: The regulated-industry client with strong in-house security
The client: A mid-size financial services firm, healthcare network, or government contractor with an internal CISO function, an in-house SOC, formal change-control processes, and a compliance program that already includes email-authentication requirements. They've published SPF and DKIM internally; they're at p=quarantine already; they have aggregate reporting flowing into their SIEM.
Why DMARC-as-a-service doesn't fit: The client doesn't need your operational discipline — they have their own. Your platform's reports are duplicative of what their SIEM already produces. The change-control cycle inside their organization takes weeks; the operational rhythm you want to run requires days. Your service line will spend most of its time waiting for approvals; you'll bill for monthly monitoring that the client's own team is also doing.
What to do instead: Sell expertise, not managed service. A retainer for the CISO's office — DMARC platform recommendations, periodic posture reviews, escalation support during incidents, training for their team. The retainer is small per month but high-margin and recurring. The client gets specialist advice on demand; you get an account without operational overhead.
When to reconsider: If the in-house team is overstretched and looking to outsource a specific operational task. "We don't need you to do DMARC, but we do need you to handle the third-party DKIM provisioning every time we add a new SaaS" can be a real managed-service line.
Profile 3: The M&A-heavy client with chaotic domain inventory
The client: A growing organization that acquires three or four companies a year, each bringing in new domains, new email infrastructure, new DKIM histories. The acquired entities often get partially absorbed into the parent's infrastructure but keep their own domains for years. The total domain count is changing month-over-month.
Why DMARC-as-a-service is risky here: The scope changes faster than the contract can absorb. Every acquisition is a discovery exercise — what does the acquired entity send? what's their current SPF/DKIM/DMARC posture? what's the integration timeline? The "rollout" never completes because new domains keep arriving. Per-domain pricing technically works but the constant change orders create commercial friction. The team handling the engagement spends more time updating scope than doing technical work.
What to do instead: Engagement structured around the M&A activity, not around steady-state operations. "Acquired-entity DMARC onboarding" as a fixed-fee SKU per acquisition; "steady-state monitoring" as a separate tier that only kicks in after an acquisition has been fully integrated for 90 days. This makes the variable nature of the work explicit and pricable.
When to reconsider: When the M&A activity slows down or the integration playbook becomes mature enough that acquisitions follow a predictable shape. Mature M&A processes produce predictable DMARC work; ad-hoc M&A produces chaotic DMARC work.
Profile 4: The client whose DNS is at a hard-to-work-with provider
The client: A client whose DNS is at a low-tier registrar with no API, no TXT-record-length support, sometimes no support for underscore-prefixed names. Updating SPF requires logging into a clunky web UI; publishing DKIM CNAMEs sometimes silently fails; the propagation behavior is unpredictable. The client either can't or won't migrate DNS providers.
Why DMARC-as-a-service is painful: Every DNS change is a manual ceremony. Every DKIM rotation is a small project. The operational time per task is multiples of what it would be at a competent DNS provider. The client may not even be aware of how unusual their setup is.
What to do instead: Either decline the engagement or quote it with a "challenging DNS" surcharge — typically 50-100% above the standard tier price. Be explicit about the surcharge and the reason; the client either accepts the surcharge (and pays for the real cost of the work) or migrates DNS (which fixes the underlying problem and lets you go back to standard pricing).
When to reconsider: If the client agrees to migrate DNS to a competent provider. Some engagements start with "we'll help you migrate DNS to a real provider as part of the rollout" — that's a clean way to package the conversation.
Profile 5: The client who can't or won't engage with the work
The client: The contact who signs the contract isn't the contact who has to action the operational steps — change DNS records, enable DKIM in M365, communicate with their marketing team about the new tool that's affecting authentication. Requests go unanswered for weeks. Meetings get cancelled. The internal stakeholder you need just doesn't show up.
Why DMARC-as-a-service fails: The work requires client participation. The MSP can't unilaterally change the client's DNS or enable DKIM in their tenant — those actions need client cooperation. A client who won't engage means the engagement stalls, the monthly fee gets paid for monitoring nothing useful, and the policy never escalates beyond p=none. Eventually one side or the other terminates with bad feelings.
What to do instead: Catch this in the sales cycle. The trial-engagement pattern — a paid 30-day audit and Phase 1 setup, with a defined go/no-go decision at day 30 — surfaces this before the longer engagement commits. If the client can't engage during a focused 30-day audit, they're not going to engage during a 12-week rollout.
When to reconsider: When there's an internal change at the client (new CISO, new IT lead, new champion). The reasons-for-engagement may have changed; the prospect is now different.
Profile 6: The client whose business model conflicts with email authentication
The client: A client whose legitimate business sends mail from third-party platforms that can't be authenticated properly. Common examples include email-marketing services where the client can't enable custom DKIM (cheaper tiers of some platforms strip this), legacy CRM systems with non-standard sending behavior, or aggregator services that send "on behalf of" but won't sign as the client's domain.
Why DMARC-as-a-service is fundamentally hard: The DMARC policy has to remain permissive (p=none or p=quarantine at low pct) to avoid blocking the client's actual revenue-generating mail. The recurring service doesn't get to deliver the headline outcome (enforcement). The client may eventually feel like they're paying for monitoring without getting the protection.
What to do instead: Be honest in the sales conversation. "Until you upgrade your marketing platform to a tier that supports custom DKIM, we can't safely get you to p=reject." Some clients will upgrade the platform; some won't. The ones who won't are honest declines — DMARC monitoring without enforcement is real value, but the client has to be educated about what they're getting.
When to reconsider: When the conflicting platform is upgraded or replaced. Many MSPs end up advising on the upgrade-path as part of the audit, which becomes its own value.
Profile 7: The client whose budget is unrealistic
The client: Wants DMARC. Has heard it's important. Doesn't want to pay specialist pricing. Negotiates aggressively on the rollout fee, then on the monthly fee, then on the response-time SLA, then on the QBR cadence. Each negotiation looks individually reasonable; together they leave the engagement unprofitable.
Why DMARC-as-a-service is poisoned here: The unit economics rely on the recurring tier being high-margin enough to subsidize the upfront work. Aggressive negotiation on monthly fees breaks the model. The client doesn't see the math; they just see line items they want lower.
What to do instead: Either hold the price firmly (and lose the deal, which is fine) or productize a "self-serve" tier — a monitoring-only service at a lower price with no QBR, no remediation work, no proactive change control. The self-serve tier honestly addresses the budget; clients who balk at it weren't going to convert anyway.
When to reconsider: When the client's situation changes (a phishing incident, a deliverability failure, a compliance requirement). Crisis budgets are different from steady-state budgets.
How to decline gracefully
Declining work is a sales skill. The pattern that holds up:
Lead with what fits. "We don't think a managed-service engagement is the right fit for your situation. Here's what we'd recommend instead." Specific alternatives, not generic dismissals.
Be honest about why. "Your DNS provider doesn't support the operational patterns we'd need." "Your team has more in-house capability than our model is designed for." Concrete reasons.
Leave the door open. "If your situation changes — new DNS provider, growth, an acquisition — come back and we can re-evaluate."
Don't try to upsell the decline. A decline that pivots into a sales pitch reads as bait-and-switch. The decline is the conversation.
Done well, prospects you decline become referrers. They tell other people about the MSP who told them "no" honestly.
Common mistakes when declining
- Saying yes to win the deal, planning to fix it later. The fix rarely happens; the engagement becomes a slow drag on margin.
- Declining without a recommendation. Leaves the prospect feeling dismissed. Always offer an alternative path, even if it's "build internal capability."
- Declining with too much technical detail. The prospect doesn't need the full reasoning; they need the conclusion and one or two specific reasons.
- Refusing to refer to a competitor. Sometimes a competitor is the right fit. Saying so builds trust; refusing to do so reads as territorial.
Step-by-step qualification
A qualification checklist that catches most of the bad fits before contract:
- Domain count and shape. One domain, low send volume → probably project work, not managed service.
- In-house team strength. Strong internal team → expertise retainer, not managed service.
- Domain change cadence. High M&A or sub-domain volume → scope-around-change model, not steady-state.
- DNS provider capability. Low-tier provider → surcharge or DNS migration discussion.
- Stakeholder availability. Sales contact ≠ operational contact → fix in sales cycle or decline.
- Authentication-compatible senders. Locked into platforms that can't authenticate → monitoring-only honestly, not enforcement promise.
- Budget realism. Aggressive negotiation on all line items → either hold price firmly or offer self-serve tier.
If three or more flags trip, the engagement is high-risk. Two flags is workable with a different model. Zero or one is a clean fit.
Best practices
- Build the bad-fit profiles into your sales process. Trained sellers spot the signs faster than fresh-eyes does.
- Have a "no" SKU ready. Project work, expertise retainer, self-serve monitoring — alternatives to the managed service.
- Track decline reasons. The pattern of why you decline is data about your target market.
- Practice the decline conversation. It's a sales skill; it improves with repetition.
- Refer to competitors when honest. Sometimes the alternative is another MSP. The referral builds your reputation.
- Revisit declined prospects yearly. Situations change; the decline isn't permanent.
Recommended next step
Audit your current client list. Are there one or two clients who match a bad-fit profile? They may not need to be offboarded (mid-engagement scope conversion is hard) but they should be flagged so the next renewal cycle is a real decision, not an automatic one. For new prospects, run the qualification checklist before quoting.
FAQ
Doesn't declining work hurt revenue?
In the short term, yes. In the medium term, declining bad-fit work raises the average profitability of the engagements you do take. The MSPs with the strongest practices are usually the ones with the highest decline rate, not the lowest.
What if the prospect is offended by the decline?
The framing matters. "We don't think this is the right fit" is better than "you're not a good client." Honest framing with a recommendation rarely produces real offense.
Should I decline if my pipeline is dry?
Tactically, sometimes you take the work to fill capacity. Strategically, even then, take it knowing what you're taking. A capacity-filler engagement that grows into a long-term relationship is fine; a capacity-filler that consumes operational time forever is not.
What about referring to a competitor?
If the competitor is genuinely the right fit, refer. The referral builds reputation. The world is bigger than the deals between you and one competitor.
How do I know when a client has shifted into a bad-fit profile?
Their engagement starts showing the warning signs from the profiles above. M&A activity picks up; the operational contact stops responding; the recurring work no longer fits the contract. The annual SOW renewal is the time to recognize and address.
Can I convert a bad-fit engagement into a good-fit one?
Sometimes. The micro-client might grow into a real client; the chaotic-M&A client might mature; the no-engagement client might get a new champion. Watch for the inflection.
Final thoughts
The honest take on DMARC-as-a-service is that the model has clear fits and clear non-fits. Spending energy on the fits is what makes the practice profitable; spending energy on the non-fits is what makes it unprofitable.
Saying no is not a failure of the service model. It's how the service model survives.