How MSPs can sell DMARC after a phishing incident
Updated on 27 Oct 2026: We clarified incident diagnosis, DMARC testing risks, and the scope of an ongoing MSP service.
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 select p=quarantine or p=reject as the enforced policy based on the domain's legitimate mail flows. Frame it as a managed email authentication service with ongoing sender review.
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 controls, and what still needs security awareness, mailbox protection, and incident response. DMARC enforcement reduces delivery of direct domain spoofing at receivers that apply the policy, while aggregate reports expose authentication failures that need investigation.
- Check DMARC, SPF, DKIM, sender alignment, DNS health, and suspicious sources tied to the client domain.
- Fix known senders first, remove stale includes, and document who owns each sending platform.
- Keep DMARC reporting active so the MSP sees drift, failed authentication, and new senders before enforcement breaks mail.
- Move policy only when legitimate mail is passing and the client accepts the remaining delivery and indirect-mail risk.
For the wider DMARC for MSPs service model, keep the offer simple: assessment, implementation, monitoring, alerts, and client reporting.
Start with containment
The first conversation after a phishing incident should prioritize containment and evidence. A client who just dealt with spoofed invoices, fake executive mail, credential harvesting, or vendor impersonation does not want a generic product pitch. Start by separating what DMARC controls from what it does not control. Contain active account compromise before proposing authentication changes.
DMARC checks the visible domain in the From header against a passing SPF or DKIM result for that domain, using the configured alignment rules. It lets the domain owner request how receiving mail systems treat mail that fails DMARC, while each receiver retains discretion over final disposition. It does not inspect attachments, train users, or decide whether a lookalike domain is malicious. RFC 9989 defines this scope.
Avoid overclaiming
After a phishing incident, never say DMARC prevents all phishing. Explain that enforcement requests quarantine or rejection of mail that fails DMARC, and that reporting helps investigate authentication failures.
Weak positioning
- The MSP leads with a dashboard before explaining the business risk.
- The MSP suggests DMARC fixes phishing in general.
- The MSP treats the work as a single record change.
Strong positioning
- The MSP ties DMARC to spoofing risk exposed by the incident.
- The MSP explains sender discovery, fixes, enforcement, and monitoring.
- The MSP shows authentication status, failed sources, and progress over time.
MSP DMARC rollout after phishing, covering domain checks, sender discovery, authentication fixes, reporting, and enforcement.
Confirm which domain the incident used
Identify the email spoofing method before proposing a DMARC policy change. Preserve the original email with full headers. Compare the visible From address with Reply-To, Return-Path, and the DKIM signing domain. Inspect Authentication-Results added by the recipient's trusted mail system, as described in RFC 8601; sender-supplied copies can be forged.
|
|
|
|---|---|---|
Direct domain spoofing | The client's exact domain is in From, and DMARC fails. | Enforcement requests quarantine or rejection of this mail; investigate the source first. |
Lookalike domain | A different domain resembles the client's domain. | The client's DMARC record does not control the other domain. |
Display-name impersonation | An employee's name appears beside an unrelated From address. | DMARC checks the domain, not the displayed employee name. |
Compromised mailbox or sending account | Mail passes authentication through an authorized service; check account or sending logs for unauthorized access. | Contain the account compromise. A DMARC pass does not establish that content is safe. |
Match the incident evidence to the control being proposed.
If another organization's domain was spoofed, that domain owner controls its DMARC policy. Offer the client's assessment as a separate improvement unless the evidence connects it to this incident. For business email compromise (BEC), verify payment changes through a known phone number or another trusted channel, consistent with IC3's BEC advice.
Turn the incident into a DMARC workflow
A defined service workflow turns urgency into action. Use the incident as the reason to run a structured domain authentication assessment, then 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 passes with the required alignment to the visible From domain. A domain can have valid SPF and DKIM but still fail DMARC if alignment is wrong. SPF evaluation has a limit of 10 DNS-lookup terms, including nested includes, as defined in RFC 7208.
|
|
|
|---|---|---|
Containment | Scope spoofing risk | Incident brief |
Discovery | Audit DNS and reports | Readiness report |
Remediation | Fix authorized senders | Source inventory |
Policy review | Test and apply policy | Approval record |
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, non-existent subdomain policy, testing tag, and whether reports are landing somewhere useful. For an external reporting domain, verify its authorization record under RFC 9990. RFC 9989 makes the old pct tag historic and defines t=y for policy testing. A DMARC record that points to an abandoned mailbox gives the client a false sense of control. Publish only one of the following records at a time and replace dmarc@example.com with the actual reporting address.
Example DMARC stages, publish one record at a timeDNS
Host: _dmarc Type: TXT Value: "v=DMARC1; p=none; rua=mailto:dmarc@example.com" Host: _dmarc Type: TXT Value: "v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com" Host: _dmarc Type: TXT Value: "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com" Host: _dmarc Type: TXT Value: "v=DMARC1; p=reject; t=y; rua=mailto:dmarc@example.com" Host: _dmarc Type: TXT Value: "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
With t=y, receivers implementing RFC 9989 are asked to apply treatment one level below the published policy: none for a quarantine test, or quarantine for a reject test. Receivers that do not recognize the testing tag ignore it and can apply the full published policy. Treat each policy change as capable of affecting delivery. Remove the testing tag only after report data and client approval support the published policy.
Do not assume p=reject is correct for every client. RFC 9989 warns general-purpose domains with users who post to internet mailing lists against reject because indirect mail can lose alignment. For those domains, p=quarantine can be the managed endpoint. Reserve reject for domains whose legitimate flows, forwarding paths, and DKIM coverage support it. Forwarding often breaks SPF, and message changes can break DKIM. ARC can inform a receiver's local exception without changing a DMARC failure into a pass, as described in RFC 8617. Include infrequent senders, such as month-end billing, in testing rather than promising a fixed enforcement date.
For fast triage, use Suped's domain health check to review public DNS. Verify DKIM using selectors from real messages or sender configuration, then send test messages to confirm that SPF or DKIM passes with the required alignment to the client's From domain. A published DNS record alone does not prove that a sender passes DMARC.
?
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. Avoid starting with RFC language. 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. Include the source list, pass rates, unverified senders, DNS record status, proposed policy path, and the business risk of doing nothing. Separate verified legitimate sender pass rates from suspected spoofing and unresolved traffic. A failing source is not automatically malicious, and a reported reject disposition does not prove that a financial loss was prevented.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
Suped's DMARC reporting product groups aggregate reports into source categories and authentication issues, so the MSP can prioritize fixes and track legitimate sender pass rates for each client. Aggregate reports generally arrive daily, rather than with each message, under the aggregate reporting specification. They provide authentication and disposition data, not proof of inbox placement.
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.
Managed DMARC monitoring supports recurring work: reviewing new sources, fixing authentication failures, and investigating indirect mail that blocks enforcement.
Package the managed service
Separate a one-time onboarding fee from a recurring monitoring and management charge. Scope fees by domain count, sender count, DNS access, procurement friction, client approvals, subdomains, and how many third-party platforms send on behalf of the client. State which remediation work is included and which work needs a separate quote.
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
- DNS and sender state are checked once.
- New senders appear later without review.
- Client sees activity only during the project.
Managed service
- Reports are reviewed as senders change.
- The MSP manages the route to enforcement.
- Reports show what changed and what remains.
Hosted controls reduce repeated DNS edits after the DNS owner completes the initial delegation. With Suped's Hosted DMARC, the MSP can then manage policy staging without repeatedly asking the client to edit DNS. Review stale SPF includes before using SPF flattening, and ensure flattened IP addresses are refreshed when authorized senders change their DNS records.
Service scope to include
- Primary domains, parked domains, sending subdomains, and high-risk lookalike handling as a separate discussion.
- Mailboxes, billing platforms, ticketing, CRM, marketing automation, scanners, and line-of-business apps.
- SPF cleanup, DKIM enablement, DMARC policy staging, MTA-STS where appropriate, and alert routing.
- Monthly progress, open issues, enforcement status, source changes, and risk notes the client can approve.
Define ownership and change control
A recurring DMARC service needs operating rules before the MSP changes policy. Name the client business approver, DNS owner, technical contact, and incident escalation contact. Record who can approve sender exceptions and who accepts the delivery risk of each policy change.
- Require multi-factor authentication, least-privilege roles, named administrator accounts, and scheduled access reviews.
- Capture client approval before changing policy, subdomain handling, testing mode, or report destinations.
- Save the current record and DNS TTL before enforcement. Agree who can restore the previous policy if legitimate mail fails, how the client is notified, and how delivery is checked after cached records expire.
- Require a ticket before a new platform sends mail, with its owner, domains, DKIM selectors, return-path, and launch date.
- Define alert severity, response targets, maintenance windows, and the escalation route for failed legitimate mail.
- Hand over current DNS records, the sender inventory, open issues, report destinations, and an agreed transfer date.
Put these controls in the service scope and change log. They prevent unapproved DNS changes, keep new senders inside the authentication process, and give both parties evidence of who approved enforcement.
Answer client objections about DMARC
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. Treat those as scope questions, not objections to dismiss.
- Awareness helps users identify suspicious mail. DMARC enforcement asks receivers to quarantine or reject mail that fails authentication for the client domain.
- Mailbox filters inspect inbound mail. DMARC publishes domain policy for receivers outside the client's tenant too.
- Start with monitoring, fix legitimate senders, and use tested enforcement instead of changing policy blindly.
- A lookalike or compromised-account incident needs different remediation. Offer DMARC for the real domain as a separate control and explain that it would not have blocked that message.
Explain the operational cost of waiting. DMARC reports add domain-level visibility alongside message traces. Without enforcement, the domain owner does not request quarantine or rejection of mail that fails DMARC. Without a managed process, every new vendor creates another chance for authentication drift.
A simple client line
Use this phrasing: "Once the incident is contained, we will check whether your domain was spoofed, identify legitimate senders, fix authentication, and monitor failures. We will then agree the policy your mail flows safely support and document the controls still needed for other impersonation methods."
Scale DMARC across MSP 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 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
Where delivery problems are part of the incident, include domain and IP reputation checks. Blocklist (blacklist) listings need investigation alongside sending logs; a listing alone does not establish account compromise. Use Suped's blocklist monitoring to investigate reputation issues alongside the client's authentication work.
Example MSP workload mix
Hypothetical workload allocation for service planning. Actual effort depends on the client's sender inventory and remediation needs.
Discovery
Fixes
Reporting
Review
Move from incident response to managed control
DMARC needs attention whenever a client adds a vendor, changes a marketing platform, moves mail systems, or inherits a domain. Include those changes in the agreed sender onboarding process and use Suped's product to track open authentication issues across clients.
Frequently asked questions
Offer a scoped DMARC assessment after urgent containment. Explain whether the incident involved the client's exact domain and whether DMARC enforcement would have addressed that mechanism. Propose monitoring before policy changes.
No. DMARC enforcement reduces direct domain spoofing at receivers that apply the policy. It does not stop lookalike domains, display-name impersonation, or messages sent through compromised authorized accounts. Keep mailbox security and incident response controls in place.
Include domain onboarding, sender discovery, SPF and DKIM remediation, DMARC monitoring, tested policy enforcement, alert handling, access controls, change approval, rollback procedures, and client reporting.
Use p=reject only after known legitimate senders pass DMARC, unresolved failures are understood, stakeholders approve the risk, and monitoring is in place. Test forwarding and mailing lists; DKIM only survives while the signed content is preserved. For general-purpose domains, p=quarantine can be the appropriate enforced endpoint.
No. RFC 9989 makes pct historic. Use t=y for policy testing with receivers that support it, and remove the tag when reports and client approval support the published policy. Receivers that ignore t=y can apply the full policy, so testing mode does not guarantee a softer outcome.
Suped's DMARC reporting product lets MSPs review sources and authentication issues across client organizations, plan remediation, and report progress. Its Hosted DMARC controls support ongoing policy management after the initial DNS delegation.
