How to onboard client domains for MSP DMARC monitoring
Michael Ko
Co-founder & CEO, Suped
Published 12 Jun 2026
Updated 12 Jun 2026
8 min read
Summarize with
Onboarding a client domain for MSP DMARC monitoring means collecting the right sending-source context, adding or updating DNS records, confirming aggregate report flow, classifying every legitimate sender, fixing SPF and DKIM gaps, and moving policy in controlled stages. I treat it as a service delivery workflow, not a one-time DNS task, because the real value for the client comes after reports start showing what is actually sending mail as their domain.
The clean operating model is simple: one client organization, one domain inventory, one reporting destination, one issue queue, and one policy plan. Suped supports that model with an MSP dashboard for multi-tenant management, plus DMARC, SPF, DKIM, hosted records, alerts, client reports, blocklist monitoring, and issue remediation in one place.
Start with scope, ownership, and access
Before touching DNS, I confirm who owns the domain, who can approve mail changes, and which systems send email. MSP onboarding breaks down when the client says "we only use Microsoft 365" but invoices, CRM alerts, marketing automation, ticketing, payroll, and website forms also send as the same domain. Those sources show up in DMARC reports, and they need an owner.
- Domain inventory: List primary domains, parked domains, redirect domains, and subdomains used for mail.
- DNS access: Identify who can add TXT and CNAME records, then decide whether the MSP edits DNS or sends approved change requests.
- Sender inventory: Capture every mail source, including business mail, marketing platforms, billing systems, support desks, forms, scanners, and line-of-business apps.
- Client approval: Get named approval for policy changes, because quarantine and reject affect real mail when sources remain unauthenticated.
Microsoft 365 admin center domain settings used during MSP onboarding
For clients with strict change control, I split onboarding into discovery, monitor-only deployment, remediation, policy staging, and steady-state reporting. That gives the client a visible path and gives the MSP a repeatable checklist.
Create the client workspace and add domains
Each client should sit in a separate organization or tenant inside the MSP console. That separation keeps reporting, alert thresholds, users, client logos, billing references, and domain ownership clean. It also avoids a common service delivery problem: one analyst fixes the wrong client domain because every domain lives in a shared flat list.
MSP organizations page showing client organizations, domain counts, email volume, and domain status columns
In Suped, the MSP organization view shows client organizations, domain counts, email volume, and domain status. I use that view as the daily queue for onboarding and ongoing service delivery: new domains get added, inactive domains get questioned, and domains stuck at monitoring get reviewed before the next policy stage.
|
|
|
|---|---|---|
Client | Acme | Tenant owner |
Domain | Primary | Scope |
DNS | Partner | Access |
Owner | IT lead | Approval |
State | Monitor | Policy |
Keep intake fields short enough to use in tickets, reports, and handoff notes.
Publish DMARC in monitoring mode first
A new client domain usually starts at p=none. That policy does not ask receivers to block mail. It tells receivers where to send aggregate DMARC reports, which gives the MSP the evidence needed to find legitimate systems, unauthorized sources, broken DKIM, SPF lookup problems, and domain match failures.
Monitor-only DMARC TXT recorddns
Host: _dmarc.client.com Type: TXT Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@client.com; fo=1; pct=100
Do not skip monitoring
Moving a client straight to quarantine or reject before sender discovery risks blocking invoices, password resets, ticket replies, form submissions, and operational alerts. I only recommend enforcement once the visible legitimate senders pass DMARC.
If the client already has a DMARC record, I check the current rua destination before changing anything. Some clients have old reports flowing to a former vendor or an abandoned mailbox. A focused DMARC monitoring workflow turns those reports into a source list and remediation queue instead of raw XML files sitting unused.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Classify senders and fix authentication
After reports start arriving, I group sources into four buckets: known and passing, known but broken, unknown but probably legitimate, and unauthorized. This classification is the core MSP work. The client does not need a spreadsheet of IPs. They need a clear decision: approve, fix, migrate, or stop.
Good onboarding pattern
- Source review: Map each source to a business owner before making DNS changes.
- SPF check: Confirm the visible sending path passes and stays under lookup limits.
- DKIM check: Enable DKIM for every provider that supports domain-level signing.
- Domain match: Verify the authenticated domain matches the client domain or approved subdomain.
Weak onboarding pattern
- Assumed senders: Accepting the client's first list as complete without report evidence.
- SPF sprawl: Adding every requested include until the record fails lookup limits.
- DKIM gaps: Leaving third-party mail unsigned because the first report volume looks small.
- No owner: Treating unknown sources as noise instead of assigning a client decision.
SPF needs special care in MSP environments because clients often have years of accumulated includes. When the record approaches the DNS lookup limit, Suped's Hosted SPF can centralize sender management so the MSP can update authorized senders without opening a DNS ticket every time.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
The strongest practical workflow is to turn every authentication failure into an issue with evidence, likely cause, and exact fix steps. Suped does this inside the issues view, so the MSP can move a domain through remediation without asking an analyst to interpret XML each week.
Use hosted records when clients need controlled changes
Hosted records are useful for MSPs because they reduce repeated DNS work. The client or registrar admin adds a CNAME once, then the MSP can manage policy, reporting, SPF sources, and MTA-STS settings inside the platform. This is especially useful when the client has outsourced DNS, strict change windows, or no one internal who understands TXT syntax.
Hosted DMARC CNAME patterndns
Host: _dmarc.client.com Type: CNAME Target: client-token.hosted-dmarc.example
With Hosted DMARC, Suped lets an MSP stage policy changes without repeatedly editing the client's zone file. The exact CNAME target comes from the setup screen, so I never guess or reuse targets across clients.
Hosted DMARC configuration dialog showing policy controls, CNAME setup, and expanded advanced options
Hosted records need ownership rules
- Approval path: Define who can change policy, add SPF senders, and update alert recipients.
- Change log: Record why each sender or policy change was made and who approved it.
- Exit plan: Keep a clean export of current policy and sender state for client handoff.
Move policy in stages
Policy enforcement should be boring. I want the client to see that legitimate mail passes before enforcement, then move gradually enough that any remaining exception is visible and reversible. A common staging plan is p=none, then quarantine at a small percentage, then quarantine at 100 percent, then reject once the client accepts the remaining risk.
Policy staging checkpoints
Use report evidence before moving the client domain to the next DMARC policy stage.
Monitor
p=none
Reports flowing, sources classified, no receiver action requested.
Trial
pct=25
Known sources pass, exceptions assigned, limited receiver action.
Control
p=quarantine
Legitimate mail passes, residual failures accepted or removed.
Enforce
p=reject
Client approves hard failure handling for unauthenticated mail.
Subdomains deserve a separate decision. Some clients use subdomains for marketing, support, or transactional mail. Others never send from subdomains and should use a strict sp value. I document the subdomain plan during onboarding so enforcement does not surprise a business unit later.
Flowchart showing an MSP DMARC onboarding process from intake to monthly reporting
Set alerting, reporting, and client handoff
Once monitoring is live, the MSP needs a rhythm. I set alerts for sudden authentication failures, new sending sources, policy regressions, and blocklist or blacklist events. Then I package the client-facing view around outcomes: what changed, what improved, what still needs approval, and what risk remains.
Create client report dialog with organization, date range, logo, and language options
Suped's client reporting workflow is useful here because the MSP can generate client reports with organization, date range, logo, and language options. That keeps the service repeatable across clients while still giving each account a report that fits the relationship.
- Weekly review: Check new sources, failure spikes, lookup errors, DKIM gaps, and policy drift.
- Monthly report: Summarize volume, authentication health, policy stage, fixed issues, and open decisions.
- Quarterly review: Confirm domain inventory, dormant services, new vendors, and enforcement readiness.
- Incident path: Define who gets alerted when spoofing attempts, failure spikes, or blacklist events appear.
The practical MSP onboarding checklist
A repeatable checklist protects margin. It also gives junior engineers a safe path and gives account managers a clear client narrative. I keep the checklist focused on tasks that move the client toward monitored, authenticated, and enforced mail.
- Create client: Create the client organization, add internal owners, and set notification recipients.
- Add domains: Add every in-scope domain and document whether each domain sends mail.
- Check DNS: Validate current DMARC, SPF, DKIM, MX, and related records before editing.
- Publish DMARC: Start with p=none unless the domain already has verified enforcement readiness.
- Review reports: Classify sources and assign every broken legitimate sender to an owner.
- Fix domain match: Prioritize DKIM signing with the client's domain, SPF lookup health, and vendor-specific sender setup.
- Stage policy: Move through quarantine and reject only after report data supports the change.
- Report outcomes: Send the client a clear summary with actions completed and decisions needed.
Where Suped fits
For MSPs that need the best overall DMARC platform for day-to-day service delivery, Suped brings together multi-tenancy, DMARC monitoring, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, real-time alerts, blocklist monitoring, and client reporting. The useful part is operational: analysts get issues and fix steps, operators get client-level visibility, and account teams get reports they can use in recurring reviews.
A clean onboarding creates the managed service
MSP DMARC onboarding works when it turns a messy domain into a managed control: known senders, authenticated mail, visible exceptions, staged enforcement, and reporting the client understands. The DNS record matters, but the service is the workflow around it.
Start with p=none, collect the data, fix the legitimate senders, use hosted records where change control slows delivery, then move policy deliberately. That approach gives the MSP a repeatable service and gives the client a safer path to DMARC enforcement.
