How to pitch DMARC to clients using Microsoft 365
Updated on 29 Oct 2026: We clarified Microsoft 365 sender validation and the checks required before DMARC enforcement.
Pitch DMARC to Microsoft 365 clients as a managed risk reduction project. The client already pays for Microsoft 365, but that does not mean every custom domain has an enforced DMARC policy or that every third-party sender authenticates correctly. Frame the pitch around a simple operational point: Microsoft 365 protects mailboxes, while DMARC lets the client publish how receivers should handle messages that fail authentication for its visible From domain.
For an MSP, the strongest pitch is practical: audit every sender, fix SPF and DKIM coverage, publish a DMARC record, monitor reports, move policy in stages, and turn the work into a repeatable service. That is why DMARC belongs in a DMARC for MSPs offer, especially for clients using Microsoft 365.
Client-facing pitch: Microsoft 365 handles a lot of email security, but DMARC is still controlled by your domain records and your sender behavior. We manage that for you, verify legitimate senders, and move the domain toward enforcement after testing valid mail.
Why Microsoft 365 clients still need DMARC
The most common objection is that the client already has Microsoft 365, Defender settings, and maybe DKIM enabled. That is useful, but it is not the whole job. Microsoft states that custom domain DMARC records are created at the domain registrar or DNS host, not managed through Microsoft 365 admin portals or PowerShell for custom domains. The Microsoft DMARC setup guidance also recommends a gradual path to p=reject. The exception is the tenant's *.onmicrosoft.com domain, whose DMARC TXT record can be added through the Microsoft 365 admin center.
Microsoft 365 admin center showing a custom domain and its DNS records.
- Control point: The DMARC policy is published in DNS for the client's domain, so someone must own record creation, staged changes, and review.
- Sender sprawl: Microsoft 365 is usually only one sender. Payroll, billing, CRM, support, marketing, scanners, and line-of-business apps often send too.
- Reporting gap: Raw DMARC XML is not a client-friendly report. The MSP needs summaries, source attribution, and issue tracking.
- Change risk: Moving directly to p=reject before identifying and fixing legitimate senders puts valid mail at risk of rejection.
What Microsoft 365 handles
- Mailbox security: Inbound filtering and spoof intelligence protect tenant mailboxes; advanced anti-phishing capabilities depend on licensing and configuration.
- Microsoft sending: SPF and DKIM can cover Microsoft 365 mail when configured correctly for the custom domain.
- Tenant visibility: Message trace and Defender views help investigate Microsoft-handled mail events.
What the MSP service handles
- Domain policy: DMARC TXT records, subdomain strategy, reporting addresses, and enforcement timing.
- Third-party senders: Discovery and fixes for every service sending as the client's brand outside Microsoft 365.
- Client reporting: Monthly progress, open issues, and evidence supporting the next policy change.
The pitch in one client conversation
Keep the meeting focused on business risk and service delivery. The client does not need a lecture on RFCs. They need to understand that attackers abuse trusted domains, Microsoft 365 does not list every legitimate sender for them, and enforcement requires measured work. A simple meeting flow works better than a technical dump.
- Open with risk: Without an enforced DMARC policy, your domain gives receivers no DMARC request to quarantine or reject messages that fail authentication. DMARC reduces direct domain spoofing; it does not stop lookalike domains, display-name impersonation, or abuse of compromised accounts.
- Tie it to Microsoft 365: Microsoft 365 is one major sender, but we need to validate every service using your domain.
- Explain the method: We start in monitoring mode, identify valid senders, fix failures, then stage policy changes.
- Show the outcome: The goal is p=reject for active sending domains and confirmed non-sending domains, after checking subdomain use.
- Set expectations: This is not a one-time switch. It is a monitored rollout with reporting and change control.
Policy stages to show clients
Use the policy name as a progress marker. Receivers retain control over final delivery decisions.
Monitor
p=none
Collect reports without requesting DMARC enforcement.
Quarantine
p=quarantine
Request spam handling for mail that fails DMARC.
Enforce
p=reject
Request rejection of mail that fails DMARC.
If a client asks why the project takes time, explain that enforcement has to follow evidence. A clean rollout depends on sender discovery, SPF lookup health, DKIM signing, DMARC alignment, and client sign-off. For a deeper client handoff, use a staged p=none to p=reject plan.
Stage DMARC enforcement under RFC 9989
RFC 9989 became the current DMARC standard in May 2026 and replaced RFC 7489. It removed the pct tag because receivers applied fractional enforcement inconsistently. Microsoft guidance still shows pct-based examples, but an MSP proposal should not depend on pct=10, pct=25, or similar steps. Use p=none until legitimate senders are ready for the full policy: receivers that ignore t=y apply p as published.
Optional test mode after readiness for quarantineDNS
_dmarc.client.tld TXT "v=DMARC1; p=quarantine; t=y; rua=mailto:d@client.tld"
- Use evidence gates. Move policy only after known legitimate sources pass DMARC and reports cover a complete business sending cycle, including infrequent invoicing or payroll. A high overall pass rate alone does not prove sender coverage.
- Use t=y carefully. With compatible receivers, p=quarantine asks for none and p=reject asks for quarantine, while report generation continues.
- Plan full policy changes. Older receivers can ignore the t tag and apply p as written, so test mode is not a guaranteed safety net.
- Keep rollback ready. Record the prior DNS value, change owner, approval, observation window, and reversal trigger before enforcement. Allow for cached DNS records when estimating rollback time.
Client-facing wording: The current standard no longer treats fractional pct values as the rollout control. We use source coverage, DMARC alignment, receiver-aware test mode, and a documented rollback decision before enforcement.
What to audit before the pitch
The best sales conversation starts with a small audit. The aim is to collect enough proof to make the problem real without promising an enforcement date before the data supports it. For Microsoft 365 clients, the audit should cover the tenant, DNS, and every obvious business sender.
|
|
|
|---|---|---|
Microsoft 365 | SPF and DKIM status for each custom sending domain | Core mail coverage |
DNS | One DMARC record per name, reporting destination, subdomain policy | Policy readiness |
Senders | Authorized services, business owners, and DMARC alignment | Breakage risk |
Domains | Active and parked domains, plus sending subdomains | Spoofing exposure |
A compact pre-call audit list for MSP discovery.
A quick DNS health check helps identify missing records before the meeting, but it does not prove that every sender passes DMARC. Suped's domain health checker is our starting point for reviewing published authentication records; confirm actual sending behavior with aggregate reports and message tests during onboarding.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Do not promise p=reject during the sales call. Promise the operating process: discovery, fixes, policy staging, reporting, and approval before enforcement.
The Microsoft 365 rollout plan
A Microsoft 365 DMARC project should feel safe and controlled. Use the plan below when a client wants the practical detail after the pitch. It shows that the MSP owns the work, but the client stays involved where vendor access or business approval is needed.
Starting DMARC recordDNS
_dmarc.client.tld TXT "v=DMARC1; p=none; rua=mailto:d@client.tld"
SPF example when Microsoft 365 is the only senderDNS
client.tld TXT "v=spf1 include:spf.protection.outlook.com -all"
Replace client.tld and the sample rua address with the client's actual domain and reporting destination. Merge the Microsoft 365 include into the existing SPF record, preserving authorized senders; publish only one SPF record per domain and stay within SPF's 10-lookup limit. If reports go to an external domain, confirm the required external reporting authorization is in place.
- Confirm DNS ownership: Know who can change public DNS and how approvals work before any record changes.
- Enable Microsoft DKIM: Retrieve the domain's two DKIM CNAME targets from the Defender portal or Exchange Online PowerShell, publish selector1._domainkey and selector2._domainkey, then enable signing. Copy the tenant-provided targets because newer and older domains use different formats.
- Inventory senders: Use reports and stakeholder interviews to identify every legitimate sending service. Treat Dynamics 365 Customer Insights - Journeys as a separate sender with its own domain authentication, even when the client also uses Microsoft 365.
- Fix authentication: Update SPF, DKIM, sender domains, and vendor settings until real mail passes DMARC.
- Stage policy: Move to quarantine, verify stable aggregate reports, then enforce reject after client approval. Under RFC 9989, do not use pct to phase only a fraction of failures.
After an initial DNS delegation, hosted records let technicians manage policy changes without repeated access to the client's DNS account. Suped's Hosted DMARC helps stage policy through a managed workflow, while Hosted SPF helps manage senders without constant edits to the client's base SPF record.
If the client has many business systems, run a formal sender audit workflow before quarantine. Confirm each source with its business owner before authorizing it in DNS.
Prove that legitimate mail passes DMARC
Send a test message through each production sending route to an external mailbox, then inspect the recipient's Authentication-Results header. Internal tenant messages are insufficient to verify outbound DKIM. Microsoft's DMARC guidance explains why DMARC requires an SPF or DKIM pass with a domain match to the visible From address.
Illustrative passing message headerstext
From: Accounts <accounts@client.tld> Authentication-Results: receiver.example; spf=pass smtp.mailfrom=client.tld; dkim=pass header.d=client.tld; dmarc=pass header.from=client.tld
- For SPF, compare smtp.mailfrom with the visible From domain. An SPF pass for an unrelated vendor domain does not satisfy DMARC alignment.
- For DKIM, verify dkim=pass and compare header.d, the signing domain, with the From domain. A signature using the tenant's onmicrosoft.com domain does not match the client's custom domain.
- Under default relaxed matching, the domains need the same organizational domain. Strict matching requires identical domains. One qualifying SPF or DKIM result is enough to pass DMARC.
- Test outbound connectors and forwarding routes too. Forwarding often breaks SPF, so verify that a matching DKIM signature survives. A DMARC pass does not guarantee inbox placement.
Record test results against each sender in the client handoff. Use them alongside aggregate reports before recommending the next policy stage.
How Suped fits the MSP delivery model
Suped is our DMARC platform for turning the pitch into a repeatable managed service. It centralizes client domains, identifies authentication issues in received reports, gives technicians steps to fix them, and packages progress into client-facing reports.
MSP organizations page showing client organizations, domain counts, email volume, and domain status columns
This matters when the client base is full of Microsoft 365 tenants. Each client has similar building blocks, but different senders, DNS hosts, business apps, and risk tolerance. A multi-tenant view lets technicians review domain status across clients.
- Issue detection: Suped identifies failing sources in reports and provides remediation steps.
- Report-based alerts: Suped alerts technicians to authentication failures as reports are processed. Aggregate reports typically arrive daily, so these alerts are not a live feed of every message.
- Unified view: DMARC, SPF, DKIM, blocklist (blacklist), and deliverability signals sit in one operational workflow.
- MSP scale: Client organizations, domain status, reports, and user roles are managed in a single dashboard.
Handling common client objections
The pitch usually works when the MSP is ready for predictable objections. Keep answers short, then bring the discussion back to operational control.
Client objection
- Microsoft covers us: The tenant has security defaults, Defender policies, and DKIM turned on.
- Nothing is broken: Users are sending and receiving mail today, so the client sees no urgent issue.
- DNS is risky: The client worries that authentication changes will block valid business mail.
MSP response
- Separate scopes: Microsoft protects the tenant. DMARC publishes the domain owner's requested treatment for mail that fails DMARC.
- Show evidence: Monitoring reveals unknown senders and failed authentication before enforcement starts.
- Use stages: The rollout begins at p=none, then changes policy after fixes and approval.
Client-facing wording: We begin with monitoring, test legitimate senders, and request approval before enforcement. We agree on a rollback trigger in advance and allow for DNS caching when reversing a change.
Scope the service so clients understand it
A clear scope prevents DMARC from becoming unpaid admin work. Split the offer into onboarding, rollout, and ongoing monitoring. Each phase has a defined client outcome. Specify the included domains and sender integrations, the DNS and vendor access the client must provide, and the approval owner. Separate onboarding remediation from recurring monitoring fees, with agreed limits for vendor troubleshooting and response times.
|
|
|
|---|---|---|
Onboarding | DNS, tenant, sender audit | Known baseline |
Fixes | SPF, DKIM, vendor changes | Valid mail passes |
Policy | Quarantine, then reject | Enforced domain |
Operations | Alerts and reports | Ongoing control |
Define delivery phases and client outcomes in the proposal.
The monthly deliverable should include current policy, known legitimate sender coverage, top failures, new sources, remediation work, and the next recommended change. Separate legitimate failures from unauthorized traffic and note gaps in receiver reporting. That keeps the report useful after setup and gives the client evidence for renewal.
Suped's DMARC monitoring workflow fits this scope because the MSP can track authentication health, source behavior, policy progress, and client reporting without building a custom reporting stack.
Agree on the next step with the client
Close the meeting with an agreed discovery scope: the domains to audit, the client's DNS owner, and the business teams responsible for sending services. Schedule a findings review before setting an enforcement date. Use that review to confirm remediation work and obtain approval for the next policy stage.
Frequently asked questions
No. Microsoft 365 helps with mailbox protection and Microsoft-hosted sending, but DMARC policy for a custom domain still depends on DNS, reporting, sender discovery, and staged enforcement.
For active domains without a validated enforcement policy, start with p=none, review reports, and fix valid senders before quarantine and reject. Keep existing enforcement when sender coverage is verified. Confirmed non-sending domains can start at p=reject after checking legitimate and subdomain use. Receivers that ignore t=y apply p as published, and pct is historic.
Show the client which domains have no DMARC record, a monitoring-only policy, missing DKIM, too many SPF lookups, or unidentified senders. Confirm sender identity and actual message results before recommending changes.
No. DMARC checks authorization of the protected domain in the visible From address. It does not stop visually similar domains, display-name impersonation, or abuse of compromised accounts, so the pitch should not promise those outcomes.
The MSP should recommend enforcement, but the client should approve it after reviewing sender status and business impact. Include IT, finance, marketing, and operations when those teams own sending tools.
Suped centralizes client domains, DMARC reports, SPF and DKIM status, issue detection, alerts, hosted records, and reporting so MSPs can run DMARC as an ongoing managed service.
