How to onboard client domains for MSP DMARC monitoring
Updated on 14 Aug 2026: We updated this guide for the current DMARC standard, safer policy testing, external report authorization, and repeatable client migrations.
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 reports, alert thresholds, users, client logos, billing references, and domain ownership clean. Give staff and client users the least access their roles require, and review access during handoff. This avoids a common service delivery problem: one analyst changes 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. For large migrations, bulk migration support or API-driven intake should follow domain deduplication and client-owner mapping so automation does not create duplicate or misplaced records.
|
|
|
|---|---|---|
Client | Acme Manufacturing | Workspace and billing owner |
Domain | acme.example | Monitoring scope |
DNS owner | Registrar partner | Change route |
Approval owner | IT lead | Policy sign-off |
Starting state | p=none | Policy baseline |
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. Under RFC 9989, that policy does not ask receivers to alter message handling. 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;
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 provider 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
Verify report routing and migration continuity
A valid DMARC record does not prove that reports will reach the MSP. RFC 9990 defines aggregate reporting and the external destination check. When the rua address uses a different organizational domain, the report consumer must authorize that destination with a DNS TXT record. Managed platforms normally publish this authorization on their reporting domain, but the MSP still needs to verify the exact rua value and confirm that aggregate reports arrive.
- Check discovery: Publish one DMARC TXT record, keep v=DMARC1 first, and confirm the exact rua destination.
- Check authorization: Confirm the external report consumer authorizes reports for the client domain.
- Check data flow: Wait for reports from multiple active receivers before marking collection complete.
- Preserve history: Export sender classifications, open issues, approvals, and policy history before replacing an existing destination.
- Record rollback: Keep the previous DMARC value, change owner, and success criteria in the onboarding ticket.
Aggregate reports contain authentication results and message counts, not message bodies. I still document who can access report data, how long it is retained, and what gets exported at contract handoff. That keeps the technical migration tied to the client's data-handling requirements.
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, a likely cause, an owner, 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. RFC 9989 removed the pct tag because receivers applied intermediate percentages inconsistently. It introduced t=y for testing, which asks receivers to apply one policy level below the published quarantine or reject policy. A current staging path is p=none, p=quarantine with t=y, p=quarantine, p=reject with t=y, then p=reject. I move only when report evidence shows that legitimate mail passes and the client has approved the next checkpoint.
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.
Test quarantine
p=quarantine; t=y
Request testing while remaining sources and forwarding paths are reviewed.
Quarantine
p=quarantine
Legitimate mail passes and the client approves quarantine handling.
Test reject
p=reject; t=y
Request quarantine-level handling before the final reject policy.
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. Each alert goes to the correct client queue with the affected domain, source, volume change, and assigned owner. 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, assign least-privilege access, and set notification recipients.
- Add domains: Add every in-scope domain, remove duplicates, 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.
- Verify reports: Confirm external destination authorization and aggregate report flow before closing setup.
- 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: Use the t=y testing steps before full quarantine and reject when report data supports each change.
- Report outcomes: Send the client a clear summary with actions completed and decisions needed.
Where Suped fits
For MSPs using Suped for day-to-day service delivery, the MSP workspace combines client separation, DMARC monitoring, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, alerts, blocklist monitoring, and client reporting. Analysts can work through issues and fix steps, operators can review status across client organizations, and account teams can generate reports for 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, confirm report flow, 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.
