Key takeaway
Running email for clients is one setup repeated, so the thing that breaks at ten clients isn't the writing. It's that client four was configured differently from client one and nobody wrote down why. Keep the process identical: onboarding, QA, approvals, reporting cadence. Keep the sending identity, the list and the consent record separate per client, because the 0.10% spam ceiling is measured per domain. That makes it the client's number and your problem, and I'd report it before anybody asks.
What running email for a client actually involves.
Email marketing for agencies means operating the channel on behalf of clients who own the list, the brand, and the consent record. You supply the process. The deliverable looks like campaigns, and the job is actually infrastructure: domains, authentication, list hygiene, approvals, and a report, repeated per client, on a schedule that doesn't care how the month went. Some variation between clients is unavoidable, and on its own it's survivable. What isn't is variation nobody recorded. At ten clients you aren't running one process with ten local exceptions, you're running ten processes, and there's no document anywhere that says what any of them is.
So the useful split isn't campaigns against automations. It's what has to be identical across every client and what has to stay separate. Identical: the onboarding steps, the QA checklist, the approval path, and the reporting cadence. Those are your product, and every one of them that varies by client is something you'll have to re-learn under pressure. Separate: the sending identity, the list, and the consent record. Those belong to the client, and pooling them is how one client's bad month becomes everybody's. I've been building email platforms for over a decade, and most of the agency deliverability calls I've sat in trace back to that line being drawn in the wrong place.
Most brands fail at email by simply not sending enough of it. The second failure mode is blasting the entire database without segmentation. I warned against this "spray and pray" tactic on Designwave. Sending to unsegmented lists without tracking engagement is a terrible idea. You will inevitably "burn that channel for your company" over the long term.
Give every client its own sending identity.
A sending identity is the domain in the From header plus the DNS records that vouch for it. Inbox providers judge that domain, not your agency and not the platform you bought.
- SPF: a DNS record naming which servers are allowed to send mail for the domain.
- DKIM: a signature on each message, checked against a public key in DNS, proving the mail wasn't altered on the way.
- DMARC: a policy record saying what a receiver should do with mail that fails the other two, and where to send the reports.
Agencies consolidate onto one domain because it's less work: one set of records, one warm-up, one thing to explain. It's the most expensive shortcut on this page. A single domain pools every client's reputation into one bucket, so the client who imported a three-year-old trade show list is now setting the delivery rate for the client who didn't. The requirements are per domain, too. Google's sender guidelines put anyone sending 5,000 or more messages a day to personal Gmail accounts under SPF, DKIM, a published DMARC record, and one-click unsubscribe, and ask that the spam rate in Postmaster Tools stay under 0.10% and never reach 0.30%. Yahoo asks for the same authentication, DMARC at p=none or stronger, a complaint rate under 0.3%, and unsubscribes honoured within two days. One-click isn't a link in the footer, either: RFC 8058 asks for a List-Unsubscribe-Post header alongside List-Unsubscribe, with the DKIM signature covering both.
The client small enough to have no DNS access at all, or the retainer where nobody can find who owns the zone file. The honest answer is to fix the access before the first send, not to sign their mail with your domain because that's quicker. That trade buys a month and charges the next client's placement for it.
Building for agencies means anticipating structural needs before users request them. We recently released agentic inboxes to handle complex multi-user setups. I spoke about this on The Breakout CEO and acknowledged we are not getting much user pull right now. No one building a 10 person startup is asking for "10 agent inboxes" yet. We shipped the feature anyway because we know it will be useful for scaling teams.
The onboarding run book.
The count is the point. Six steps, in this order, for every client, written down once and run identically whether the client is a law firm or a sneaker brand. A step that lives in somebody's memory is the step that gets skipped on the client who signed during a busy month, and it's never the same step twice.
- Collect the consent record and where the contacts came from, before anything is imported.
- Add and verify the client's sending domain, with SPF, DKIM, and DMARC on their DNS.
- Import and suppress: bounces, unsubscribes, and every address the client can't account for.
- Build the template set and the approval path, with named approvers rather than a job title.
- Send a small first campaign to the most recently engaged contacts, and read the result before raising volume.
- Agree the report and its cadence before the first send, not after the first bad month.
Nothing on that list is clever, which is why it survives contact with a busy quarter. The agency that treats onboarding as a conversation ends up with as many setups as it has clients: one where DMARC never got published, one where the old list went in whole, one where the approver left in March. None of them auditable, and all of them discovered on the day something goes wrong. So write the six steps as a checklist somebody can fail, put a name and a date against each one, and keep the finished checklists where the next person can read them. When a client asks in month nine why a send went the way it did, that file is the whole answer.
The run book assumes the client can answer the questions in it. A client who can't produce a consent record or name an approver isn't a step you tick, and the checklist's job there is to stop the onboarding rather than record that it happened anyway.
Deliverability is judged per client, not per agency.
Reputation attaches to the sending domain and the sending IP. It doesn't attach to your account, your agency, or the platform you bought. That's why the separation two sections up is worth what it costs you in setup time: one client's purchased list can't reach a neighbour's domain reputation when the two are signed by different domains, and it very much can when everything ships under yours. Separate domains don't separate the IP, though: on a shared pool every sender's activity moves the same IP reputation, so list provenance stays your problem whoever signs the mail.
Three things follow from that. The spam-rate ceiling is a per-domain measurement, so 0.10% is the client's number and your problem, and it belongs on the monthly report whether or not anybody asked for it. A new client domain is warmed rather than switched on: start with the contacts who engaged most recently, raise volume over days, and don't let a launch date decide the ramp. And a dedicated IP is a volume question rather than a quality one. A client that doesn't send enough to keep an IP warm every day can't hold a stable reputation on it, so a low-volume dedicated IP is a mistake in our view, and it makes placement worse rather than better. Most agency clients belong on a shared IP, and the ones that don't announce themselves by volume.
Authentication and warm-up buy delivery, not attention. A list that doesn't want the mail fails at much the same rate from a perfect setup as from a sloppy one, and no DNS record fixes a client who wants to email everyone who ever downloaded a PDF. That one is a conversation, not a configuration.
Deliverability drops sharply when clients try to reactivate old contacts for holiday sales. We see a massive volume spike every October and November. A merchant will often try to email a "dusty old list of a hundred thousand people" from four years ago, a classic scenario I described on In the Ring with SUMO Heavy. Hitting those addresses five times before Black Friday will destroy your sender reputation. The only safe move is to take that list out back and burn it.
Consent, liability, and which one you are.
In almost every agency arrangement the list belongs to the client and you operate it on their behalf. That isn't a description of who cares more. It's a thing to write down before the first import: whose data it is, what you may do with it, how long you hold it, and what happens to it the day the retainer ends. Agencies that never write it down find out the answer during an offboarding, which is the worst moment to be discovering it.
The paperwork question and the operational question have different answers, and agencies get caught assuming one covers the other. The contract says whose data it is. The mechanics say the unsubscribe has to work on the day it's clicked, and that an address which opted out never travels to another list, another client, or another platform. Yahoo asks bulk senders for two days. Build to two days and stop carrying a second number in your head.
The client who can't say where a list came from. That isn't a technicality to be papered over with a warranty clause. It's the best predictor there is of a complaint rate that takes a domain down, and the conversation is cheaper in week one than in month three, when you're explaining why their mail now lands in spam at three providers. Ask for the provenance of every list before you import it, and write the answer down next to the checklist.
How the account is held, and what you bill for.
Underneath the pricing conversation sits a structural question: whose account is it. The answer comes in three shapes, and they differ on who holds the contract, whose domain signs the mail, and who keeps the account if the relationship ends.
| Model | Holds the contract | Domain that signs the mail | Who keeps the account at exit |
|---|---|---|---|
| Client-owned | The client, who pays for it. | The client's own domain. | The client keeps the account and its history. |
| Agency-owned | You, and you rebill it. | The client's domain still. | The account stays with you. |
| White-label | You, and the platform carries your brand. | The client's domain. | Stays with you, as with agency-owned; the client never sees the vendor's name at all. |
The three differ on who absorbs the platform cost and who is exposed at renewal, and that's most of the commercial argument. Client-owned keeps your retainer clean and your leverage small. Agency-owned keeps the margin and hands you the bill when a client's list doubles, which is why contact-priced platforms hurt agencies in particular: the invoice grows with the size of the client's list while the retainer stays where it was signed. White-label email marketing sits at the far end, with your brand on the product and your name on the invoice. Where the account is agency-owned, the contact bill is the line that moves, and it's the one we price against: contacts are unlimited on every Nitrosend plan, including Free, so a client's list doubling doesn't rewrite your margin. BYO sending keys on Pro and above cover Amazon SES, Resend, Postmark, Mailgun, and SendGrid, which is the version of client-owned that leaves the sending in the client's own provider account while the process stays yours. An agency with the dev resources to run that setup sees the same saving a solo developer does: 70 to 80 percent off at scale, against a client-owned contract carrying a vendor's own markup.
None of the three shapes fixes a retainer priced before the client's list grew. Where the account sits decides who receives the invoice, not how big it gets.
Ten clients, and a setup that has to be a script.
The same operations repeat with one variable substituted, client to client. Same six onboarding steps, different client. Same domain verification, different DNS. Same monthly report, different numbers. That's the definition of a script, and it's being run by a person clicking through a dashboard, one client at a time.
Every platform built for this work was designed that way, which is fine at three clients and is the entire job at thirty. Retrofitting an agent onto a dashboard-first product is bolting a motor onto a bicycle: the interface still assumes somebody is in it choosing a client from a dropdown, and the automation stops wherever the vendor decided to stop. The six-step run book is six API calls per client. The monthly report is the same shape every month, and only the numbers move. Domain verification, suppression import, and template deployment are the same operation with a different argument each time. Nitrosend is MCP-first: every capability is an API endpoint and an MCP tool before it's a screen, so the script runs and you read the result.
The judgment doesn't automate. What to send, which client needs a phone call instead of a report, and whether a list should be mailed at all stay decisions a person makes and owns.
If your tenth client is going to be set up like your first, the setup has to be a script rather than a memory. 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 onboarding through it and see whether the same script holds for the next nine.
Managing multiple client accounts requires fast context switching. We built the architecture early to let users "switch between your other brands and do it all from your agent" without logging out. This approach is a massive time saver for agencies, a point I made on The Breakout CEO.
Go deeper
Sources
- Google, Email sender guidelines: the 5,000-a-day bulk-sender threshold, the SPF, DKIM, and DMARC requirement, one-click unsubscribe, and the 0.10% and 0.30% spam-rate numbers.
- Yahoo Sender Hub, best practices: Yahoo's authentication requirements, the DMARC policy minimum, the complaint-rate ceiling, and the two-day unsubscribe window.
- RFC 8058: Signaling One-Click Functionality for List Email Headers, the header pair behind one-click unsubscribe and the DKIM coverage it expects.
Common questions
By making the process identical and the accounts separate. The onboarding steps, the QA checklist, the approval path, and the reporting cadence should be the same for every client, written down as a checklist somebody can fail. The sending domain, the list, and the consent record stay separate per client, because that's what inbox providers and data-protection contracts are both looking at. Agencies that keep those two the other way round end up with as many setups as they have clients and no way to audit any of them.
Yes, in almost every case. Sender reputation attaches to the domain in the From header, so one shared agency domain pools every client's complaint rate, bounce rate, and list hygiene into a single number. One client's bad import then sets the delivery rate for the rest. Separate domains cost more setup time and contain the damage. The exception worth naming is the client with no DNS access at all, and the fix there is to get the access, not to send their mail from your domain.
Only if the client is meant to see your brand on the platform rather than the vendor's. White-label is one of three ways to hold the account, alongside client-owned (the client pays the platform and keeps it) and agency-owned (you pay and rebill). It changes who is exposed at renewal and who absorbs the platform bill, not how the email is authenticated or sent. Decide the commercial question first, because the sending setup is the same in all three.
The client, in almost every arrangement. They collected the contacts, the consent was given to them, and their brand is on the mail. The agency operates the list on their behalf. Write it into the contract explicitly, including what happens to the data when the engagement ends, because a list that has been living in an agency-owned account for two years is the most common thing to argue about at the exit.
Both, in different ways. The list is almost always the client's, and who may do what with it belongs in writing before the first import: whose data it is, what you may do with it, how long you hold it, and what happens at offboarding. That allocates the argument. It doesn't operate the unsubscribe link, verify the domain, or refuse a list nobody can account for, and those stay the agency's job on the day.
It depends on three things, and any number quoted without them is somebody else's business. The scope: strategy only, or production and sending, or the whole channel including automation and reporting. The send volume, because that drives the platform bill. And who holds the platform contract, since an agency-owned account means the bill grows with the client's list while the retainer doesn't. Price the platform cost separately from the work if the client's list is growing.
Usually not. A dedicated IP is a volume decision, not a quality one: it needs consistent traffic to build a reputation on, and a client that doesn't send enough to keep it warm every day tends to get worse placement rather than better. Most agency clients belong on a well-run shared IP with their own authenticated sending domain. The clients that genuinely need a dedicated IP make it obvious through send volume.
Delivery and reputation first, then engagement, then whatever the client is actually buying. That means the spam-complaint rate against the 0.10% ceiling Google publishes, bounce rate, unsubscribe rate, and any authentication change, followed by opens, clicks, and the revenue or pipeline the client cares about. Agree the shape of that report and its cadence before the first send. Adding deliverability numbers after a bad month reads as an excuse, and adding them at the start reads as competence.