Branded Email Security Reports: Light Mode, Dark Mode, and Your Logo

You've done the hard work — implemented DMARC for a client, moved them to p=reject, cleaned up their SPF record — and then you email them a PDF with a generic header and your own Gmail address in the From field. That's the moment the professionalism gap opens up. This post is about closing it: specifically, how to deliver branded email security reports that look like they came from your practice, not a tool you're quietly reselling.

The problem with how most MSPs deliver email security reporting

The typical MSP email security workflow goes something like this: run an assessment, export a report, attach it to an email, hope the client reads it. If you're using a platform that supports some form of branding, you might have squeezed your logo onto page one. But the footer still says something else, the portal URL is somebody else's domain, and when the client asks "can I show this to our board?", you forward them a link that has a vendor's name in it. It's not a good look, and it quietly undermines the argument that you — not the tool — are the expert delivering value.

The deeper issue is that most MSPs treat reporting as an afterthought: proof of work rather than a client-facing product. When you're trying to productise email security — put it in a service catalogue, charge a recurring fee, defend margin against competitors — the delivery experience is part of the product. A branded, consistently presented report that arrives at a clean portal on your domain tells a different story than a forwarded PDF attachment.

What "white-label" actually means for email security reports

White-label gets used loosely. In the context of email security reporting, it means at minimum: your logo appears, your name appears, and the vendor's name doesn't. In practice there are several layers, and understanding which ones you actually need will help you decide how much effort to put in.

Layer 1: Branded report content

This is the baseline. Every report type — onboarding assessments, monthly security summaries, milestone reports (e.g. "reached p=reject"), progress reports, and outreach reports — should render with your logo and organisation name, not the platform's. A client should be able to open any report and see your brand in the header and footer, regardless of what generated it.

Layer 2: A portal on your domain

Reports sitting in a portal at reports.somevendor.com/client/abc123 are not yours. They belong to the vendor. If you want to present email security as a service your practice delivers, the portal URL needs to be yours: reports.acme-msp.com.au, or whatever subdomain you choose. This matters for two reasons: direct client perception (they see your domain, they associate the capability with you), and practical things like link permanence if you ever switch platforms.

Layer 3: Light mode, dark mode, and logo matching

This is the layer most MSPs skip, and it's worth spending a moment on. Many clients access portals on devices where the OS is set to dark mode — MacBooks, iPhones, Windows 11 with dark theme enabled. If your portal renders with a white background in dark mode, or worse, renders your white logo on a dark background as an invisible rectangle, the experience falls apart. Proper white-label means serving the right logo variant for the right theme, automatically.

The distinction matters practically: a light-mode logo is typically a dark-coloured logo designed for white or light-grey backgrounds. A dark-mode logo is typically the light or reversed version of the same mark, designed for dark backgrounds. These are not interchangeable. If you only upload one, you will eventually get a support call from a client who sees a blank space where your logo should be.

Setting up your branded portal: the actual workflow

There are four concrete steps to go from "reports going out under someone else's brand" to "a fully white-labelled client-facing portal on your domain." Each step builds on the last.

Claim your custom report domain. In the platform's branding settings, you register a subdomain — something like reports.acme-msp.com.au. You then create a CNAME record in your DNS pointing that subdomain to customers.dmarcbusta.pro. Once the DNS record propagates, the platform's infrastructure handles TLS certificate provisioning for your hostname. This is not instant — there's a verification and provisioning step that ops processes — so factor that into your onboarding timeline. Don't promise clients a live portal link the same afternoon you set it up.
Upload your logos. In the branding settings, upload an SVG logo for light mode and a separate SVG logo for dark mode. SVG is the right format here: it scales cleanly to any display density, and you won't get pixelated logos on high-DPI screens. If your designer only gave you a PNG, go back and ask for the SVG source. Both logo variants should be prepared before you flip the portal theme — uploading only the light logo and then enabling dark mode is one of the most common ways this goes wrong.
Set your organisation name and portal theme. The organisation name appears in report headers, page titles, and footers — everywhere the platform would otherwise show its own name. Pick light or dark as your default portal theme. The dark mode implementation is scoped so it doesn't bleed into other parts of the platform; when a client lands on your white-label hostname, they get your theme, your logo for that theme, and your organisation name throughout.
Create a domain group for each client and share their portal token. Each client maps to a domain group. The platform generates a revocable share token for that group, giving you a public portal URL at reports.{your-subdomain}/c/{token}. This URL lists every report published for that client's domains, supports filtering by domain and by report type, and requires no login from the client. Share it once in your onboarding email, pin it in their IT documentation, and you're done. If a token is ever compromised or you offboard a client, revoke it — the link stops working immediately.

