A client forwards you a panicked email: their CFO just got a spear-phishing attempt that spoofed the company's own domain, and the IT manager wants answers by end of day. Your scheduled monthly DMARC report isn't due for three weeks. What do you send them? If your answer is "I'll log into the portal and screenshot something," you've already lost the room.
The problem with fixed reporting schedules
Most DMARC tooling is built around a rhythm: aggregate data rolls in, a report fires on the first of the month, someone glances at it, life goes on. That cadence works fine for steady-state monitoring, but it falls apart the moment something goes wrong — or the moment a client asks a pointed question, a prospect wants to see evidence of your work, or a compliance audit lands with two days' notice. MSPs running email security as a productised service need to be able to generate a report for any client, for any period, on demand — and deliver it in a way that looks deliberate, not improvised. Emailing a raw PDF from your personal Gmail, sharing a login you've cobbled together from a trial account, or saying "I'll send it through later this week" are all ways to quietly undermine the professional credibility you're trying to build. The lack of ad-hoc reporting capability is one of the most common reasons MSP email security practices look amateurish despite the underlying technical work being solid.
What ad-hoc reporting actually means in practice
It's worth being precise here, because "ad-hoc" gets used loosely. There are two distinct scenarios where on-demand report generation matters, and they call for slightly different workflows.
Scenario one: the client investigation
Something has gone wrong — or a client thinks something has. A spoofed email made it through to an executive. A mass mail campaign just completed and the client wants to know whether their ESP was correctly authenticated. A new SaaS tool was onboarded last quarter and nobody checked whether its outbound mail was DKIM-signed. In all of these cases, you need a report scoped to a specific domain and a specific time window, generated now, delivered in a format the client can actually read and reference later.
Scenario two: the sales or QBR moment
You're in a quarterly business review with a client who's been on a DMARC enforcement journey for six months. They've moved from p=none to p=reject. You want to show them the before-and-after. Or you're in a discovery call with a prospect and want to hand over an initial assessment report on their domain right then. A scheduled report that went out three weeks ago doesn't serve either of these moments — you need something generated on the spot, under your brand, ready to share before the call ends.
Building an investigation workflow that holds up
The mechanics of a good ad-hoc investigation workflow come down to three things: speed to generate, quality of output, and delivery method. Get all three right and you look like a mature practice. Miss any one of them and you're back to scrambling.
Step 1: Scope the request before you open the tool
Before generating anything, get clear on what the client is actually asking. "Something weird happened with our email" is not a scope. Pin down:
- Which domain or domains are in scope (they may have several)
- The date range — not just "this week" but specific dates, because DMARC aggregate data is date-bound
- What outcome they need — do they want to understand what happened, confirm a new sender is working, or produce something for an internal compliance file?
This step sounds obvious but it saves you from generating a month-wide report when the client only cares about a 48-hour window, or generating a report for the wrong domain because their trading name and their registered domain are different.
Step 2: Generate the right report type
Different situations call for different report types. An initial assessment report makes sense when a prospect or new client wants a baseline. A progress report is right when the client is mid-journey and wants to see movement. A milestone report is appropriate when they've hit a meaningful threshold — reaching p=reject is the obvious one, and it's genuinely worth documenting formally because it's the kind of thing a client can include in their own security posture documentation. A security report is the right vehicle for an incident-style investigation — it frames the data in terms of what passed, what failed, and where unauthenticated mail is originating.
Choosing the right report type isn't just about aesthetics. It signals that you understand what the client is trying to achieve, and it frames the data in a way that's legible to a non-technical stakeholder — which is almost always who ends up reading it.
Step 3: Deliver it through a channel that reflects your brand
This is where most MSPs quietly lose points. Generating a good report and then emailing it as an attachment from your personal address, or sharing a link from a platform that has someone else's branding on it, undermines the work. The delivery method is part of the product. The client should receive something that looks like it came from you — your domain, your logo, your name — not from a vendor they've never heard of.
The right delivery pattern for ad-hoc reports is a URL the client can open immediately, that lives somewhere persistent (not a file attachment that gets buried in email), and that you can revoke if the engagement ends or the report becomes outdated. More on how this maps to the actual tooling below.
The "Publish to Client Portal" workflow
Once you've generated an ad-hoc report, you have two distribution paths and it's worth understanding the difference between them.
The 30-day share link
Generating a report and publishing it mints a per-report share URL with a 30-day validity. This is the right tool when you need to forward something immediately — drop it into an email, a Teams message, or a Slack DM to the client's IT manager. It's time-limited, which is actually a feature: it creates a natural expiry that encourages clients to revisit their portal rather than bookmarking stale links.
The persistent client portal
Publishing a report to the client portal persists it at the client's portal URL — reports.{your-domain}/c/{token} — where it appears alongside every other report you've published for that client. This is the right vehicle for anything the client might want to reference more than once: a milestone report they're including in their compliance pack, a baseline assessment they want to revisit during a QBR, or a series of monthly summaries they can browse themselves.
The portal supports filtering by domain and by report type, so a client managing multiple domains isn't staring at an undifferentiated list. They can pull up just the reports for their primary trading domain, or just the monthly summaries, without asking you to find something for them.
When to use which
| Situation | Right tool | Why |
|---|---|---|
| Client asks for immediate clarification after an incident | 30-day share link via message | Fast to send, no need to explain what the portal is |
| QBR prep — showing progress over six months | Publish to portal, walk through in the meeting | Client can see the full history, you control the narrative |
| New client onboarding — initial assessment | Publish to portal + share link as intro | Sets up their portal immediately, link is the first thing they receive |
| Prospect in a sales call | Share link | Instant, requires no login, expires if they don't convert |
| Compliance audit — client needs a file | PDF download from portal | Client can download directly without involving you |
Where DMARC Busta fits
The ad-hoc reporting workflow described above maps directly to shipped capabilities in DMARC Busta. Here's how the pieces connect.
The Publish to Client Portal button is present on every report toolbar. Clicking it does two things simultaneously: it persists the rendered report into the client's portal (accessible at reports.{your-msp-domain}/c/{token}) and it mints a 30-day per-report share URL you can forward immediately. One click, two distribution paths.
The ad-hoc period report feature lets you select a client (DomainGroup), a report type, and a custom date range, and generate the report on demand — independently of the scheduled weekly and monthly reports that run automatically. This is the capability that makes investigation workflows and QBR prep actually workable.
The white-label custom reports domain means the URL your client sees is yours — reports.acme-msp.com.au, not a platform domain. Combined with the layout-wide white-label branding, the portal your client opens shows your organisation name and logo throughout, with no visible reference to the underlying platform. The client's experience is entirely of your brand.
When a client opens an ad-hoc report you've just published, the URL is yours, the logo is yours, and the report footer is yours. The quality of the underlying data analysis is what closes the gap between "managed IT" and "security practice."
The tokenised client portal handles the access question cleanly. There are no client login accounts to provision or reset — each DomainGroup gets a revocable share token. If a client's engagement ends, you revoke the token and the portal URL immediately goes dead. If you want to give a new stakeholder access, you share the same URL (or regenerate the token if the previous one was shared too widely). No SSO configuration, no password resets, no "I can't log in" support tickets.
The absence of client logins is a deliberate trade-off: it eliminates an entire category of support overhead in exchange for a slightly different access model. For most SMB clients, a bookmarked URL they can share internally is more practical than individual login credentials they'll forget.
The AI Autopilot runs underneath all of this — automatically progressing DMARC policy, flagging new sending sources for approval, and monitoring DKIM. The ad-hoc reports surface what the autopilot has been doing, which means when a client asks "what has actually happened with our email security over the last month," you have a documented, formatted answer ready to generate in under a minute.
What this looks like in practice
It's a Tuesday afternoon. One of your SMB clients — a professional services firm with two domains, one for client-facing mail and one for their internal systems — messages you via Teams. Their operations manager received an email purportedly from their own domain that was clearly a phishing attempt. The IT manager wants to understand whether their DMARC policy actually stopped anything, and the firm's COO wants a written summary by Thursday for a board update.
You open the DMARC Busta dashboard, navigate to the client's DomainGroup, and generate an ad-hoc security report scoped to the last 14 days for their primary domain. The report is generated. You click Publish to Client Portal. The report is now live in their portal at reports.your-msp-domain.com.au/c/{their-token}, and you have a 30-day share link in your clipboard.
You paste the share link into Teams with a two-sentence summary: what the DMARC policy caught, and what the board needs to know. The IT manager opens it immediately — no login, no friction. For the COO's board pack, the IT manager downloads the PDF directly from the portal. You haven't sent a single email attachment. The report is under your brand throughout. The whole workflow, from receiving the message to sending the link, takes less than five minutes.
On Thursday, the client mentions in passing that the portal has been useful — they've been browsing the previous monthly reports to understand the trend. That's a retention conversation you didn't have to manufacture.
Common mistakes to avoid
- Generating a report before scoping the date range. DMARC aggregate data is granular — a report generated for "this month" when the client wants to understand an incident that happened in a specific 48-hour window will contain a lot of noise and miss the signal. Always confirm the exact date range before generating.
- Sharing the client portal token across multiple clients. Each DomainGroup should have its own token. If you've issued one token and shared it informally with several clients for convenience, revoking it for one of them invalidates access for all of them. The correct model is one token per DomainGroup, managed independently.
- Publishing to portal before setting up white-label branding. If you publish a report before configuring your custom report domain and uploading your logo, the client's first experience of their portal is unbranded. First impressions of the portal are hard to undo — set up branding in the platform settings before you publish anything to a client.
- Uploading only a light-mode logo. If your client portal is set to dark theme and you've only uploaded a light logo, the result is typically a white logo on a light background — unreadable, unprofessional. Upload separate SVG logos for both light and dark mode before setting a portal theme.
- Treating the 30-day share link as a permanent reference. The per-report share link expires after 30 days. If you send a client a link and they reference it in their compliance documentation or internal wiki, it will stop working. For anything that needs to be permanently accessible, direct the client to their portal URL (
/c/{token}) rather than a time-limited share link.
See the MSP capabilities — including the ad-hoc period report workflow, white-label portal, and Publish to Client Portal tooling.
