White label email marketing.

Key takeaway

White label email marketing splits on one axis: whether you're rebranding somebody else's software or reselling somebody else's team. Either way the rebranding is cosmetic. The dashboard, the login domain and the report change. The From domain, the DKIM signature and the tracking host don't, and those are what a mailbox provider scores. The 0.30% ceiling doesn't care that the mail went out for different companies. I'd decide which domain signs each client's mail first.

What white label email marketing actually is.

White label email marketing is an arrangement where one company's email platform or email team is sold to clients under a different company's brand. The client sees your logo, your login screen, and your name on the monthly report, while the software or the labour behind it belongs to somebody they never hear about. That definition is accurate and it hides the thing worth knowing, because the phrase covers four arrangements that behave nothing like each other, and they split on whether you are rebranding software or reselling a team. The client sees your logo either way, so branding isn't the variable. What changes underneath is which domain signs the mail, and that's a setting somebody has to choose. On most agency accounts nobody chose it on purpose.

The people asking are consistent enough to list. Agencies running email across a book of clients, franchises whose local branches each want their own sends, consultants who would rather not forward a third-party invoice, and SaaS products bolting email onto something else. When one of them brings me this, it arrives worded as a branding problem: they want the login screen and the monthly report to carry their own name. Two questions in, it's always about which domain each client's mail is signed by, and that's the one nobody has an answer to. In a decade of building these platforms I've never seen it asked before a contract was signed, and it decides whether a client's reputation is theirs or everybody's.

The four arrangements sold under one name.

Those four differ on who holds the account rather than on what the client sees. I'd settle which one you're actually selling before quoting anybody, because the answer decides who carries the reputation.

1. Rebranded platform: you license a vendor's product, put your logo and your login domain on it, and sell seats to clients who never see the vendor's name.
2. Reseller: you sell the vendor's product under the vendor's own name for a margin or a commission, and the client knows who built it.
3. White-label delivery: another agency or a contractor writes, builds, and sends the campaigns, and the work goes out under your name rather than theirs.
4. Client-owned account: the client holds the platform contract in their own name and you operate it for them, with no rebranding anywhere in the arrangement.

Choosing between them isn't a price comparison, whatever the vendor pages imply. Three questions settle it: who holds the platform contract, who holds the consent record, and who the client calls at nine at night when a send stalls. The first is commercial and reversible. The second is the list itself, and it belongs to the client in any arrangement worth signing. The third is the one agencies underestimate, because a rebranded product means the client can't call the vendor even when the vendor is the only party who can help.

Now notice what none of the four decided. Every one leaves the client's sending domain exactly where it was. The arrangement settles whose invoice arrives and whose logo sits on the login screen, and says nothing about which domain the mail goes out under.

Two layers, and only one of them gets rebranded.

Every email product has an interface layer and a sending layer. The interface layer is what a client looks at: the dashboard, the login domain, the colours, and the report. The sending layer is what a mailbox provider looks at: the From header, the DKIM signature, and the host every tracked link redirects through. White labeling changes the first list. It isn't, on its own, a change to anything on the second.

The two sets of decisions are independent, and that's the part worth reading twice. You can buy a fully rebranded dashboard, hand a client a login on your own domain, and still send every message signed by the vendor's domain. You can equally run a plain vendor dashboard while the mail is entirely the client's, authenticated on the client's own DNS. The second setup looks worse and behaves better. In DKIM the d= domain claims responsibility for introducing the message into the mail stream, and the public key verifying the signature is served from a _domainkey subdomain of that same domain. The DNS records land wherever the signing identity is, and whoever owns that zone owns the reputation accumulating on it. The two-layer model stops helping at the account where the second layer was never a decision at all: the dashboard gets rebranded in an afternoon, the signing domain is whatever the vendor set up, and nobody looks at it until a client asks to take their sending somewhere else.

Whose reputation absorbs a bad list.

Mailbox providers score a sending identity, not an agency. That identity is a domain and, on shared infrastructure, an IP, and the score follows what the identity has sent recently. The layer white labeling doesn't touch is therefore the exact layer being judged, which means the rebranding decision and the reputation decision have nothing to do with each other. Agencies make the first on purpose and the second by accident.

DMARC authenticates the From domain, and it does that by requiring SPF or DKIM to validate a domain aligned with it, so the name a recipient can actually read is the name on the hook. Google's sender guidelines put numbers against it: above 5,000 messages a day to Gmail accounts you need SPF and DKIM, DMARC published for the sending domain, one-click unsubscribe, and a spam rate in Postmaster Tools that stays under 0.30%. Every one of those is measured per domain. Not per agency, not per account, and certainly not per logo.

The tidy version agencies reach for is the one to watch. Consolidating ten clients under one agency-owned sending domain is one warm-up, one set of DNS records, and one conversation instead of ten, which is genuinely less work. It also pools ten reputations into a single bucket, so the client who bought a list from a conference organiser is now setting the spam rate for the other nine. The 0.30% ceiling doesn't care that the mail was sent for different companies. It sees one domain behaving badly.

Who counts as the sender when the mail carries your brand.

Three roles sit on top of each other here, and three different tests decide them. Under data protection law the client is normally the controller, because the list and the consent record are theirs, and the agency is the processor acting on instructions. Under US anti-spam law the test is different again, and it never asks whose logo is on the platform.