Light mode vs dark mode: a practical decision, not an aesthetic one

The choice of portal theme isn't just about what looks good in a screenshot. It's a client experience decision with real-world implications.

When to use dark mode

Dark mode works well if your brand's primary colours pop on dark backgrounds — deep blues, bright greens, white wordmarks. Tech-forward MSPs whose client base skews towards developers or creative professionals often find dark mode feels more native to how those clients use their devices. It can also give the portal a more security-focused, professional aesthetic that aligns with how clients think about "security dashboards."

When to stick with light mode

Light mode is the safer default for MSPs whose client base includes traditional industries — accounting firms, law practices, trades businesses — where clients are more likely to print reports or view them in bright office environments. Light-mode reports are also easier to read in PDF form, since most PDFs are designed for white backgrounds. If you're regularly emailing PDFs and directing clients to the portal as a secondary option, light mode is the more consistent choice across both mediums.

The logo preparation checklist

Before you go live with either theme, run through this:

Do you have an SVG version of your logo? (If not, request it from your designer.)
Does your light-mode logo have sufficient contrast on white or light-grey backgrounds?
Does your dark-mode logo have sufficient contrast on dark backgrounds? (Usually this means a reversed or all-white version of the mark.)
Have you tested both logos by viewing the portal on a real device with OS dark mode toggled on and off?
Are both SVGs clean — no hidden white rectangles behind transparent areas that will show up unexpectedly on dark backgrounds?

That last point catches a lot of people. Designers sometimes export SVGs with a white background rectangle baked in, which is invisible on a white portal but very visible on a dark one. Open the SVG in a text editor and check for any <rect> elements with a white fill if you're seeing an unexpected white block behind your logo.

Reports as a recurring client touchpoint

One of the structural advantages of getting branding right is that reports become a recurring, passive reinforcement of your value. Every time a client opens their portal — whether you send them a link or they've bookmarked it — they see your brand, your name, and a timeline of security work delivered under your practice's identity.

The scheduler and ad-hoc reports

The platform ships a scheduler that automatically generates and can publish weekly and monthly summaries. These appear in the client's portal at reports.{your-subdomain}/c/{token} without you manually doing anything once it's configured. But you also have the ability to generate reports on demand for any client and period — useful when a client asks "what happened last quarter?" or when you're preparing for a QBR and want a specific period report ready to reference.

The Publish to Client Portal button

Every report in the platform has a toolbar button — "Publish to Client Portal" — that does two things: it persists the rendered report into the client's portal so it's there the next time they open their /c/{token} URL, and it mints a 30-day per-report share link as a side effect. That share link is useful when you want to forward a specific report in an email or Teams message without directing the client to the full portal. You're not maintaining two separate things — publishing to the portal and generating a share link happen in the same action.

The 30-day per-report share link is a useful operational tool: it gives you a clean, single-purpose URL to drop into a client email for a specific report, while the portal token remains the permanent home for everything published to that client's group.

Where DMARC Busta fits

Everything described above is shipped and working in the platform as of April 2026. To be specific about where each piece lives:

