You've just finished a solid month of DMARC work for a client — SPF flattened, DKIM keys rotated, policy progressed to quarantine — and the deliverable is a PDF attached to an email that will sit unread in someone's inbox for three weeks before they forward it to the wrong person. If that workflow feels like it's dragging down the perceived value of your email security practice, you're right, and it's a solvable problem.
The problem: reporting workflows that undercut the work
Most MSPs doing email authentication work have the technical delivery sorted. DMARC, SPF, DKIM — the configuration is sound. Where things fall apart is the client-facing layer. PDFs get emailed from a generic mailbox. They open on a phone as a blurry A4 rendering. The MSP's logo might be on page one, but by the time a client opens it (if they open it), the experience signals "small operation doing a good job of hiding it" rather than "specialist firm I'm paying a premium for." Worse, when a client asks for last quarter's report, someone on your team has to dig through sent mail and re-attach the file. There's no persistent home for the work you've done. The reporting workflow is the product experience, and right now it's an afterthought.
Why PDF delivery specifically is the wrong default
It's worth being precise about where the PDF-email workflow breaks down, because "just build a client portal" isn't a useful answer unless you understand the failure modes it's fixing.
The delivery problem
Email is a terrible distribution channel for security reports. PDFs get caught by spam filters — ironically, given what you're selling. They get forwarded without context. They don't render well on mobile. And the moment you send a file, you've lost control of it: you can't update it, you can't revoke access, and you have no idea whether it was opened. For a service that's supposed to demonstrate ongoing vigilance, handing over a static file and hoping for the best is the wrong posture.
The brand erosion problem
Even if your PDF has your logo on it, the container it arrives in — an email thread, a shared drive folder, a Slack message — is someone else's brand. The client's experience of your service is mediated by Google Drive or Outlook or whatever folder structure they've built. There's no consistent environment that says this is Acme MSP's email security service. Over time, that makes the work feel generic, which makes it feel commoditised, which makes it feel like something that should cost less.
The access management problem
If you've ever shared a portal login across multiple clients — or worse, sent a client a username and password for a tool they'll use once a quarter — you know the support overhead. Password resets, account lockouts, "I can see another company's data" tickets. It's amateur hour, and it's avoidable.
What a better reporting workflow looks like
The goal is a reporting experience that does three things: surfaces under your brand, requires nothing of the client to access, and gives you a persistent, organised record of every deliverable you've produced. Here's how to think about each component.
Your brand, your domain
Client-facing URLs should resolve to your domain, not someone else's. reports.acme-msp.com.au is categorically different from app.somevendor.com/client/12345. The former says you've built something. The latter says you've resold something and not bothered to hide it. For an email security practice specifically — where you're asking clients to trust your judgement about their DNS and mail infrastructure — the brand credibility of a custom domain is not a cosmetic detail.
Zero-friction client access
Clients should be able to open their portal without creating an account, remembering a password, or asking you for anything. A tokenised URL that goes directly to their report list is the right model. The trade-off is real: you don't get the audit trail of authenticated logins, and if someone shares the link, it's shareable. But for quarterly security reports sent to an IT manager or business owner, that trade-off is almost always correct. The friction of SSO or account creation costs you more in client experience than you gain in access control. If a client's token is ever compromised, you revoke it from your side and issue a new one — the client gets a new link, problem solved.
Persistent, organised report history
Every report you produce should land in one place, organised by domain and report type, accessible at any time without your team having to do anything. When a client asks "can you send me the report from three months ago," the answer should be "it's already in your portal" — not "let me find that and re-send it." That's a small thing that signals operational maturity in a way clients notice and remember.
Reports that look like yours
Branding isn't just logos. It's the consistent application of your visual identity across every touchpoint. If your onboarding assessment report looks different from your monthly summary, which looks different from your milestone report when a client reaches p=reject, the cumulative impression is inconsistency. Every report type — onboarding, monthly, progress, milestone, outreach — should render with the same logo, the same organisation name, the same footer. That's what a productised service looks like.
The operational upside MSPs underestimate
The client experience argument is clear, but the internal efficiency argument is just as strong.
Eliminating the re-send workflow
If every report is published to a persistent portal at the moment you generate it, the re-send request disappears. Your team stops spending time on "can you resend last month's report" tickets. The portal is always up to date because publishing is part of the generation workflow, not a separate step someone might forget.
Ad-hoc reports without ad-hoc processes
Sometimes a client has a specific question — "what did our authentication posture look like in Q3?" — and they need a report that doesn't fit the monthly cadence. If your reporting tool supports on-demand generation for any client and period, and publishing that report to the portal takes one click, you can respond to that request in minutes. That's a billable interaction that used to require manual PDF generation, formatting, attachment, and email. Now it's a conversation-closer.
Revocation as a client management tool
When a client churns, you revoke their portal token. The link they have stops working immediately. No need to remove them from a shared system, reset credentials, or worry about whether they can still access historical data. Revocation is instant and complete. That's cleaner offboarding than most MSPs have for any of their services.
Where DMARC Busta fits
The capabilities described above aren't hypothetical — they're the specific features DMARC Busta has built for MSPs running an email security practice. Here's how they map to the workflow.
Custom report domain
In the platform settings, you claim a subdomain — for example, reports.acme-msp.com.au — and point a CNAME record to customers.dmarcbusta.pro. TLS provisioning is automated via Cloudflare for SaaS, so HTTPS just works on your subdomain. Every report and every client portal is then served from your hostname. This isn't instant — there's an ops-side route configuration step — but it's a one-time setup, not ongoing maintenance.
White-label branding across the whole portal
Once your custom domain is live, the entire dashboard chrome, page titles, and report footers render under your brand — your organisation name and your logo. DMARC Busta doesn't appear anywhere client-facing. You can upload separate SVG logos for light and dark mode; the correct one is served automatically based on the portal theme you've selected. The white-label surface is deliberately scoped: organisation name, logo, light/dark theme. There's no custom CSS or arbitrary colour palette — if you need pixel-level brand control, that's a trade-off to weigh.
The tokenised client portal
Each client (modelled as a DomainGroup in the platform) gets a unique share token. Their portal URL is reports.{your-subdomain}/c/{token}. The portal lists every report published for that group, filterable by domain and report type. Clients can view reports inline or download PDFs. No login required. Revoke the token from your dashboard and the link stops working immediately.
The token model is the right call for SMB clients. They're not logging into your portal weekly — they're opening a link once a quarter. Removing the login step removes the support overhead and removes the friction that makes clients feel like the reporting is a chore rather than a service touchpoint.
The Publish to Client Portal button
Every report has a Publish to Client Portal button in the toolbar. Clicking it persists the rendered report to the client's portal — it appears the next time they open their /c/{token} URL — and simultaneously mints a 30-day per-report share URL. That share URL is useful if you want to forward a single report without directing someone to the full portal. The publish action is the moment your deliverable goes from "a thing you generated" to "a thing the client can access."
Report types covered
Branding applies across every report type the platform generates: onboarding assessments, monthly security summaries, milestone reports (for example, when a domain reaches p=reject), progress reports, and outreach reports. You're not maintaining a consistent brand across some reports and falling back to a generic template for others.
The scheduler handles recurring reports automatically — weekly and monthly summaries go out on cadence. For anything ad-hoc, you generate on demand and hit Publish. The client's portal is always current.
What this looks like in practice
Let's make this concrete. You've onboarded a new client — a professional services firm with four domains under management. Here's the workflow from day one.
- You add the client as a DomainGroup and import their domains via CSV. The platform begins collecting DMARC aggregate data.
- You generate an onboarding assessment report covering authentication posture across all four domains. You click Publish to Client Portal. The report is now live at
reports.acme-msp.com.au/c/{their-token}. - You send the client their portal URL — once, in the onboarding email. That's the last time you'll need to send them anything by email unless you choose to.
- Each month, the scheduler automatically generates a monthly security summary. You review it, click Publish, and it appears in their portal. If you want to prompt the client to look at it, you can send them a note with their portal link — but the report is already there.
- Three months in, the primary domain reaches
p=reject. The platform generates a milestone report. You publish it. The client opens their portal and sees the progression documented — onboarding assessment, three monthly summaries, milestone report — all under your brand, all in one place. - The client's IT manager leaves the business. New manager asks for a briefing. You send the portal link. Everything is already there. No re-sending, no digging through sent mail, no re-generating reports.
That's a productised service. The work and the reporting infrastructure are inseparable — the portal is part of what they're paying for.
Common mistakes to avoid
- Not uploading a dark mode logo before enabling dark theme. If you select a dark portal theme without uploading a dark-mode SVG, your logo may render poorly against the dark background. Set up both light and dark logos in the platform settings before you flip the theme — the platform serves them automatically, but only if both exist.
- Sharing one portal token across multiple clients. Each DomainGroup should have its own token. If you use the same token for multiple clients — or don't create separate DomainGroups — clients can see each other's reports. The DomainGroup model exists specifically to prevent this. One client, one group, one token.
- Publishing reports before reviewing them. The Publish to Client Portal button is a one-click action, which means it's easy to publish before you've confirmed the report content is accurate. Build a review step into your workflow — generate, review, publish — rather than treating generation and publishing as the same action.
- Not communicating the portal to clients at onboarding. The portal only delivers value if clients know it exists and know where to find it. Include the
/c/{token}URL in your onboarding documentation, your welcome email, and your service agreement. Clients who don't know about the portal will still email you asking for reports. - Forgetting to revoke tokens for churned clients. When a client offboards, revoke their token as part of your offboarding checklist. It's a single action, but it needs to be in the checklist. An active token means an active client portal — and a former client who can still access historical data from your platform.
See the MSP capabilities — white-label custom domains, the tokenised client portal, branded reports across every type, and the full multi-client management stack built for MSPs running email security as a productised service.
