How MSPs sell DMARC to small business clients

Evidence to collect

Collect enough evidence to make the first conversation specific. A prospect's public DNS records can reveal whether DMARC is published, but they cannot show whether a marketing platform, accounting application, help desk, or line-of-business system is using the intended authentication path.

Use the DMARC checker to inspect a prospect's public DMARC record before discussing the result. Frame it accurately: a public check can identify the published record and obvious gaps, but it does not prove the production sending path, continuous state, a mailbox provider's private decision, or future inbox placement.

Palisade documents white-label prospection reports that can be branded, configured for an audience, and downloaded as PDFs. Its documented report content includes an overall score, risk summary, spoofing-risk analysis, financial-loss estimate, brand-and-trust impact, and a glossary. Palisade's prospection-report guide also describes a sales use case involving no DMARC policy, an overly permissive SPF record, and no DKIM signing.

Record the initial assessment in a portable client record:

client: example-accounting-firm
domain: yourdomain.com
evidence: public DMARC record check and client sender inventory
owner: MSP service manager
next_action: client confirms marketing, billing, support, and payroll senders
review_on: 2026-12-01

The sales discovery should also ask for:

• The domains used in visible From addresses.
• Known marketing, CRM, billing, support, payroll, and application senders.
• The person authorized to approve DNS and policy changes.
• The DNS provider and change owner.
• Typical sending volumes and the mailbox providers that receive important mail.
• Seasonal campaigns, invoices, or other low-frequency sending paths.
• Existing SPF, DKIM, and DMARC evidence from real delivered messages where available.

Do not present a missing DMARC record as proof that all client email is failing. It is a public posture finding that needs sender inventory and message evidence before a remediation plan.

How to run the workflow

1. Produce a prospect posture brief

Owner: MSP sales or security lead. Input: Prospect domain and public DNS results. Output: A client-specific brief that separates observed facts from open questions.

Lead with what the MSP can verify publicly. For example, a domain with no DMARC record has no published DMARC policy for that organizational domain. Do not turn that finding into an unproven delivery or breach claim.

State the next evidence needed: the client's sending inventory and delivered-message headers. This keeps the conversation useful for a small business that has several vendors but no centralized email-authentication documentation.

2. Explain the relevant provider requirements

Owner: MSP technical lead. Input: The client's sending volume and recipient destinations. Output: A requirement map marked as confirmed, possible, or not applicable.

Google says all senders to personal Gmail accounts must set up SPF or DKIM. Senders that send more than 5,000 messages per day to Gmail accounts must set up SPF, DKIM, and DMARC, and Google permits a DMARC policy of p=none. Google also states that unauthenticated messages might be marked as spam or rejected with 5.7.26. Google's email sender guidelines are the source for those requirements.

Yahoo's published bulk-sender guidance requires SPF, DKIM, a valid DMARC policy of at least p=none, DMARC passing, and alignment between the From domain and SPF or DKIM. Yahoo strongly recommends a properly configured rua tag during initial monitoring. Yahoo sender best practices also require bulk senders to keep spam rates below 0.3%, provide unsubscribe controls for marketing or subscribed messages, and honor unsubscribes within two days.

Microsoft's Outlook.com requirements apply to domains sending more than 5,000 emails daily. Microsoft requires passing SPF and DKIM plus DMARC at least p=none, aligned with SPF or DKIM. Microsoft stated that, after May 5, 2025, it would route high-volume non-compliant mail to Junk, while a future rejection date remained unannounced. Microsoft's Outlook sender-requirements announcement documents that scope and timeline. For the mechanics, Microsoft Learn's DMARC guidance for Microsoft 365 says a message passes DMARC when the SPF or DKIM check passes with an aligned domain, and recommends starting at p=none and monitoring reports before moving to quarantine or reject.

Do not say a small business is subject to a provider's high-volume rules until the client confirms its relevant volume and recipient mix.

3. Turn discovery into a scoped managed service

