If you're delivering email security to SMB clients and still emailing them PDF attachments with your Gmail signature at the bottom, you're leaving money — and credibility — on the table. White-labelling your DMARC reporting isn't a vanity exercise; it's the difference between a productised service clients renew and a one-off project they forget about. This post walks through exactly how to set it up properly.
The problem with how most MSPs deliver DMARC reporting today
The typical workflow looks something like this: you run a DMARC report, export a PDF from whatever tool you're using, drop it into an email, and send it to your client contact. Maybe you remember to brand the PDF, maybe you don't. The client opens it once, files it under "IT stuff," and has no idea what happened to last month's report when their CFO asks. When it's time for a QBR, you're hunting through sent mail to find the last three. There's no consistent client-facing experience, nothing that looks like a managed service, and nothing that justifies a recurring line item on an invoice. The tool is invisible, your brand is absent, and the whole thing feels like a favour rather than a product.
What white-label DMARC reporting actually means (and doesn't)
White-labelling in email security gets thrown around loosely, so it's worth being precise about what it covers in practice — because MSPs often over-invest in the wrong things.
What it genuinely covers
A properly white-labelled DMARC reporting setup gives your client three consistent touchpoints under your brand:
- A domain that belongs to you — the client portal and every report link should come from your domain, not the vendor's.
reports.acme-msp.com.aureads as a professional service.app.some-vendor.com/share/abc123reads as a reseller who couldn't be bothered. - Your logo and organisation name throughout — not just in a header banner but in the dashboard chrome, report footers, and page titles. The vendor's name should not appear anywhere the client can see it.
- A repeatable, client-accessible portal — somewhere the client can go on their own to review reports, not just an inbox thread they've lost track of.
What it doesn't need to cover
You do not need full CSS control over every pixel. You do not need client SSO with Azure AD. You do not need a bespoke colour palette that matches each client's brand (you're branding it to your MSP, not theirs). Scope creep on white-label requirements is a common reason MSPs delay shipping a productised service at all. Get the fundamentals right first.
How to set up your white-label domain
The custom report domain is the foundation everything else sits on. Here's how it works in practice.
- Choose your subdomain. Pick something clean and professional —
reports.yourmsp.com.auorsecurity.yourmsp.com.auare both solid choices. Avoid anything that looks like a vendor subdomain (nodmarc.yourmsp.com.auif that's going to confuse clients who've heard of DMARC tools). - Add the subdomain in platform settings. In DMARC Busta, you claim your white-label hostname in the branding/custom domain settings. You'll be given a CNAME target — currently
customers.dmarcbusta.pro. - Create the DNS record. In your DNS provider, add a CNAME record pointing your chosen subdomain to
customers.dmarcbusta.pro. TTL of 300–3600 is fine. - Wait for TLS provisioning. Cloudflare for SaaS handles the certificate issuance automatically. This is not instant — plan for a short verification and provisioning window rather than a same-minute turnaround. Don't promise a client their portal link at 3pm if you're configuring it at 2:45pm.
- Verify it's live. Once provisioned, hit your subdomain in a browser and confirm it's serving your branded portal, not a vendor page.
Once this is in place, every client portal URL and every report share link comes from your domain. That CNAME is doing a lot of quiet work for your brand.
Configuring your branding so reports look the part
The custom domain gets you the URL. The branding settings get you the visual. These are separate steps and both matter.
Upload both a light and a dark logo
DMARC Busta supports a light portal theme and a dark portal theme. If you pick dark mode and haven't uploaded a dark-mode logo, you'll end up serving a dark-background logo that disappears or looks broken — which is embarrassing when the client notices before you do. Upload both versions. SVG format is preferred because it scales cleanly across report PDFs, portal headers, and email previews without going fuzzy.
Set your organisation name carefully
Your organisation name appears in report titles, dashboard chrome, and footers. "Acme MSP" is fine. "Acme Managed Services Pty Ltd" might be accurate but reads as bureaucratic in a client-facing UI. Pick the name you'd use on a pitch deck, not your ASIC registration.
Choose your portal theme deliberately
The theme choice (light or dark) is layout-wide for the client portal experience. Dark themes read as more technical and modern, which some clients appreciate; light themes are more conservative and tend to cause fewer "is this legitimate?" reactions from clients who aren't especially tech-literate. Pick one, commit to it, and make sure both logo variants are uploaded regardless so you can switch without scrambling.
Delivering reports to clients without the email-attachment chaos
Once branding is configured, the client-facing delivery workflow changes substantially. Here's the intended flow.
The client portal: one URL per client, always up to date
Each client (organised as a DomainGroup in DMARC Busta) gets a dedicated portal URL in the format reports.{your-domain}/c/{token}. This portal lists every report for that client's domains — onboarding assessments, monthly security reports, milestone reports, progress summaries, outreach reports. Clients can filter by domain or report type, view inline, or download PDFs. No login required — it's token-based access.
Send that URL once during onboarding and put it in the client's IT documentation. Every report you publish from that point forward appears in the portal automatically. The client stops asking "can you resend that report from March" because they can get it themselves.
Publishing reports: the one-click step that matters
Every report in DMARC Busta has a Publish to Client Portal button in the toolbar. Clicking it does two things: it persists the report to the client's portal (so it's visible next time they open /c/{token}), and it generates a 30-day per-report share URL as a side effect. That share URL is useful when you want to forward a specific report in an email without opening up the entire portal — a clean link to a single document rather than attaching a PDF.
The scheduler generates weekly and monthly reports automatically, but you can also generate ad-hoc reports for any client and period on demand. If a client asks mid-month for a progress update after a configuration change, you generate the report, hit Publish to Client Portal, and drop the share link in a Slack message or email. Done in under two minutes.
Revoking access when a client offboards
When a client leaves, revoke their share token in the platform. The portal URL becomes immediately invalid. No need to chase down shared logins, deactivate accounts, or worry about them accessing future reports. This is a cleaner offboarding story than most MSPs have for any client-facing portal, and worth mentioning in your service agreement.
Where DMARC Busta fits
The capabilities above aren't aspirational — they're shipped as of April 2026. Here's how they map to the white-label workflow:
| What you need | Where it lives in DMARC Busta |
|---|---|
| Custom report domain (your subdomain) | Platform branding/custom domain settings — CNAME to customers.dmarcbusta.pro |
| Your logo and organisation name in all reports | Branding settings — light + dark SVG upload, organisation name field |
| Client-accessible portal with no login | reports.{your-domain}/c/{token} — token issued per DomainGroup |
| Publishing reports to the portal | Publish to Client Portal button in every report toolbar |
| Ad-hoc reports outside the scheduler | Generate report on demand, then Publish to Portal |
| Revoking client access | Revoke the DomainGroup share token — instant invalidation |
| Light/dark portal theme | Theme selector in branding settings — scoped to portal via data-theme="dark" |
The custom domain CNAME is the single most important step. Every other branding element builds on it. Do this first, before you onboard a single client.
The Publish to Client Portal button is what separates a managed service from a reporting tool. One click and the client sees it in their portal. The share URL is a bonus — useful for forwarding, not a replacement for the portal.
What this looks like in practice
Say you've just onboarded a 12-person accounting firm as a new client. Here's what the workflow looks like from day one:
Day 1 — Onboarding: You add the client as a DomainGroup, import their domains (their primary domain plus the two legacy domains they still send from), and run an initial assessment report. You hit Publish to Client Portal and send their contact the portal URL — reports.acme-msp.com.au/c/xk7t29 — with a short note explaining they can always find their latest reports there. The report shows your logo, your company name, your domain. The vendor is invisible.
Week 3 — Progress update: The AI Autopilot has progressed their primary domain to p=quarantine. You generate an ad-hoc progress report, publish it to the portal, and drop the per-report share URL into a Teams message to their principal: "Here's where things stand — we've moved to quarantine enforcement, next milestone is reject." They click the link, read the report, reply with "great, keep going." No attachment, no login, no confusion about whether they're on the right website.
Month 1 — Scheduled report: The monthly security report generates automatically and appears in the portal. You don't have to do anything. The client opens it themselves ahead of their monthly check-in call. They arrive at the meeting already knowing their domain alignment score improved. That's a better QBR conversation than "let me pull up the report now."
Month 6 — Milestone reached: Their primary domain hits p=reject. You generate a milestone report, publish it, and include the share link in the invoice email as a value reminder. The client sees a branded document confirming the project outcome. That's the kind of artefact that justifies the recurring fee at renewal time.
Common mistakes to avoid
- Skipping the dark logo upload before switching to dark theme. If you enable dark mode in the portal and your only uploaded logo is designed for a white background, it will either disappear or look broken against the dark chrome. Upload both logo variants before you set your theme.
- Reusing the same share token across multiple clients. Each DomainGroup should have its own token. Sharing a token between clients (or giving a single client contact access to all your clients' portals through one URL) is a data exposure risk and an offboarding nightmare. One client, one token, always.
- Promising the custom domain will be live within minutes. The CNAME and TLS provisioning process has a verification step that isn't instant. Set client expectations — or more practically, set up the custom domain during your own platform onboarding, not 20 minutes before the first client meeting.
- Publishing reports inconsistently. If you use the scheduler for monthly reports but forget to publish ad-hoc reports, the client portal becomes an incomplete picture. Build the publish step into your own workflow as a non-negotiable — it takes one click.
- Not telling clients the portal exists. The tokenised portal is only valuable if clients know to use it. Include the URL in your onboarding documentation, your service agreement, and your QBR template. Clients who self-serve on the portal ask fewer reactive questions and have more informed conversations at review time.
- Using a portal theme that conflicts with your brand. If your MSP brand is clean and light, a dark portal theme can feel inconsistent when a client compares it to your website or proposals. The portal is a client-facing extension of your brand — treat the theme choice as a branding decision, not a personal preference.
See the MSP capabilities — including the full white-label setup, tokenised client portal, and AI Autopilot features built specifically for MSPs running email security at scale.
