You've done the hard work of getting a client's domain to p=reject, their email is clean, and the deliverability numbers look good. Then you email them a PDF. They reply asking where to find "that dashboard thing again." You paste a link. They ask if it's secure. You look like a capable technician who hasn't quite figured out the product part yet. That's the gap this post is about.
The problem: good work, amateur delivery
Most MSPs selling email security today are doing the technical work competently — DMARC records deployed, SPF flattened, DKIM keys rotated. Where the wheels fall off is the client experience around that work. Reports go out as unbranded PDF attachments from a personal Gmail or a generic noreply@ address. Clients have no self-service view of their own data. When they ask "how are we tracking?", the honest answer is "let me run a report and email it to you." There's no portal, no persistent history, and nothing that looks like a managed service rather than a one-time engagement. For an MSP trying to justify a recurring monthly fee, that's a serious positioning problem. You're charging SaaS money and delivering consultant vibes.
The funnel starts before the sale
The cleanest way to think about this is as a funnel: prospect scans their domain → you capture the lead → you onboard them → you deliver ongoing reports → they renew without thinking about it. Most MSPs only participate in steps two through five, and even then, patchily. DMARC Busta is designed to let you own every step, under your brand, from the first touchpoint.
Step one: the scanner widget on your website
DMARC Busta ships an embeddable scanner widget — a simple script tag you drop onto your website. A prospect lands on your site, types in their domain, and gets an instant read of their DMARC, SPF, and DKIM posture. From their perspective, this is your tool. Your branding. Your competence on display.
This matters for lead generation because it filters in the right prospects. Someone who bothers to scan their domain is already email-security aware, which makes the conversation about a managed service far shorter. You're not explaining why DMARC exists — you're showing them they have a problem and that you have the fix.
The practical upshot: every scan is a warm lead with a known technical starting point. You know before the first call whether they're at p=none, p=quarantine, or — occasionally — nowhere at all. That's a better opening to a sales conversation than a cold discovery call.
What the widget doesn't do
To be direct: the widget is a lead capture mechanism, not a full self-service assessment. It surfaces posture at a point in time. The detailed onboarding report, the source analysis, the remediation roadmap — those come from you, inside the platform, after you've added the prospect as a client. The widget opens the door; you walk through it.
Onboarding: the first report sets the tone
Once a prospect becomes a client and you've added their domains to a DomainGroup, DMARC Busta can generate an onboarding report — an initial assessment that documents current posture, identifies sending sources, flags misconfigurations, and sets a baseline. This is the first piece of branded collateral your client sees from your managed service.
If that report arrives as a generic PDF with "DMARC Busta" in the header, you've just told your client they're paying you to operate someone else's tool. If it arrives under your logo, your organisation name, and a portal link at your domain, you look like you've built something. The difference is entirely in setup, not in the underlying data.
The white-label surface: what it covers and what it doesn't
DMARC Busta's white-label is deliberately scoped: you get your organisation name, a light logo, a dark logo, and a custom report domain. That's it. There's no custom colour palette, no CSS overrides, no arbitrary theme editor. Some MSPs will find this limiting; most will find it's exactly enough to look professional without spending a week on brand customisation.
What it covers in practice:
- Every report type — onboarding, monthly security, milestone, progress, and outreach reports — renders with your logo and organisation name in the header and footer.
- The client portal is served from your subdomain (e.g.
reports.acme-msp.com.au) and shows your branding across the entire layout. DMARC Busta is not visible to your client. - Both light and dark portal themes are supported. You upload separate SVG logos for each, and the platform serves the right one automatically based on the theme the MSP has selected for that portal.
What it doesn't cover: any part of the DMARC Busta platform that your client never sees. The MSP-facing management dashboard is unbranded. This is sensible — your clients aren't logging in there.
The client portal: replacing the PDF email chain
This is the part of the product that changes the client relationship most substantially. Instead of emailing reports and hoping the client finds them in their inbox three months later, every report you publish appears in a persistent, filterable portal at a URL like reports.acme-msp.com.au/c/{token}.
How the token model works
Each DomainGroup (one client) gets a share token. The portal URL for that client is constructed from your white-label domain and that token. The client bookmarks it, shares it internally, references it during your quarterly review. No login required — the token is the credential.
Token-based access is a deliberate design choice, and it comes with a real trade-off worth naming: it's less granular than per-user SSO. If a client contact leaves the company, you revoke the token and issue a new one. All old links immediately stop working. That's clean and simple, but it does mean you need a process for communicating new portal links when you rotate tokens. Build that into your offboarding checklist for client contacts.
The portal itself lets clients filter by domain and by report type, view reports inline, and download PDFs. It's a self-service history of your work, which is exactly what a retainer client needs to feel like they're getting ongoing value rather than paying for something invisible.
Publishing to the portal
Every report in DMARC Busta has a Publish to Client Portal button in the report toolbar. Clicking it does two things: it persists the report to the client's portal (so it appears the next time they visit /c/{token}), and it mints a 30-day per-report share URL as a side effect. That share URL is useful when you want to forward a single report in an email or a Teams message without directing the client to the full portal — a link that expires in 30 days is lower-stakes than handing out the permanent portal URL.
You can also generate ad-hoc reports for any client and period on demand, then publish them immediately. This is useful when a client asks for a report outside your normal scheduling cadence, or when you want to create a milestone report ("you've reached p=reject") and get it in front of them the same day.
Recurring reports without manual work
Beyond ad-hoc generation, DMARC Busta schedules weekly and monthly summary reports automatically. Once you've configured the schedule for a client's DomainGroup, reports appear in the portal without you touching anything. This is the recurring-value proof point that justifies the monthly fee — your client sees new reports in their portal every month, with your logo on them, whether or not they've emailed you recently.
The AI Autopilot layer
Underneath the reporting and portal infrastructure sits the part that reduces your per-client maintenance overhead: AI Autopilot. This handles DMARC policy progression (moving a domain from p=none through p=quarantine to p=reject as alignment confidence increases), SPF source approval, DKIM monitoring, and anomaly detection.
For an MSP running email security at scale across dozens or hundreds of client domains, the alternative to automation is a technician manually reviewing DMARC aggregate reports, identifying new sending sources, and nudging policies forward. That's billable time that doesn't scale, and it introduces human inconsistency. Autopilot handles the progression logic; you remain in the loop on approvals and exceptions, but the engine keeps things moving without you scheduling a weekly review for every domain.
This is worth flagging in your client conversations too. "We use automated monitoring that watches your domain around the clock and flags anomalies" sounds better than "we check in monthly." It's also more accurate.
Where DMARC Busta fits
To make this concrete, here's how each shipped capability maps to the funnel stages described above:
| Funnel stage | DMARC Busta capability |
|---|---|
| Lead generation | Embedded scanner widget (script tag on your website) |
| Onboarding | Onboarding / initial assessment report, branded with your logo and org name |
| Ongoing delivery | Scheduled weekly/monthly reports, auto-published to client portal |
| Client self-service | Tokenised portal at reports.{your-domain}/c/{token}, filterable by domain and report type |
| Ad-hoc reporting | Generate on demand, click Publish to Client Portal, optionally share a 30-day link |
| Brand consistency | White-label custom report domain, light/dark logo, org name across all report types |
| Policy automation | AI Autopilot — progression, SPF approval, DKIM monitoring, anomaly detection |
| Multi-client scale | DomainGroup model, bulk CSV/XLSX domain import, MSP dashboard, RBAC team roles |
The custom report domain is the single highest-leverage setup step. Everything your client sees — the portal, the reports, the share links — comes from your domain. Set it up before you onboard your first client, not after.
The Publish to Client Portal button is the habit that makes the retainer defensible. If you generate a report and don't publish it, your client never sees the value. Publishing takes one click. Make it part of your standard workflow, not an afterthought.
What this looks like in practice
Here's a concrete scenario. You're running email security for 40 SMB clients. You've configured your white-label domain (reports.acme-msp.com.au) and uploaded your light and dark SVG logos. Each client is a DomainGroup with a unique share token.
On the first of the month, DMARC Busta automatically generates and publishes monthly security reports for all 40 DomainGroups. Your clients open their portal links — bookmarked months ago — and see the new report waiting. No email from you required. No PDF attachment. No "where do I find that again?"
Midway through the month, one client's domain crosses the threshold to p=reject. Autopilot handles the policy progression. You generate a milestone report to mark the occasion, click Publish to Client Portal, and forward the 30-day share link in a brief congratulatory email. The client clicks through to a portal that looks like yours, reads a report with your logo, and feels like they've achieved something with your help. You've spent about four minutes on this interaction.
A prospective client visits your website and scans their domain via the widget. Their SPF record has too many lookups and they're sitting at p=none. You call them with that context already in hand. You demo the portal using a sanitised existing client's report (published, your branding). They ask if they'll get something like that. You say yes, from day one. The close is shorter than it would have been without the demo artefact.
Common mistakes
- Not uploading a dark logo before enabling dark mode. If you flip the portal to dark theme without a dark-optimised SVG logo, your light logo renders on a dark background — often unreadable if it has a transparent background. Upload both before you share a portal link with any client.
- Sharing the same token across multiple clients. Each DomainGroup gets its own token for a reason. If you reuse or conflate tokens, clients can potentially see reports that aren't theirs, and revoking one token breaks access for multiple clients. One DomainGroup, one token, always.
- Waiting to set up the custom report domain. The custom domain setup involves a CNAME change and a verification step on DMARC Busta's side. It's not instantaneous. If you onboard your first client before this is done, they see the default domain, which breaks the white-label illusion immediately. Do this on day one of your trial.
- Not publishing reports to the portal. The scheduler publishes automatically once configured, but ad-hoc and milestone reports require you to click Publish to Client Portal. MSPs who skip this step end up with a portal that looks sparse to clients because it only contains scheduled reports. Every significant report should go in the portal.
- Using the 30-day share link as a substitute for the portal. The per-report share link expires. If you send it to a client and they try to open it five weeks later, it's dead. Use the portal URL (
/c/{token}) as the canonical, permanent link for clients. Reserve the 30-day link for one-off shares in messages where you want the link to stop working eventually.
See the MSP capabilities — if you're evaluating whether DMARC Busta fits your practice, the MSP page covers the full feature set with specifics on white-labelling, the client portal, and per-domain billing.