Owner: MSP account manager and technical owner. Input: The posture brief, sender inventory, and client priorities. Output: A written scope with deliverables, approval points, and exclusions.

Sell the recurring work that follows the initial assessment:

• Maintain a sender inventory with a named owner for every sending path.
• Review DMARC aggregate-report evidence as it accumulates.
• Create remediation tasks for authentication or alignment gaps.
• Coordinate with the client, DNS host, and sender platform owners.
• Prepare policy recommendations with evidence and rollback conditions.
• Report unresolved exceptions and decisions that need client approval.

For the underlying controls, a client may need email security priorities for small businesses, including work outside DMARC. Keep that discussion separate from the evidence required to change a DMARC policy.

4. Present policy progression as an approved decision

Owner: MSP technical owner, with client approver. Input: Sender evidence, open exceptions, and a proposed change. Output: An approved or deferred policy decision.

A monitoring policy such as p=none can support evidence collection, but it does not establish that every legitimate sender has been found. The MSP should document which senders are confirmed, which are unknown, which remediation items remain open, and what would trigger a rollback or pause.

Palisade's MSP page states that its agent finds senders, drafts SPF and DKIM fixes, and carries domains toward enforcement while the MSP approves every step. Palisade for managed service providers describes that approval boundary. Palisade can analyze DMARC aggregate-report data, identify sources and alignment issues, create prioritized remediation tickets, and propose a next policy stage. A human still reviews the evidence and applies the change.

5. Validate through the correct layers

Owner: MSP technical owner. Input: Published records, sender configuration, and delivered-message evidence. Output: A dated validation record and follow-up queue.

Validate each change at the layer it affects:

• DNS: Query the authoritative DNS provider and a public resolver after publication.
• Vendor: Confirm the sender platform's authentication or domain-verification status.
• Message: Inspect a real delivered message from the exact production path.
• DMARC: Review aggregate reports after enough reporting data accumulates.

Investigate this with your coding agent

Use this for a read-only prospect assessment when the client has authorized review of public DNS. Prepare only the prospect's domain list and a redacted evidence summary. Do not provide credentials, private keys, tokens, unredacted headers, or customer data.

Exceptions and escalation

Use an exception register when evidence does not support a safe recommendation. An unknown source is not automatically malicious, and a client statement that "we do not use that system" is not enough to close an observed sending path without follow-up evidence.

Escalate to the client when:

• No owner can confirm whether a sender is legitimate.
• A business-critical platform cannot provide an aligned SPF or DKIM path.
• DNS ownership is unclear.
• The client cannot provide a safe test window.
• A sender vendor controls a limitation that the MSP cannot change.
• Aggregate reports, public DNS, and delivered-message evidence conflict.

Reporting and success measures

Use a recurring client report that shows work and decisions rather than a single universal security score. A monthly operating review can include:

• Domains in scope and their current DMARC policy.
• Confirmed, unknown, retired, and pending senders.
• Open authentication or alignment remediation items by owner.
• Changes approved, applied, deferred, or rolled back.
• Exceptions without a client decision or review date.
• Evidence collected from DNS, sender platforms, messages, and DMARC reports.

Make the sales report the start of an operating queue

A branded prospecting report can open the conversation, but the recurring value is the work that follows: maintaining sender evidence, assigning remediation, and preparing approved policy decisions across client domains. Palisade's MSP offering describes multi-tenant functionality, white-label client reports, hosted authentication records, automatic SPF flattening, PSA integrations, API access, and client email volume that is not metered.

Palisade's MSP pricing is per active client domain, not per email, at the published rates on the MSP page, and new MSP accounts are billed for a minimum of five client domains. Those are platform rates, not a recommended resale price. An MSP's client price depends on its scope, onboarding work, support model, and approval responsibilities.

Book a demo to discuss how a prospecting report and approval-led DMARC workflow could fit your client portfolio. A demo does not prove a prospect's production mail flow, repair a sender, or authorize a DNS change.