Custom report domain — configured in the platform's branding settings. You enter your subdomain, create the CNAME record, and the platform handles TLS via Cloudflare for SaaS. Provisioning is not instant; allow time for DNS propagation and the ops-side hostname routing step.
Organisation name and logo upload — also in branding settings. Separate upload fields for light and dark logos. The organisation name propagates to every report type automatically once set.
Portal theme (light/dark) — selected in branding settings. Dark mode is scoped to the white-label hostname via data-theme="dark", so it only affects what clients see, not the MSP's own platform view.
Domain groups and share tokens — each client is a domain group. Token management (generate, revoke) is in the domain group settings. The public portal URL is reports.{msp-subdomain}/c/{token}.
Publish to Client Portal toolbar button — appears on every report. One click publishes to the portal and mints the 30-day share link.
Branded report types — onboarding, monthly, milestone, progress, and outreach reports all render under the MSP's branding. No report type has a separate branding toggle; it applies globally once configured.

What DMARC Busta doesn't do: custom CSS, arbitrary colour palettes, or client login accounts. The white-label surface is logo, organisation name, light/dark theme, and custom report domain. If you need pixel-perfect brand matching with a client's exact colour system, you're looking at a custom build — this platform is for MSPs who want professional, consistent branding without that overhead.

There's also no PSA or RMM integration (ConnectWise, HaloPSA, NinjaOne — none of these are connected). Reporting lives in the client portal and as PDFs; you pull it into your PSA workflow manually or via the share links. That's an honest trade-off to name upfront with your team.

What this looks like in practice

Say you're onboarding a new SMB client — a 40-person accounting firm. Here's the actual sequence with branded reporting in place:

You create a domain group for the client in the platform and add their primary domain.
Your custom report domain (reports.acme-msp.com.au) is already configured and live — you did this once when you set up the platform, not per client.
You run the initial assessment. The onboarding report generates with your logo, your organisation name in the header and footer, and your portal domain in any references. You click "Publish to Client Portal."
You copy the client's /c/{token} URL and paste it into your onboarding email alongside the 30-day share link for the specific assessment report. The email reads like it's entirely from your practice — because every URL in it is on your domain.
Over the following weeks, the AI Autopilot progresses their DMARC policy from p=none toward p=reject. When they hit p=quarantine, a milestone report is generated. You publish it. It appears in their portal automatically. No email required — they can check the portal themselves, and you've set the expectation that it's where their security reports live.
At the quarterly business review, you pull up their portal on screen. The client sees a timeline of reports — all branded, all on your domain. You didn't manually compile anything; you published as you went.

The accounting firm has no idea what platform you're using. They see your brand, your domain, and a consistent record of security work. That's the outcome you're building toward.

Common mistakes to avoid

Going live with dark mode before uploading a dark-mode logo. If you enable the dark portal theme but only have a light-mode logo uploaded, clients on dark-mode devices will see a blank or nearly invisible logo. Prepare both SVG variants before you flip the theme.
Sharing the same domain group token across multiple clients. Each client should have their own domain group and their own token. Sharing a token means one client can see another's reports. It also means revoking one client's access revokes all of them. One group, one token, per client — no exceptions.
Promising the custom domain will be live immediately. DNS propagation plus the ops-side hostname provisioning step means there's a lag. Don't include the portal URL in a client's onboarding materials until you've confirmed the domain is active and the TLS certificate has been issued. Test it yourself first.
Using a raster PNG instead of an SVG for your logo. PNGs look fine on standard displays and terrible on high-DPI screens, especially in a portal that renders at multiple sizes. Get the SVG from your designer or branding files. This is a one-time fix with permanent benefit.
Treating the portal token as permanent without a revocation plan. Token links require no login, which is the feature — but it also means if you forward a token URL widely or a client shares it internally, it stays live until you revoke it. Build revocation into your offboarding checklist. When a client leaves, revoke the token on the same day you offboard their domains.
Not publishing reports as you go. The portal is only as useful as what's in it. If you generate reports but don't click "Publish to Client Portal," the client's portal stays empty. Make publishing part of your standard report workflow — not an optional last step you remember half the time.

See the MSP capabilities on DMARC Busta — including the full white-label feature set, multi-client management, and how the platform is built for MSPs running email security as a productised service.