Setting Up a Tokenised Client Portal for Email Security: A Step-by-Step Guide for MSPs

Most MSPs managing email security for SMB clients are still emailing PDF reports as attachments — or worse, pointing clients at a shared login that half of them can't remember how to use. There's a better way, and it doesn't require building a client portal from scratch. This guide walks through exactly how to set up a tokenised, white-label client portal so your clients can access every DMARC, SPF, and DKIM report you've ever published for them, without a login, without your vendor's branding plastered over everything, and without you fielding "can you resend that report?" tickets.

The problem in one paragraph

DMARC enforcement is a multi-month project. You're generating onboarding assessments, monthly security summaries, milestone reports when a client hits p=reject, and the occasional progress update for a sceptical decision-maker. The typical MSP workflow is: generate report, export PDF, attach to email, send. That approach has several failure modes: the client loses the attachment, you lose track of what's been sent, there's no single place a client can go to review their history, and if you're white-labelling the service, the vendor's logo is sitting right there in the PDF header. You end up looking like a reseller rather than an authority. The fix is a persistent, branded client portal where you publish reports once and clients access them on demand — no logins, no attachments, no admin overhead.

Understanding the tokenised portal model

Before jumping into setup steps, it's worth understanding the architecture because it informs every decision you make about how to structure clients and share access.

One domain group per client

In DMARC Busta, each MSP client maps to a domain group. A domain group is the container for all of that client's domains — a client might have three trading domains, a transactional email subdomain, and a legacy domain they haven't decommissioned yet. All of those live under one group. Reports are generated at the group level or per-domain, and everything published to the portal is scoped to that group.

Share tokens, not logins

Each domain group gets a single revocable share token. The public portal URL takes the form:

reports.{your-msp-domain}/c/{token}

Anyone with that link can access the portal — no account, no password. The portal lists every report you've published for that group, lets the viewer filter by domain or report type, and supports inline viewing or PDF download. The moment you revoke the token, the link is dead. A new token gives the client (or a new contact at the client) a fresh URL. This is the right trade-off for SMB clients: they won't use SSO, they won't remember passwords, and you don't want to be managing user accounts for every client contact who needs to see a report.

The honest trade-off: token-based access means anyone who has the link can view the portal. For most SMB clients, that's fine — the reports contain your analysis, not raw log data or credentials. If a client has unusually sensitive requirements, you can revoke and reissue the token if the link gets shared somewhere it shouldn't. It's not SSO with audit trails, and it's not trying to be.

Step 1: Claim your white-label report domain

This is the foundational step. Without it, portal URLs and report headers will show DMARC Busta's domain rather than yours — which defeats the purpose of white-labelling.

1. Choose your subdomain. Most MSPs use something like reports.acme-msp.com.au or security.acme-msp.com.au. It should be on a domain you own and control DNS for. Avoid using a client-facing domain — this is your operational subdomain.
2. Add the CNAME record. In your DNS provider, create a CNAME record pointing your chosen subdomain to customers.dmarcbusta.pro. The exact record will look like: reports.acme-msp.com.au CNAME customers.dmarcbusta.pro. TTL of 300–3600 is fine; lower TTL makes testing faster.
3. Register the hostname in platform settings. In DMARC Busta, navigate to the organisation/branding settings and enter your custom report domain. The platform will verify the CNAME and, once confirmed, provision a TLS certificate via Cloudflare for SaaS. Every portal URL and report served from that hostname gets a valid HTTPS certificate under your domain.
4. Wait for provisioning. Verification is automated, but the per-hostname route binding involves an ops step, so don't expect it to be instant. Plan for this to be confirmed within a business day, not within minutes. Don't schedule a client demo for an hour after submitting the request.

Once this is done, your client portal URLs will read reports.acme-msp.com.au/c/{token} — your brand, your domain, HTTPS, no DMARC Busta in sight.

Step 2: Configure your white-label branding

The custom domain gets you the URL. Branding gets you the visual experience. When a client opens the portal on your white-label hostname, the dashboard chrome, page titles, and report footers all render under your brand. DMARC Busta stays invisible.

What you can configure

• Organisation name — appears in report headers, page titles, and footers. Use your trading name, not an abbreviation.
• Light mode logo — SVG format. Used when the portal renders in light mode.
• Dark mode logo — SVG format. Used when the portal renders in dark mode. This is a separate upload, not an automatic inversion of your light logo.
• Portal theme — light or dark. This is the default the portal opens in.

A note on SVG logos

SVG is the right format here because the portal renders at variable viewport widths and you don't want a rasterised logo looking soft on a retina display. If your designer has only given you PNGs, ask for the SVG source. If your logo has a transparent background and works on both light and dark surfaces, you might get away with one file — but in practice, a dark logo on a dark portal background is invisible, and a light logo on a white background disappears equally well. Upload separate files. This takes five minutes and saves an embarrassing client moment.

Branded reports, not just the portal

Branding applies across every report type DMARC Busta generates: onboarding assessments, monthly security reports, milestone reports (e.g. when a domain reaches p=reject), progress reports, and outreach reports. You're not just branding a portal page — you're branding every deliverable in your email security service. That's what makes it a productised service rather than a resold tool.

Step 3: Set up your first client group and publish a report

With your domain and branding in place, the per-client setup is straightforward.

