How to position DMARC against phishing awareness training
Updated on 22 Oct 2026: We clarified how DMARC protects customers and suppliers alongside staff training, with more precise MSP reporting guidance.
DMARC should be positioned alongside phishing awareness training as a technical control that helps receivers reject or quarantine unauthenticated mail using the client's domain when enforcement is enabled. Training 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 DMARC checks. 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 explain DMARC alongside phishing awareness training
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 teaches users to question and report convincing messages, 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: Checks whether SPF or DKIM passes with the required relationship to the visible From domain. A pass does not establish that the message is safe.
- 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: Tracks participation through completion and assesses response through reporting rates, time to report, and simulation results.
- 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, identify sources visible in aggregate reports, and give the client a measurable path toward enforcement.
How DMARC protects customers and suppliers
Staff training reaches the client's employees. DMARC enforcement can also help protect customers and suppliers receiving messages that misuse the client's domain, even when those recipients are outside the client's training program. Their receiving systems decide how to apply the published policy.
Consider a fake invoice sent to a customer with billing@example.com in the visible From address. If neither SPF nor DKIM passes with the required domain relationship, the message fails DMARC. A reject policy requests rejection at the customer's receiving system. This addresses exact-domain impersonation used in business email compromise (BEC). Fraud sent through a compromised, authenticated mailbox still requires payment verification.
Publishing the client's DMARC policy does not filter all mail arriving at that client. Separately confirm that its receiving system evaluates incoming authentication and applies its email security policy. NCSC's phishing guidance includes both domain protection and incoming filtering in a layered defense.
What DMARC does that training cannot
DMARC email authentication flow showing SPF or DKIM checks, domain policy, 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 evaluates SPF and DKIM results against the visible From domain. A message passes DMARC when at least one of those methods passes with the required domain relationship. 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. A low simulation click rate can coexist with approved senders that fail DMARC, forwarding failures, or stale SPF includes. Missing DKIM alone does not mean DMARC fails if SPF passes with the required domain relationship. 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 is the current DMARC specification and replaces RFC 7489. The legacy pct tag is historic 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 DMARC policy of p=none does not request quarantine or rejection for DMARC failures. Aggregate reports are requested separately through the rua tag, as in the example above. 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 to verify payment changes by calling a previously verified number, rather than a number supplied in the suspicious message, and to report urgent requests for confirmation. Pair these processes with phishing-resistant MFA to reduce credential-based account takeover. NCSC's phishing guidance makes the same practical point: phishing defense needs technical controls, user reporting, business process safeguards, and incident response.
|
|
|
|---|---|---|
Exact-domain spoofing | Checks SPF or DKIM alignment and publishes a handling preference for failures | Helps users report anything that still arrives |
Lookalike domain or display name | Can pass for an attacker's own domain; does not validate 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: Use authentication headers added by the receiving system and its message logs to investigate reports that claim to use the client's domain. Compare broader source patterns with DMARC data without assuming unknown sources are malicious.
- 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. They summarize traffic rather than identify individual messages, so use the reported message and receiving-system logs for incident triage. RFC 9990 defines aggregate reporting. Simulation results do not prove that DMARC works.
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 its multi-client reports to identify observed senders, investigate SPF and DKIM failures, and review policy status. Use those findings to assign fixes and explain changes to each client.
- Inventory: List the client's domains and subdomains, including parked or unused 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 SPF and DKIM settings for approved senders, and test forwarding and mailing-list flows before tightening the DMARC policy.
- Stage: Document business approval before each policy change. Schedule a change window, monitor authentication and delivery, and retain a rollback plan.
- 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.
How to measure DMARC and training separately
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 passes DMARC, 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. Measure DMARC pass rates for approved mail separately from suspected spoofing traffic. A change in attack volume can distort a combined pass rate, and a DMARC failure count is not a count of attacks blocked.
For training, compare simulation click and reporting rates in the context of message difficulty and recipient roles. NIST's research on simulation difficulty explains why raw click rates need context. Track time to report alongside the MSP's time to triage reports, so users' reports lead to a defined response.
?
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, "Does SPF or DKIM pass with the required relationship to 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, 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 and client reporting for this workflow.
