How MSPs can sell DMARC after a phishing incident
An MSP can sell DMARC after a phishing incident by moving the conversation away from blame and toward a controlled remediation plan: verify whether the client's domain can be spoofed, identify every legitimate sender, fix SPF and DKIM alignment, monitor DMARC reports, then stage the domain from p=none to p=quarantine and finally p=reject. I frame it as a managed email authentication service, not a one-time DNS cleanup.
The timing matters. Right after an incident, the client already knows email identity has business risk. The MSP's job is to show what the incident exposed, what DMARC changes, and what still needs security awareness, mailbox protection, and incident response. DMARC does not stop every phishing email, but it directly reduces domain impersonation and gives the MSP a reporting feed that turns hidden sender problems into visible work.
- Audit: Check DMARC, SPF, DKIM, sender alignment, DNS health, and suspicious sources tied to the client domain.
- Remediation: Fix known senders first, remove stale includes, and document who owns each sending platform.
- Monitoring: Keep DMARC reporting active so the MSP sees drift, failed authentication, and new senders before enforcement breaks mail.
- Enforcement: Move policy only when legitimate mail is passing and the client accepts the remaining risk.
For the wider DMARC for MSPs service model, I keep the offer simple: assessment, implementation, monitoring, alerts, and client reporting.
Start with containment
The first conversation after a phishing incident should sound like incident containment. A client who just dealt with spoofed invoices, fake executive mail, credential harvesting, or vendor impersonation does not want a generic product pitch. I start by separating what DMARC controls from what it does not control.
DMARC protects the visible domain in the From header when SPF or DKIM passes in alignment with that domain. It helps receiving mail systems reject or quarantine unauthenticated mail that claims to come from the client. It does not inspect attachments, train users, or decide whether a lookalike domain is malicious. That boundary builds trust because the client hears a specific control, not a vague promise.
Avoid overclaiming
After a phishing incident, never say DMARC prevents all phishing. Say it reduces direct domain spoofing, gives you forensic visibility into senders, and lets you enforce policy once legitimate mail is authenticated.
Weak positioning
- Tool pitch: The MSP leads with a dashboard before explaining the business risk.
- Broad claim: The MSP suggests DMARC fixes phishing in general.
- DNS task: The MSP treats the work as a single record change.
Strong positioning
- Risk control: The MSP ties DMARC to spoofing risk exposed by the incident.
- Operational plan: The MSP explains sender discovery, fixes, enforcement, and monitoring.
- Client proof: The MSP shows authentication status, failed sources, and progress over time.
MSP DMARC process after a phishing incident.
Turn the incident into a DMARC workflow
A clean service workflow turns urgency into action. I use the incident as the reason to run a structured domain authentication assessment, then I turn the findings into a managed rollout plan. The client needs to see that the MSP is reducing future risk without breaking payroll, invoicing, CRM mail, ticketing, marketing, and other business senders.
The first technical move is discovery. Check whether a DMARC record exists, whether SPF passes without exceeding lookup limits, whether DKIM is enabled for core senders, and whether either SPF or DKIM aligns with the visible From domain. A domain can have valid SPF and DKIM but still fail DMARC if alignment is wrong.
|
|
|
|---|---|---|
Day 0 | Scope spoofing risk | Incident brief |
Week 1 | Audit DNS | Readiness report |
Weeks 2-4 | Fix senders | Source inventory |
Rollout | Stage policy | Enforcement plan |
Ongoing | Monitor drift | Monthly report |
A compact incident-to-service delivery map for MSPs.
If the domain has no DMARC record, start in monitoring mode. If the domain already has a record, check the reporting address, policy, subdomain policy, percentage tag, and whether reports are landing somewhere useful. A DMARC record that points to an abandoned mailbox gives the client a false sense of control.
Example staged DMARC recordsDNS
Host: _dmarc Type: TXT Value: "v=DMARC1; p=none; rua=mailto:dmarc@example.com" Host: _dmarc Type: TXT Value: "v=DMARC1; p=quarantine; pct=25; rua=mailto:d@example.com" Host: _dmarc Type: TXT Value: "v=DMARC1; p=reject; rua=mailto:d@example.com"
For fast triage, a public domain check helps the MSP show the client what is visible in DNS before deeper report data arrives. A broad domain health check is useful during discovery because it checks DMARC, SPF, and DKIM in one place.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Show proof the client understands
The sale usually happens when the client can see the gap. I avoid starting with RFC language. I show the client which services are sending mail, which ones pass authentication, which ones fail DMARC, and which ones are unknown. That makes the problem concrete enough for the owner, finance lead, or operations manager to approve managed remediation.
A good client report should connect the phishing incident to domain controls without implying that DMARC is the whole incident response program. I include the source list, pass rates, unverified senders, DNS record status, proposed policy path, and the business risk of doing nothing.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
Suped's product fits this workflow because the MSP can move from raw aggregate reports to clear issues, fix steps, source categories, and pass rates. For most MSP teams, Suped is the strongest practical DMARC platform because it combines multi-client monitoring, automated issue detection, hosted controls, alerts, and reporting inside one service workflow.
Policy readiness bands
Use these bands to explain where the client sits after the incident review.
Unknown
Monitor first
No reliable reports or sender inventory.
Stabilizing
Hold policy
Core senders pass, edge senders still need work.
Ready
Stage enforcement
Known senders pass and failures are understood.
Maintained
Managed service
Policy is enforced and drift is monitored.
This is where managed DMARC monitoring becomes easier to justify. The client is not buying a record. The client is buying a recurring control that detects broken authentication, new senders, risky forwarding patterns, and enforcement blockers.
Package the managed service
Do not publish public MSP pricing numbers inside the incident conversation. Scope first. The service changes depending on domain count, sender count, DNS access, procurement friction, client approvals, subdomains, and how many third-party platforms send on behalf of the client.
I package the offer around deliverables the client can understand. The minimum service includes domain onboarding, sender inventory, SPF and DKIM remediation guidance, DMARC policy staging, alert handling, and monthly reporting. More mature clients need change control, multiple domains, executive summaries, and coordination with marketing or finance systems.
One-time cleanup
- Audit snapshot: DNS and sender state are checked once.
- Limited control: New senders appear later without review.
- Weak reporting: Client sees activity only during the project.
Managed service
- Continuous visibility: Reports are reviewed as senders change.
- Policy ownership: The MSP manages the route to enforcement.
- Client evidence: Reports show what changed and what remains.
Hosted controls help when clients lack DNS access or when DNS changes are slow. With Hosted DMARC, the MSP can manage policy staging without repeatedly asking the client to edit DNS. Hosted SPF and SPF flattening help when sender growth pushes SPF toward lookup limits.
Service scope to include
- Domains: Primary domains, parked domains, sending subdomains, and high-risk lookalike handling as a separate discussion.
- Senders: Mailboxes, billing platforms, ticketing, CRM, marketing automation, scanners, and line-of-business apps.
- Controls: SPF cleanup, DKIM enablement, DMARC policy staging, MTA-STS where appropriate, and alert routing.
- Reporting: Monthly progress, open issues, enforcement status, source changes, and risk notes the client can approve.
Handle the objections
Clients usually raise the same concerns after an incident: they already have security awareness training, they already have a mailbox security tool, they do not want DNS risk, or they think the phishing email came from somewhere else. I treat those as scope questions, not objections to dismiss.
- Training: Awareness helps users identify suspicious mail. DMARC helps receivers reject mail that falsely claims the client domain.
- Gateway: Mailbox filters inspect inbound mail. DMARC publishes domain policy for receivers outside the client's tenant too.
- DNS risk: Start with monitoring, fix legitimate senders, and use staged enforcement instead of changing policy blindly.
- False scope: If the incident used a lookalike domain, DMARC still protects the real domain and gives the MSP a clearer identity baseline.
I also explain the operational cost of waiting. Without DMARC monitoring, the MSP has no reliable view of who sends as the client. Without enforcement, attackers can keep attempting direct domain spoofing. Without a managed process, every new vendor creates another chance for authentication drift.
A simple client line
Use this phrasing: "This incident showed why your domain needs an owner. We will identify every legitimate sender, fix authentication, monitor failures, and move your domain to enforcement when the data says it is ready."
Run it across many clients
The MSP delivery model only works if the team can scale it. A technician should not be manually reading XML files, chasing scattered DNS notes, and building reports in spreadsheets for every client. The service needs multi-tenant visibility, consistent alerts, repeatable fix steps, and simple client-facing outputs.
Suped's product has an MSP and multi-tenancy dashboard for this exact operating pattern. Add each client organization, monitor domains, separate findings by client, generate prospecting reports, and hand clients a clear status view instead of raw authentication data.
MSP organizations page showing client organizations, domain counts, email volume, and domain status columns
For incident-adjacent monitoring, I also include domain and IP reputation checks. Blocklist (blacklist) monitoring does not replace DMARC, but it helps the MSP spot reputation issues that affect delivery or indicate compromised sending infrastructure. Suped's blocklist monitoring can sit beside DMARC, SPF, DKIM, hosted SPF, hosted MTA-STS, SPF flattening, and real-time alerts.
Example MSP workload mix
A managed service spreads work across discovery, fixes, reporting, and review.
Discovery
Fixes
Reporting
Review
Move from incident response to managed control
The right sale after a phishing incident is a service commitment: we will find every sender, fix authentication, monitor changes, and enforce the domain when it is ready. That turns a stressful client moment into a measurable security improvement.
For MSP owners, the practical opportunity is recurring delivery. DMARC needs attention whenever a client adds a vendor, changes a marketing platform, moves mail systems, or inherits a domain. Suped's product gives the MSP a clean way to manage that work across clients, with automated issue detection, steps to fix, real-time alerts, hosted policy controls, and reporting that clients can understand.