1. Create a domain group. In the MSP dashboard, create a new domain group for the client. Name it clearly — you'll be looking at this list across many clients, so a consistent naming convention (e.g. client trading name) helps. Avoid using internal account codes that mean nothing to you six months later.
2. Add the client's domains. You can add domains individually or bulk-import via CSV or XLSX. If a client has multiple domains, import them all now. It's much easier to manage a complete picture of a client's email surface from day one than to add domains piecemeal as issues surface.
3. Generate the share token. Each domain group has a share token. Find this in the group settings — the portal URL will display once the token is generated. Copy and store this URL; it's what you'll share with the client.
4. Generate a report. Whether it's an initial onboarding assessment or a monthly summary, generate the report for the relevant period. The report will render with your branding — your logo, your organisation name, your domain in the URL.
5. Publish to the client portal. In the report toolbar, click the Publish to Client Portal button. This does two things: it persists the rendered report into the client's portal (so it appears at reports.{your-msp-domain}/c/{token} the next time they open it), and it mints a 30-day per-report share URL as a side effect. The per-report URL is useful for forwarding a single report without sending the client to the full portal — for instance, emailing an exec a direct link to the milestone report without exposing the full history.
6. Send the portal URL to the client. This is a one-time step per client. From here, every subsequent report you publish simply appears in their portal automatically. The client doesn't need a new link — they bookmark the portal URL and it's always current.

Step 4: Maintain the portal as a living record

The portal's value compounds over time. A client who opened their portal six months ago and sees a timeline of reports — from the initial assessment, through the quarantine milestone, through to p=reject confirmation — has a concrete record of the work you've done for them. This is useful at renewal time, at QBR time, and when a new stakeholder at the client asks "what have you actually been doing?"

Scheduled vs. ad-hoc reports

DMARC Busta ships a recurring scheduler for weekly and monthly report summaries — these are generated and can be published automatically. But you can also generate ad-hoc period reports on demand. This is useful when a client asks for a specific date range, when you want to produce a one-off milestone report, or when a client has been onboarded mid-month and the scheduled report doesn't cover their full first period. Generate the report, set the period, publish it — it appears in the portal alongside the scheduled reports.

Revoking and reissuing tokens

If a client contact leaves the business, or if you have reason to believe the portal link has been shared more widely than intended, revoke the token. The old URL immediately returns an error. Generate a new token and send the fresh URL to the relevant contacts. The published reports remain in the group — they're not tied to the token itself, only access to them is. This is the right mental model: the token controls the door, not the contents.

Where DMARC Busta fits

Everything described in this guide maps directly to shipped, verified capabilities in DMARC Busta. To name them explicitly:

• Custom report domain — configured in the platform's organisation/branding settings. Your subdomain, CNAME to customers.dmarcbusta.pro, automated CNAME verification, Cloudflare for SaaS TLS provisioning.
• White-label branding — organisation name, light logo, dark logo, portal theme. Applies to the full portal chrome and every report type.
• Tokenised client portal — the /c/{token} URL, per domain group, revocable, no login required. Filter by domain, filter by report type, inline view or PDF download.
• Publish to Client Portal button — in the report toolbar on every report. One click persists the report to the portal and mints a 30-day per-report share URL.
• Ad-hoc period reports — generate on demand for any client and period, publish alongside scheduled reports.
• Multi-client management — the domain group model, MSP dashboard, bulk CSV/XLSX import.

The white-label setup makes DMARC Busta invisible to your clients. The portal URL is your domain, the reports carry your branding, and the client has no reason to know what's powering the service. That's the point — you're selling your email security practice, not reselling a vendor.

The Publish to Client Portal button is the operational heartbeat of the service. Every time you click it, you're adding to a permanent, branded record of the work you've done for that client. Over a 12-month engagement, that history becomes one of the clearest demonstrations of value in your service stack.

What this looks like in practice

Here's a concrete example of the workflow once everything is configured.

It's the first week of the month. DMARC Busta's scheduler has generated monthly security summaries for all active domain groups. You open the MSP dashboard, spot that three clients have reports ready. For two of them, you click Publish to Client Portal directly — no review needed, the summaries look clean. For the third client, you notice an anomaly in the report: a new sending source appeared mid-month that hasn't been authorised in SPF. You hold that report, investigate, add the source, and then publish an updated version with a note in the report commentary explaining what was found and what was done. The client's portal now shows the monthly report with the incident documented. When the client's IT manager opens the portal that afternoon — they check it on the first of every month, because you told them to when you onboarded them — everything is already there.

Meanwhile, a prospect scanning their domain via your website's embedded scanner widget has reached out. You create a new domain group for them, run an onboarding assessment, and publish it to their (new) portal. You send them the /c/{token} URL as part of your proposal email. They click it, see a branded report on your domain, and the conversation starts from a position of authority rather than a generic PDF attachment with someone else's logo on it.

Common mistakes to avoid

• Not uploading a dark mode logo before enabling dark theme. If you set the portal theme to dark without uploading a dark logo, the platform will fall back to your light logo — which may be unreadable on a dark background. Upload both logos before you flip the theme. Check it from an incognito window before sharing any portal URLs.
• Sharing the same token across multiple clients. Each domain group should have its own token and its own portal URL. Never give one client the portal URL for another client's group. It sounds obvious, but in a rush it's easy to copy the wrong URL from your notes. Label portal URLs clearly in your client records.
• Expecting instant custom domain provisioning. The CNAME verification is automated, but the per-hostname route binding involves an ops step. Don't promise a client a live portal URL on the same afternoon you submit the domain registration request. Build a one-business-day buffer into your onboarding checklist.
• Publishing reports before branding is configured. If you publish a report to the portal before your logo and organisation name are saved, the report renders unbranded. There's no retroactive re-render — you'd need to re-publish. Set up branding completely before you start publishing anything to client portals.
• Never telling clients the portal exists. The portal only creates value if clients actually use it. Include the portal URL in your onboarding email, mention it in your first QBR, and tell clients to bookmark it. A portal no one visits is just a feature you paid for without extracting any relationship value from it.

See the MSP capabilities — including the full white-label setup, tokenised portal, and billing model built for MSPs running email security as a productised service.