How to position DMARC against phishing awareness training
Updated on 15 Aug 2026: We updated this guide for RFC 9989 and added a practical workflow for pairing DMARC evidence with phishing reporting and training.
DMARC should be positioned alongside phishing awareness training as a technical control that reduces unauthenticated use of the client's domain before a user sees a message. Training is still useful, but it is a human behavior control. Neither replaces the other. DMARC protects use of the client's domain, while training helps users respond 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 and report suspicious messages, while DMARC lets the domain owner publish a handling preference for mail that claims to use its domain but fails authentication and alignment. Those controls address different failure points and have different owners, evidence, and limits.
- Domain control: DMARC publishes the domain owner's requested handling for mail that fails DMARC checks against the domain in the visible From address. The receiver retains final discretion.
- User control: Awareness training helps people notice and report suspicious links, requests, attachments, display names, and business process traps.
- Service control: An MSP turns DMARC into an ongoing service by monitoring sources, fixing authentication gaps, staging policy changes, 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 unauthenticated use of the client's domain. Training reduces the chance that a user mishandles a convincing message, including mail sent through lookalike domains, misleading display names, compromised accounts, personal mail, shared documents, or supplier accounts.
Use this framing with owners, finance leaders, and technical contacts because it avoids a false choice. The client does not need to decide between technology and people. The client needs layered controls where each control has a defined job, an owner, and evidence that it is working.
DMARC
- Scope: Validates authorized use of the domain in the visible From address through SPF or DKIM alignment.
- Evidence: Uses aggregate reports from participating receivers to show observed sources, authentication results, and alignment.
- 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, time-to-report, and simulation results as evidence of behavior change.
- 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 exact-domain spoofing risk, prove which observed sources are 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, expose authentication patterns across participating receivers, or publish a requested policy for DMARC failures. DMARC does this when SPF or DKIM passes and the authenticated domain aligns with the domain in the visible From address. Aggregate reports help the MSP discover observed sources and authentication gaps, but they do not guarantee visibility into every message or sender.
That gives the MSP a strong service delivery angle. A client can complete training and still leave the domain at p=none for years. The client can pass a simulated phishing campaign and still have unsigned marketing mail, unsupported SaaS senders, forwarding failures, 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 comes from source discovery, authentication repair, controlled policy changes, and client-facing evidence.
RFC 9989 became the current DMARC protocol in May 2026 and replaced RFC 7489. It removed the old pct tag because receivers did not apply percentage sampling consistently. Stage enforcement with sender remediation, test domains or subdomain sequencing where appropriate, controlled change windows, and a rollback plan.
Do not sell p=none as protection
A monitoring-only DMARC policy requests reports but does not request quarantine or rejection for DMARC failures. For clients, explain that p=none is the assessment phase. Protection increases as legitimate mail is fixed and the published policy moves toward quarantine or reject, subject to each receiver's local policy.
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 validate a display name, block a lookalike domain, or detect malicious intent in an authenticated message. A supplier's compromised mailbox, a malicious document shared through a legitimate platform, or a payment request sent from a real but abused account can pass DMARC. That is where awareness training, reporting workflows, business process controls, and incident response still matter.
Good training also supports business process controls. Users learn when to verify payment changes through a separate channel, how to report suspicious mail, and why urgent requests need confirmation. Public phishing guidance makes the same practical point: phishing defense needs technical controls, user reporting, business process safeguards, and incident response.
|
|
|
|---|---|---|
Exact-domain spoofing | Validates aligned authentication and publishes a handling preference for failures | Helps users report anything that still arrives |
Lookalike domain or display name | Does not authenticate another domain or the display name | Builds domain-checking and reporting habits |
Compromised account | The message can pass when sent through an authorized account | Teaches users to question unusual context and requests |
Payment or data request | Does not verify the business request | Reinforces separate-channel verification and escalation |
Use this as a scope map, not a quantitative risk score.
Use this control map in client conversations instead of assigning universal percentages. DMARC has the strongest fit when unauthenticated mail uses the client's domain, while training has the stronger fit when the attack depends on user judgment or abuses an authenticated identity.
How to make the controls reinforce each other
The controls work best as separate evidence streams feeding one response process. DMARC aggregate reports expose observed sending sources and alignment outcomes. User reports expose lures that can pass DMARC, including lookalike domains, display-name impersonation, and compromised accounts. Neither stream describes the whole phishing problem.
- Route exact-domain reports: When users report mail that claims to use the client's domain, compare the message's authentication results with DMARC data and investigate unknown sources.
- Update role-based training: Use reported lookalike, supplier, payroll, or payment lures to refresh scenarios for the teams that face those requests.
- Keep metrics separate: Report DMARC policy and alignment health beside phishing report rate, time to report, and simulation outcomes. Do not merge them into one score.
- Remove blame: Make reporting quick and non-punitive so a user who clicked or replied still reports the incident without delay.
Keep the data boundaries clear
Aggregate DMARC reports contain authentication and source data, not the message body, its links, or proof that a user saw or clicked it. Simulation results do not prove that DMARC works. Give each data source a defined purpose in the client review.
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 DMARC | Check SPF alignment |
We use DKIM | DKIM needs the required From-domain relationship | Verify approved senders |
We fear disruption | Stage policy with a rollback plan | 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 observed sources, 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 reduces unauthenticated use of your domain, 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. Start with discovery, then move to sender repair, controlled policy changes, client reporting, and ongoing monitoring. 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 our DMARC and email authentication platform. MSPs can use it to manage multi-client DMARC, SPF, and DKIM monitoring, policy changes, alerts, hosted controls, and blocklist (blacklist) visibility in one workflow. The operational sequence is practical: identify observed senders, find authentication gaps, assign fixes, and show clients what changed.
- Inventory: Add the client's domains, publish reporting records, and collect aggregate data from participating receivers to identify observed senders.
- Validate: Confirm which approved senders pass SPF or DKIM with identifier alignment, 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 through controlled policy changes with change windows, monitoring, and a rollback plan, then document business approval.
- Report: Show alignment health, observed sources, enforcement status, and issues that need client input.
For clients with complex sender lists, hosted DMARC helps the MSP manage policy changes 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 when the client adds a sender, changes platforms, starts a campaign, or retires a system.
This fits 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 publication as a one-time project.
Metrics that make value visible
Clients understand training metrics because completion, reporting, time-to-report, and simulation results are familiar. DMARC needs the same reporting discipline, but its metrics should focus on authenticated mail flow and domain protection rather than user behavior.
DMARC enforcement readiness signals
Use operational evidence for each client instead of treating one pass-rate threshold as universal.
Discovery
Sources unknown
Aggregate reports are flowing, but unknown sources or ownership gaps remain.
Repair
Failures open
Approved senders are known, but alignment failures or indirect flows still need work.
Ready
Change approved
Approved mail aligns, owners have signed off, and the MSP has a monitored rollback plan.
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: what changed, what risk remains, what the MSP is fixing, and 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. Show known sources fixed and a policy changed safely instead of a long dashboard no one can interpret. For executive reviews, keep the report tied to domain protection, mail continuity, open decisions, and the next controlled change.
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. Make the boundary concrete: training changes user behavior, while DMARC changes how participating receivers evaluate 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 reduces unauthenticated use of your domain, and its reports show the sending sources visible to participating receivers so we can verify which systems are approved."
Another 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 controlled, monitored, approved, and backed by a rollback plan.
Do not rush enforcement
The right answer to enforcement fear is a controlled rollout: identify senders, fix authentication, use test domains or subdomain sequencing where appropriate, schedule the change, and keep a rollback path. Increase enforcement only when the reports and business owners support it.
Ownership is another objection. 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 client offer should not argue against phishing awareness training. It should state that awareness training and DMARC answer different questions. Training asks, "Will the user spot and report suspicious mail?" DMARC asks, "Can this message prove authorized use of our From domain, and what handling preference have we published for failures?"
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, controlled policy changes, 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 an evidence-based path toward enforcement.
- Boundary: Explain that DMARC does not replace training, mailbox security, incident response, payment verification controls, or protection against lookalike domains.
- Proof: Report observed source health, alignment results, policy status, open fixes, and risk decisions.
- Platform: Suped, our DMARC and email authentication platform, supports multi-client monitoring, issue detection, hosted controls, alerts, and client-ready reporting.
That positioning keeps the client conversation honest. Training reduces human handling risk. DMARC reduces unauthenticated domain use. The MSP's job is to connect both within an email security program with clear ownership and useful evidence for ongoing operational work.
