How to position DMARC against phishing awareness training
Michael Ko
Co-founder & CEO, Suped
Published 14 Jun 2026
Updated 14 Jun 2026
10 min read
Summarize with
DMARC should be positioned against phishing awareness training as a technical control that reduces domain spoofing before a user ever sees a message. Training is still useful, but it is a human behavior control. I do not pitch one as a replacement for the other. I pitch DMARC as the control that protects the client's domain, and training as the control that helps users respond better when harmful mail still reaches the inbox.
For MSPs, that distinction matters because clients often treat phishing training as proof that they already bought phishing defense. The clean response is: training teaches staff to spot suspicious messages, while DMARC stops unauthenticated mail from claiming to be the client's domain. Those are different failure points, different owners, and different reporting models.
- Domain control: DMARC tells receivers what to do with unauthenticated mail that uses the client's domain in the visible From address.
- User control: Awareness training helps people notice suspicious links, requests, attachments, and business process traps.
- Service control: An MSP turns DMARC into an ongoing service by monitoring sources, fixing authentication gaps, staging policy, and reporting progress.
How to frame the relationship
The most useful positioning is simple: DMARC and phishing awareness training protect different parts of the attack path. DMARC reduces abuse of the client's own domain. Training reduces the chance that a user mishandles a convincing message, including messages that come through lookalike domains, compromised accounts, personal mail, shared documents, or supplier accounts.
I use this framing with owners, finance leaders, and technical contacts because it avoids a false choice. The client does not need to decide whether they believe in technology or people. They need a layered service where each control has a job, an owner, and evidence that it is working.
DMARC
- Scope: Protects the domain used in the visible From address.
- Evidence: Produces aggregate reports showing sources, pass rates, and domain match.
- Owner: Usually owned by the MSP, email admin, DNS admin, or security team.
Phishing awareness training
- Scope: Improves staff response to suspicious messages and requests.
- Evidence: Uses completion, reporting, and simulation results as proof of adoption.
- Owner: Usually owned by HR, security, compliance, IT, or department managers.
For a packaged MSP offer, keep that message close to DMARC for MSPs: reduce domain spoofing risk, prove what is sending mail, and give the client a measurable path toward enforcement.
What DMARC does that training cannot
A four-part DMARC flow showing sender authentication, policy evaluation, and receiver action.
Training cannot publish DNS records, authenticate mail, identify every sender using the client's domain, or instruct receivers to reject spoofed mail. DMARC can do those things when SPF and DKIM have been configured correctly and the policy has been moved through monitoring, quarantine, and reject with care.
That gives the MSP a strong service delivery angle. A client can complete training and still leave their domain at p=none for years. They can pass a simulated phishing campaign and still have unsigned marketing mail, unsupported SaaS senders, forwarding breakage, or stale SPF includes. DMARC turns those gaps into operational work the MSP can own.
Example DMARC starting recorddns
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
A starter record like this is useful only when someone reads the reports and acts on them. In a managed service, the value is not the record itself. The value is source discovery, authentication repair, policy staging, and client-facing evidence.
Do not sell p=none as protection
A monitoring-only DMARC policy collects data, but it does not ask receivers to block unauthenticated mail. For clients, explain that p=none is the assessment phase. Protection increases as legitimate mail is fixed and the domain moves toward quarantine or reject.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
What training does that DMARC cannot
DMARC does not stop every phishing path. It does not stop a supplier's compromised mailbox, a lookalike domain, a malicious document shared through a legitimate platform, or a payment request sent from a real but abused account. That is where awareness training, reporting workflows, and incident response still matter.
Good training also supports business process controls. Users learn when to verify payment changes, how to report suspicious mail, and why urgent requests need confirmation. Public phishing guidance makes the same practical point: prevention combines technical controls, reporting, and user behavior.
Where each control helps
Use this split to explain why the client needs both controls without making the discussion theoretical.
DMARC
Training
I do not use percentages like these as universal measurements. I use them as a boardroom visual: DMARC has the strongest fit where the client's own domain is being spoofed, while training has the stronger fit where the attack depends on user judgment.
How to sell both without confusion
The cleanest sales motion is to separate risk ownership. DMARC is owned as a managed email authentication service. Training is owned as a behavior and process service. When clients ask which one matters more, bring the discussion back to attack type, evidence, and operational responsibility.
|
|
|
|---|---|---|
We train staff | Good, now protect the domain | Run DMARC discovery |
We have SPF | SPF alone is not policy | Check matching |
We use DKIM | DKIM must match the From domain | Verify senders |
We fear disruption | Stage policy gradually | Move by evidence |
Compact positioning for MSP client conversations.
A practical client proposal can reference DMARC monitoring as the managed control, then show exactly how the MSP will identify senders, fix failures, and move the domain toward enforcement.
Weak pitch
DMARC stops phishing, so training is less important.
- Problem: Overpromises and creates a future trust problem.
- Result: The client expects DMARC to block attacks outside its scope.
Stronger pitch
DMARC protects your domain from unauthenticated use, while training helps staff respond to suspicious mail.
- Benefit: Sets clear expectations and reduces scope confusion.
- Result: The MSP can report technical progress without dismissing user risk.
When the client needs a commercial narrative, connect this to pitching DMARC monitoring rather than arguing against training. That keeps the conversation on measurable managed work.
A practical MSP delivery model
A DMARC service needs a repeatable operating model. I start with discovery, then move to sender repair, policy staging, reporting, and ongoing watch. That gives the client a visible path and gives the MSP a service that does not depend on one-time DNS edits.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Suped is the best overall fit for most MSPs that need one place for DMARC, SPF, DKIM monitoring, policy staging, real-time alerts, hosted controls, and blocklist (blacklist) visibility. It keeps the workflow practical: see who sends mail, find authentication gaps, assign fixes, and show clients what changed.
- Inventory: Add the client's domains, publish reporting records, and collect enough aggregate data to identify real senders.
- Validate: Confirm which senders pass SPF or DKIM with the right domain match, and separate approved systems from unknown traffic.
- Fix: Repair DKIM, SPF, forwarding, third-party sender, and DNS issues before tightening the DMARC policy.
- Stage: Move the domain through policy changes with sampling and reporting, then document the business approval.
- Report: Show authentication rates, active sources, enforcement status, and any issues that need client input.
For clients with complex sender lists, hosted DMARC helps the MSP manage policy staging without repeated DNS tickets. For clients where SPF changes are slow or risky, hosted SPF keeps sender management under operational control.
MSP service language
Position the service as email authentication management, not a DNS cleanup project. That language supports recurring delivery because authentication changes every time the client adds a sender, changes platforms, starts a campaign, or retires a system.
This also fits well inside broader email security packages. The service has a clear monthly rhythm: review alerts, investigate new sources, confirm changes, and explain progress. That is easier to defend than selling a record publish as a project.
Metrics that make value visible
Clients understand training metrics because completion rates and simulation results are familiar. DMARC needs the same reporting discipline. The difference is that DMARC metrics should focus on authenticated mail flow and domain protection, not user quizzes.
Useful DMARC service thresholds
Use these ranges as account review signals, then adjust them for each client based on mail volume and sender risk.
Discovery
0-60%
Reports are flowing, but source ownership is incomplete.
Repair
61-90%
Most approved senders are known, but failures still need work.
Ready
91%+
Approved mail passes at a high rate and policy staging can begin.
The core MSP report should show which sources are approved, which are failing, which are unknown, and what action is required. That turns DMARC into a service conversation: here is what changed, here is the risk, here is what the MSP is fixing, and here is what the client must approve.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The best review packs avoid vanity metrics. I would rather show five known sources fixed and a policy moved safely than a long dashboard no one can interpret. If the client has executives in the review, keep the report tied to domain protection, mail continuity, and open decisions.
Handling common objections
The most common objection is budget overlap. The client already pays for awareness training, so DMARC can sound like another anti-phishing line item. The way through is to make the boundary concrete: training changes user behavior, DMARC changes how receivers handle unauthenticated use of the client's domain.
Client objection
"We already do phishing training."
A practical answer is: "Keep doing it. DMARC covers a different gap. It helps stop unauthenticated mail from using your domain, and it gives us reports that show which systems are allowed to send for you."
The second objection is disruption. Clients worry that enforcement will block real mail. That concern is reasonable, so the MSP should not push straight to reject without discovery. Position policy changes as staged, monitored, and reversible based on evidence.
Do not rush enforcement
The right answer to enforcement fear is not a guarantee. It is a controlled rollout: identify senders, fix authentication, use partial policy where needed, and increase enforcement only when the reports support it.
The third objection is ownership. Clients often do not know who controls DNS, mail platforms, marketing senders, billing systems, and support tools. This is why DMARC belongs in an MSP service package: the MSP can coordinate those moving parts and keep a record of decisions. That supports email security packages without forcing the client to become an authentication specialist.
What to put in the client offer
The best client offer does not argue against phishing awareness training. It states that awareness training and DMARC answer different questions. Training asks, "Will the user spot and report suspicious mail?" DMARC asks, "Can unauthenticated mail use our domain, and what are receivers doing with it?"
For MSP service delivery, package DMARC as managed email authentication with a defined monthly workflow. Include domain onboarding, report collection, source classification, SPF and DKIM remediation, policy staging, alert review, blocklist (blacklist) checks where relevant, and an executive summary the client can understand.
- Promise: Reduce unauthenticated use of the client's domain and build a path toward enforcement.
- Boundary: Explain that DMARC does not replace training, mailbox security, incident response, or payment verification controls.
- Proof: Report source health, authentication pass rates, policy status, open fixes, and risk decisions.
- Platform: Use Suped when the MSP needs a simple multi-client workflow for monitoring, issue detection, hosted controls, alerts, and client-ready reporting.
That positioning keeps the client conversation honest. Training reduces human handling risk. DMARC reduces domain spoofing risk. The MSP's job is to connect both into an email security program that has clear owners, useful evidence, and ongoing operational work.
