You've just signed three new clients in the same month, each with a dozen or more domains spread across different registrars, different hosting environments, and different levels of existing email authentication. Congratulations. Now figure out how to onboard all of them before the billing cycle starts, without it becoming a week-long project or a pile of manually edited PDFs.
The problem with onboarding at scale
Most MSPs hit the same ceiling once email security starts to gain traction as a service line. The first few clients are manageable — you add the domains, generate a report, export a PDF, maybe slap a logo on it in Word or Canva, and email it across. It looks fine. The client is happy enough. But by the time you're looking at 50 domains across 8–10 clients, that manual workflow starts to cost you in ways that aren't always visible on the timesheet. You're spending 40 minutes per client on formatting that adds no analytical value. You're re-explaining what a DMARC report is every time you forward a PDF. You're losing track of which clients have seen which version. And your branded experience — or lack of one — is making you look like every other MSP who treats email auth as a checkbox rather than a managed service. The goal of this post is to walk through a repeatable, scalable onboarding process for bulk domain intake, using the actual workflow mechanics that reduce that ceiling significantly.
Before you touch the platform: get your domain inventory right
The biggest time sink in any bulk onboarding isn't the platform — it's the data. Walking into a CSV import with bad data is worse than doing it one by one.
Step 1: Build a clean domain inventory
Before you log into anything, get every client to give you a complete list of domains they own or operate — not just the primary trading domain. Include:
- All active sending domains (e-commerce, transactional, marketing)
- Parked domains that still receive email or are spoofable
- Legacy domains from rebrand or acquisition history
- Country-code variants (
.com.au,.net.au,.co.nz)
Clients are bad at this. Budget 15 minutes per client for a brief call or a simple form. The output you want is a spreadsheet with at minimum: domain name, client name, and whether the domain is actively used for sending. That's your import source.
Step 2: Normalise your spreadsheet for import
DMARC Busta supports bulk domain import via CSV and XLSX. Map your spreadsheet columns to what the import expects: domain name is the critical field. Clean up any trailing spaces, remove any http:// or www. prefixes, and flag domains that are purely parked so you know to set appropriate expectations about reporting volume. Five minutes of normalisation here saves you debugging import errors later.
Step 3: Group by client before you import
The platform's model is one DomainGroup per client. That matters because each group gets its own client portal, its own share token, and its own report history. If you batch-import across multiple clients into a single group, you'll spend time untangling it later. Spend 10 minutes up front to make sure your spreadsheet is sorted and split by client before you start creating groups.
Setting up the client groups efficiently
With clean data in hand, the actual setup moves quickly. Here's the sequence that minimises context-switching.
Create all your DomainGroups first
Don't interleave group creation with domain import. Go through your client list and create every DomainGroup in one pass — group name, client name, any notes. This gives you a complete list of groups to import into without stopping to context-switch mid-import.
Bulk import domains per group
For each group, use the CSV/XLSX import. Select the group, upload the file, confirm the import. Depending on the number of domains, this takes under a minute per client. For 50 domains across 8 clients, you're looking at around 10–15 minutes of actual import work if your files are clean.
Let the initial scan run
Once domains are imported, the platform runs an initial assessment — checking existing DMARC records, SPF configuration, DKIM selectors where detectable, and MX records. You don't need to babysit this. Import all groups, then step away for 20–30 minutes. By the time you're back, you'll have enough data to start generating onboarding reports.
Branding setup: do this once, benefit every time
This is the step most MSPs skip when they're in a hurry, and they pay for it every month afterward when they're still sending unbranded reports. Get your white-label configuration done before you generate a single client-facing report.
Set up your custom report domain
In the platform settings under Branding, you'll claim a subdomain — something like reports.acme-msp.com.au. You add a CNAME record in your DNS pointing that subdomain to customers.dmarcbusta.pro. From that point, every client portal and every report URL is served from your domain, not DMARC Busta's. TLS is handled automatically. Worth noting: the custom domain setup isn't instantaneous — there's a verification and provisioning step that ops handles per hostname, so allow some lead time rather than expecting it live the moment you add the CNAME.
Upload your logos and set your organisation name
You'll upload two logo variants: one for light mode, one for dark mode. These should be SVGs if possible — they scale cleanly at any report size. Your organisation name populates the dashboard chrome, page titles, and report footers. Once set, every report you generate from that point forward carries your branding. DMARC Busta stays invisible to the client.
Choose your portal theme
Light or dark — pick the one that matches your brand. If you go dark, make sure you've uploaded a dark-mode logo variant before flipping the switch. Clients opening reports.acme-msp.com.au/c/{token} will see your dark theme immediately, and a light logo on a dark background looks unfinished. This is a five-minute task that has a disproportionate impact on how professional the client experience feels.
Generating and publishing onboarding reports at scale
With groups set up, domains imported, scans run, and branding configured, you're now ready to generate the first wave of client-facing reports. This is where the bulk onboarding effort pays off.
The onboarding (initial assessment) report
For each DomainGroup, generate an onboarding report. This report summarises the current state of email authentication across every domain in the group — which have DMARC records, which are at p=none vs p=quarantine vs p=reject, which have SPF misconfigurations, which are missing DKIM. It's the document you'd previously have been assembling manually from DNS lookups and a template. It comes out branded with your logo, your organisation name, your footer.
Publishing to the client portal
Every report toolbar has a Publish to Client Portal button. Click it. That report is now persisted into the client's portal — accessible at reports.{your-domain}/c/{token} — and a 30-day share URL is minted as a side effect, which you can forward directly in your onboarding email. The client doesn't need a login. They open the link, they see their branded portal with the report available to view inline or download as a PDF.
Running through 8–10 clients in sequence
Each publish action takes seconds. Working through 8–10 client groups and generating + publishing one onboarding report per group is a 20–30 minute task once the setup is done. The total afternoon, including data prep and branding setup, is realistic for 50 domains across a mid-sized client cohort — not because the platform is magic, but because the bottlenecks have been moved to the parts that only need to happen once (branding, group structure) rather than repeating per client per month.
Where DMARC Busta fits
The workflow above isn't hypothetical — it maps directly to shipped capabilities in the platform. Here's how the specific features connect to the onboarding scenario:
- Bulk CSV/XLSX import — handles the domain intake without manual entry per domain.
- DomainGroup model — one group per client, clean separation of portal, reports, and token management.
- White-label custom report domain — your CNAME (
reports.acme-msp.com.au→customers.dmarcbusta.pro), Cloudflare-for-SaaS TLS, every report and portal URL on your hostname. - Layout-wide white-label branding — organisation name, light/dark logo, rendered across all report types and the entire dashboard chrome. DMARC Busta is not visible to your client.
- Tokenised client portal at
/c/{token}— revocable, no login required, filterable by domain and report type, inline viewing or PDF download. - Publish to Client Portal button — one click to persist a report into the client portal and generate a 30-day share URL.
- Onboarding report type — initial assessment report branded and ready to share on day one.
- AI Autopilot — after onboarding, automatic DMARC progression (none → quarantine → reject), SPF source approval, and anomaly detection run in the background, reducing the manual touchpoints between monthly reports.
The client portal is token-based, not login-based. That's a deliberate trade-off: no account provisioning friction for the client, no password reset tickets for you, but also no per-user access controls within a client organisation. If a client wants to rotate access, you revoke the token and issue a new one — takes seconds.
The white-label surface is organisation name plus logo plus hostname — not arbitrary CSS or colour palettes. If your brand relies on a specific colour scheme, assess whether light/dark mode with your logo is sufficient before committing. For most MSPs, it is.
What this looks like in practice
It's 1:00pm on a Thursday. You've just wrapped a scoping call with a new client — a mid-sized professional services firm with 14 domains (one primary, a handful of practice-area subbrands, several legacy acquisitions). They want to understand where they stand before you propose a remediation roadmap.
You ask them to fill in a quick domain inventory form while you're still on the call. By the time you hang up, you have a list. You clean it in about five minutes — strip the prefixes, check for duplicates, note three domains that are clearly parked and haven't sent email in years.
You create a DomainGroup for the client, import the CSV, and the platform starts scanning. You move on to the next client intake task. Thirty minutes later you come back, generate the onboarding report for this group, and hit Publish to Client Portal. You copy the 30-day share URL from the side effect and paste it into your onboarding email alongside a brief paragraph explaining what the report covers and what the next step is.
The client clicks the link. They land on reports.acme-msp.com.au/c/{token} — your branding, your logo, your portal. They see the report. They can filter by domain to focus on the ones they actually care about. They download the PDF for their internal records. They forward it to their CFO as context for approving the remediation budget. At no point does DMARC Busta appear.
From import to published report: under an hour including the scan wait. You did it for two other new clients the same afternoon.
Common mistakes to avoid
- Importing domains across clients into a single DomainGroup. This is the most common structural mistake in bulk onboarding. Once a group's portal token is shared with a client, everything in that group is visible to them. Mixing clients in one group means either a privacy problem or an untangling job. One client, one group, always.
- Forgetting the dark-mode logo before enabling dark theme. If you switch the portal to dark mode without uploading a dark-mode logo, clients see your light logo against a dark background — which often means a white rectangle or an invisible logo, depending on your SVG. Upload both variants first, then set the theme.
- Sharing one client's portal token with another client. Obvious in principle, easy to do when you're copy-pasting URLs in a hurry. Each token is unique to a DomainGroup. Double-check the URL before it goes in the email, especially when you're working through a batch of onboarding emails in sequence.
- Expecting the custom domain to be live immediately. The CNAME propagation is on your end, but the per-hostname provisioning involves an ops step. If you're planning a client-facing launch for a specific date, set up the custom domain a few days in advance rather than the morning of. Don't promise the client a portal URL on your domain until you've confirmed it's resolving correctly.
- Not publishing the onboarding report before sending the share URL. The Publish to Client Portal button is what makes the report appear in the portal. If you send a client their portal URL before publishing, they'll see an empty portal. Publish first, send the link second. It's a one-click step but it's easy to skip when you're moving fast.
- Skipping the parked domain conversation. Parked domains with no DMARC record are spoofable. Clients often don't know this and don't see why they'd care about a domain "we don't even use." Address it in the onboarding report walkthrough — low effort to remediate, high value as a talking point, and it sets the tone that this service covers the full domain estate, not just the primary.
See the MSP capabilities — including white-label branding, the tokenised client portal, bulk domain import, and AI Autopilot — or start your free trial and run through the onboarding workflow with your first few clients before you commit.
