White-label reporting in DashboardFox isn't a single toggle — it's a set of four distinct branding layers, each covering a different part of the client experience. Understanding how these layers interact, and how they relate to tier limits for branding policies and custom domains, is essential for designing a white-label architecture that actually scales with your client base.
This chapter covers each branding layer, what it controls, and the practical limits and tradeoffs that come with each tier.
The Four Branding Layers
1. Login Page Branding
The login page is the first thing clients see — and it's the one element that sits completely outside the authenticated session. Because users haven't logged in yet, there's no user-level branding policy that can be applied. Login page branding is instead driven by which domain the user arrived from.
DashboardFox uses a domain-matching system for login branding: you configure a login page policy for a specific domain (e.g., reports.youragency.com), and when a user arrives at that URL, the matching branded login page is served — your logo, your colors, your favicon, your footer text, with no DashboardFox attribution. If no domain-specific policy matches, a default fallback policy is used. If no fallback exists, the default DashboardFox login page appears.
The connection between login branding and custom domains is direct: each distinct branded login experience requires both a configured domain and a login branding policy for that domain. One domain, one login branding policy — per branded access point.
2. Application Branding (Post-Login)
Application branding controls what authenticated users see once they're inside: logo, colors, navigation, feature visibility, sidebar links, and more. This is a policy-based system — you create a branding policy and assign it to a user group, a security group, or all users. When a user logs in, the system applies whichever policy is assigned to them.
This is where per-client branding differentiation happens in a multi-tenant environment. Different client groups can be assigned different branding policies — Client A's users see co-branded policy A, Client B's users see policy B, your internal agency users see yet another policy. Branding takes effect at login and persists for the session.
Application branding goes beyond logos and colors. Feature visibility is also controlled here: you can show or hide SQL access, scheduling, export options, embedding controls, and more — on a per-policy basis. This matters for client-facing users, who typically shouldn't see the builder interface at all, vs. your internal team members who need full access. Different branding policies allow you to present appropriately simplified interfaces to each group.
3. Embedded Report Branding
If you're embedding dashboards or reports into an external application, portal, or website via iframe, embedded branding controls what appears inside that frame. You can configure the embedded view to hide navigation, suppress export buttons, collapse the report header, or restrict interaction — independently of how the full application is configured for logged-in users. A client-facing embedded view can be cleaner and more constrained than the full portal experience, while the underlying data security still applies.
4. Email and Scheduled Report Branding
Scheduled reports delivered by email can be sent from your own domain via a custom SMTP configuration. This means clients receive scheduled PDFs or Excel exports from an address like reports@youragency.com rather than from a generic system address.
One important constraint: SMTP configuration is server-wide. You configure one SMTP gateway per DashboardFox workspace, and all outbound email — from all clients, all users, all scheduled deliveries — goes through that one mail server. You cannot configure per-client SMTP; all emails originate from the same sending domain. For most agencies this is fine — emails come from your agency domain, which is the right brand to put in front of clients. But if a use case requires Client A's emails from Client A's domain and Client B's from Client B's domain, that requires separate workspace instances rather than a shared environment.
Report Headers and Footers on Exported Output
For reports delivered as Excel or PDF — whether downloaded manually or sent on a schedule — DashboardFox supports configurable headers and footers that appear on every page of the exported document. This is a meaningful white-label touch point: the client's exported report can carry your logo, the report name, the generation date, applied filter criteria, page numbers, and more, rather than a plain data dump.
Header and footer fields are positioned in a 3×2 grid — top left, top center, top right, bottom left, bottom center, bottom right. Each position can contain dynamic tokens like @[ReportName], @[Date], @[Criteria], or an image reference pointing to your logo file. Footers (including page numbers) are PDF-only; Excel exports support headers but not footers.
Report headers and footers can be configured at two levels. A global default set at the server level applies to all exported reports unless overridden. Individual reports can then define their own header/footer settings that take precedence over the global default. This means you can set your agency logo and report name as a server-wide default, then customize specific reports — adding different logos for co-branded reports, client-specific criteria display, or page numbering for longer documents.
One scope note: header/footer configuration applies to grid and table report types exported as Excel or PDF. Chart, KPI, treemap, and geo map visualizations export as PNG image files and do not support headers or footers on the visualization output. If you need headers on chart data, the Data Tab export outputs the underlying data as Excel or PDF with headers applied.
DashboardFox's custom SMTP configuration is set at the workspace level — all outbound email for all users in that workspace sends through a single mail server. For agencies delivering reports under their own brand to multiple clients, this is exactly what you want: all emails from your agency domain. If a use case requires per-client sending domains, that requires separate workspace instances per client.
Tier Limits and What They Mean for Your Architecture
The number of branding policies and custom domains you have available is determined by your tier. This isn't just a pricing detail — it directly shapes how many distinct white-label experiences you can create within a single workspace.
| Tier | Branding Policies | Custom Domains | What This Means |
|---|---|---|---|
| Starter ($99/mo) | 1 | 1 | One branded environment — one login page, one application branding policy, one domain. Good for a single client or a single-brand agency portal. |
| Growth ($249/mo) | 5 | 3 | Up to 5 distinct branding contexts (e.g., 3 client groups + 1 internal + 1 partner), with 3 independently branded domains. Covers most growing agencies. |
| Scale ($499/mo) | Unlimited | 10 | Unlimited branding policies with 10 custom domains. Branding can be differentiated across as many client groups as needed. |
| Enterprise | Unlimited | Unlimited | Full flexibility for large multi-tenant operations. |
The practical question when choosing a tier is: how many distinct branded experiences do you need, and how many branded login URLs?
A single branding policy applied to all users — one logo, one color scheme — is sufficient if all your clients access the same portal under your agency brand. Many agencies operate this way: one URL like reports.youragency.com, one login page, one application brand. Starter handles this case.
As you add clients who want their own co-branded experience — their logo in the portal, a URL that matches their brand, a login page that looks like it belongs to them — you need additional policies and domains. Before jumping to the next tier, it's worth knowing that both custom domains and branding policies are available as add-ons: +1 Custom Domain at $29/month and +3 Branding Policies at $29/month, stackable on any plan.
This changes the tier decision meaningfully. A Starter account ($99/mo) with one extra domain add-on ($29/mo) and one branding policy pack ($29/mo) costs $157/month total and covers 2 domains and 4 branding policies — more than enough for a small agency with a handful of co-branded clients — without upgrading to Growth at $249/month. Growth's 5 policies and 3 domains cover most growing agencies outright, and add-ons extend it further without a tier jump. Scale's unlimited policies with 10 domains handles complex multi-client operations where each major client gets their own branded environment.
Why "Powered By" Badges Damage Client Relationships
Some vendors offer partial white-labeling — they let you add your logo but leave their brand attribution visible elsewhere in the interface. This is worse than it sounds.
When a client sees "Powered by [Vendor]" on the dashboard you're presenting as your work, a few things happen. First, it undercuts the perception that your agency is delivering a proprietary solution. Second, it makes the BI tool vendor visible to the client — raising the possibility that the client could procure the software directly and cut your agency out of the loop. Third, it signals that your agency is reselling a product, not delivering a service — which affects how clients perceive the value of your engagement fee.
Full white-label removes this entirely. Klipfolio charges $299/mo as an add-on for white-label removal. Metabase gates it behind their Pro tier at $575/mo. DashboardFox includes it from the $99/mo Starter tier, on every plan, with no add-on required. The competitive difference isn't just cost — it's that white-label is treated as a core feature rather than an upsell.
White-label branding — custom domain, logo, colors, branded login, no DashboardFox attribution — is included on every DashboardFox plan from $99/mo.
Designing Your Branding Architecture
Before you configure anything, sketch out the answers to these questions:
How many distinct branded experiences do you need? Count: one per major client group that wants co-branding, plus your internal team, plus any partner access. That number is the minimum branding policies you need.
How many branded login URLs do you need? If all clients log in at reports.youragency.com, one domain is sufficient. If Client A logs in at analytics.clienta.com and Client B at analytics.clientb.com, each of those is a custom domain that needs its own login branding policy.
Do any clients need their own sending domain for emails? If yes, that requires a separate workspace instance — you can't route outbound email through multiple SMTP servers in a single workspace.
Work through those questions and you'll know which tier you need and whether any clients are better served by their own dedicated instance rather than a seat in a shared environment. Most agencies find that Growth handles the bulk of their client base, with the occasional large enterprise client warranting a dedicated instance.