Pressing send makes it your send, whoever's product is in it. The reputation being spent is the client's if their domain signed the mail and yours if it didn't, which is the whole reason the separation is worth what it costs. On the email where you pitch your own retainer it's yours either way. Two things follow: an address that opted out of one client's list never appears on another's, and the relationship gets written down before the first import, so that whose list it is, what you may do with it, and what happens at offboarding all have answers before anybody needs them.

The rebranded dashboard is silent on all of that. It changes what the client sees and nothing about who answers for the mail. The label moves anyway, and selling is what moves it: an agency that pitches "our platform" hard enough starts promoting its own service inside the client's message, and that's the sentence that turns a processor into a sender.

What you can charge, and what you take on with it.

The commercial case is a margin. You buy wholesale, you sell retail, and the gap is yours. Three shapes cover almost every arrangement.

1. Markup on seats: you buy a plan at wholesale and bill a fixed monthly platform fee above it.
2. Per-thousand sends: you bill on volume, which tracks the vendor's own cost model and moves with the client's list.
3. Folded into the retainer: the platform never appears as a line item, and the margin stays invisible until somebody asks for a breakdown.

What the markup actually buys the client is tier-one support, and that's the half the vendor pages leave out. The client can't call the vendor, because as far as the client knows there is no vendor. So the stalled send, the DNS change that didn't propagate, and the template rendering wrong in Outlook all arrive with you, on a surface you don't control and can't see into. You're quoting a resolution time against logs that belong to somebody else.

The arithmetic is what breaks it. The margin is real at three clients and thin at thirty, because the cost that grows isn't the licence. It's the number of times a person repeats the same setup by hand: same domain verification, same suppression import, same template deployment, different client. Rebranding the login screen doesn't reduce that count by one.

What you own when you leave.

Portability is three separate questions, and only one of them has a good answer. Contacts and suppression lists export cleanly, because they're rows and every platform imports rows. Templates and automations are held in the vendor's own format, so they get rebuilt rather than moved, and the rebuild is a project rather than an afternoon. Reputation is the piece that may not travel. It's scored per sending domain and per sending IP, so leaving a platform whose domain signed the mail, on whose shared IP pool it went out, restarts the warm-up whatever the list looks like, while reputation earned on a domain the client owns stays with that domain.

"Pick your forever platform" is advice that only makes sense if leaving is expensive, and it comes almost entirely from the people it's expensive to leave. The version worth acting on is quieter, which is to make leaving cheap while you still have the choice.

Here the earlier decision arrives with a bill attached. The exit is cheapest when the client's own domain was signing all along, because then the authentication records stay exactly where they are, the reputation stays attached to a domain nobody is giving up, and the migration is a template rebuild instead of a restart from zero. Sign everything with your own domain for three years and the client's list is portable while their delivery isn't.

A rebranded dashboard is still a dashboard.

Every white-label product is a dashboard with somebody else's logo on it. That isn't a criticism of any particular vendor, it's what the underlying product was built to be: a set of screens for a person clicking buttons, with a theming layer added later. Retrofitting an agent onto a dashboard-first product is bolting a motor onto a bicycle, and repainting the bicycle doesn't change the ride.

An agency's real constraint isn't branding. It's repetition across N clients, and a login screen carrying your logo doesn't reduce N by one. Nitrosend specializes in email, and it's MCP-first: every capability is an API endpoint and an MCP tool before it's a screen. That decides the white-label answer too: what's on offer here isn't a dashboard themed in your colours, it's separation where a mailbox provider looks for it, a sending identity and a list of its own for every client, and per-client sending you configure once and script from then on. Sending domains are added and DKIM-verified per client through the same API and MCP tools, contacts are unlimited on every plan, and BYO sending keys on Pro and above cover Amazon SES, Resend, Postmark, Mailgun, and SendGrid, so a client who wants their sending to stay in their own provider account can have exactly that. The commercial layer stays on your side of that line: Nitrosend prices the sending and carries no reseller billing, so the markup, the invoice, and the client relationship are yours to run.

If you're about to set up a tenth client the way you set up the first, the part worth automating is the setup rather than the branding. Nitrosend's free tier is 8,000 emails to start and then 500 a month, with unlimited contacts and the MCP server, API, and CLI all switched on, no card. Script one client's domains, lists, and templates through it, then see whether the same script holds for the next nine.

Related reading

• Email Deliverability Best Practices That Actually Matter
• Email Authentication Protocols: SPF, DKIM, DMARC, and BIMI
• How Do I Authenticate My Email? The Setup Steps

Sources

• RFC 6376: DomainKeys Identified Mail Signatures, the d= domain as the identity claiming responsibility for a message, and the _domainkey subdomain the public key is published under.
• RFC 7489: DMARC, and the requirement that the From domain be aligned with a domain authenticated by SPF or DKIM.
• Google, Email sender guidelines: the 5,000-a-day bulk-sender threshold, SPF, DKIM, DMARC published for the sending domain, one-click unsubscribe, and the 0.30% spam-rate ceiling.
• Google, Postmaster Tools dashboards: domain reputation and IP reputation as separate quality ratings, one for the domains a sender uses and one for the IP addresses.

Common questions