If you are building an AI SDR, the agent is the part that demos well and the sending substrate is the part that decides whether it works. Winnr is that substrate: an API that buys domains, provisions mailboxes with full DKIM, SPF, and DMARC, warms them, and hands your agent SMTP credentials. Size the fleet by dividing daily sends by 10 to 20 per mailbox and mailboxes by 5 per domain. Solve the onboarding cold start with a pre-provisioned buffer or the pre-warmed marketplace, because warmup takes two to four weeks and no amount of engineering removes that. Then decide whether tenants share a domain pool or get dedicated domains. All of it is one API surface.
Winnr sits underneath a growing number of AI SDR products. We see the same pattern often enough to write it down: a team ships a genuinely good agent, gets customers, and then discovers that the hard operational problem is not reasoning quality. It is that 40 customers each need their own authenticated sending domains, their own warmed mailboxes, and their own reputation that does not contaminate anyone else's. This is a guide to that layer, written for the engineers building on top of it. It covers the sizing math, the cold-start problem at onboarding, the two architectures that work, and the exact API calls.
The Part of an AI SDR Nobody Demos
An AI SDR demo shows the agent researching a prospect, drafting a personalized opener, and queueing a sequence. It is impressive, and it is the part of the stack that is commoditizing fastest. Frontier models keep getting better at the reasoning, and every team building in this space has access to the same models.
What does not commoditize is whether the message arrives. An agent that writes a brilliant email into a spam folder has produced nothing. And the failure is quiet: there is no exception, no error rate, no alert. Sends succeed, the dashboard is green, and reply rates just quietly sit near zero while everyone debugs the copy.
The gap is structural. Agent quality is a function of the model and your prompts, and it improves in days. Sending reputation is a function of domain age, authentication, warmup history, per-mailbox volume, and recipient engagement, and it improves in weeks. Those two clocks do not run at the same speed, and the second one is the one your customers experience as "does this product work."
Agents scale message volume the instant a customer turns them on. Infrastructure reputation does not scale on that timeline. Every AI SDR deliverability incident we have helped debug traces back to the same root cause: sending volume that arrived faster than the sending identities were ready for. Design your onboarding so a customer physically cannot outrun their warmup.
The Capacity Math
Start from the number your customer cares about: emails per day. Two constants convert it into infrastructure.
10 to 20 cold sends per mailbox per day. Not because of a technical cap, but because Google and Microsoft evaluate reputation per sending identity, and a new-ish mailbox pushing 50 cold emails a day looks like exactly what it is. Stay at the low end for a fresh fleet and the high end for a mature one.
5 mailboxes per domain. Winnr allows up to 10, and the extra headroom is genuinely useful for a mature domain. Five is the number to plan with, because it keeps the blast radius of any single domain incident small.
| Customer sends/day | Mailboxes | Domains | Warmup lead time | Infra cost/mo |
|---|---|---|---|---|
| 100 | 7 | 2 | 2 to 4 weeks | ~$25 |
| 250 | 17 | 4 | 2 to 4 weeks | ~$40 |
| 500 | 33 | 7 | 2 to 4 weeks | ~$60 |
| 1,000 | 67 | 14 | 3 to 4 weeks | ~$120 |
| 2,500 | 167 | 34 | 4 weeks | ~$280 |
Cost assumes a Winnr plan plus $1 per extra mailbox, $0.60 per mailbox for warming, and one-time domain registrations amortized. The headline number worth internalizing: a customer sending 500 emails a day costs you roughly $60 a month in infrastructure. If you are charging AI SDR prices, the sending layer is not your cost problem. Getting it wrong is.
Two planning notes. First, warmup lead time is not a function of fleet size, so a 34-domain fleet and a 2-domain fleet both take about the same wall-clock time to become production-ready. Second, size for peak day, not average day. Sequences are bursty, and a fleet sized to the average will push individual mailboxes past their daily ceiling on the peak.
The Cold-Start Problem
Here is the constraint that shapes an AI SDR business more than any other: a customer signs up today and wants to send tomorrow, but new mailboxes need two to four weeks of warmup first.
Every team building in this space hits this wall during onboarding. There are exactly three honest ways through it, and one very tempting way that does not work.
The tempting option is to skip warmup and send anyway, on the theory that low initial volume is self-limiting. It is not. A brand-new domain with no sending history that starts cold-emailing strangers is the single clearest spam signal there is, and the damage lands on the domain, which means you cannot undo it by slowing down afterwards. You will burn the domain in week one and spend more time replacing it than warmup would have taken.
Two Architectures: Shared Pool vs Dedicated Domains
Once onboarding works, the structural question is how sending domains map to customers. This is the decision that determines whether one tenant's behavior can hurt another, so it is worth making deliberately rather than discovering later.
Shared pool: generic domains you own
You register a pool of neutral domains and allocate mailboxes from it to customers as they sign up. Your application maps mailboxes to tenants.
- Good for: high-velocity self-serve signup, free trials, and any tier where a customer is not paying enough to justify their own domains.
- Why it is fast: capacity is fungible, so a new customer draws from inventory that is already warm instead of waiting on a fresh warmup cycle.
- The real cost: tenants share domain reputation. One customer importing a bad list degrades delivery for everyone else on that domain, and you cannot undo it per tenant.
Dedicated: each customer's own domains
Every customer gets domains registered for them, usually variations on their own brand, with mailboxes only they use.
- Good for: paying tiers, enterprise deals with isolation requirements, and anyone whose recipients should see their brand in the From address.
- Why it is safer: a deliverability incident stops at that customer's domains. Nothing crosses tenants.
- The real cost: a warmup cycle per customer at onboarding, which is exactly the cold-start problem above, and more domains to track.
Most teams end up running both: shared pool for trials and entry tiers, dedicated domains from the first paid tier upward. The principle underneath the choice is worth stating plainly, because it is the thing people get backwards: sender reputation follows the domain, not the customer record in your database. Two tenants you consider fully separated are not separated at all if they send from the same domain, and two tenants in the same row of your billing table are properly isolated if their domains differ. Tag domains with your internal tenant ID at purchase time and let the domain boundary be the tenant boundary.
Provisioning in Code
The whole flow is a handful of calls against https://api.winnr.app. Authentication is a bearer token scoped to an account.
1. Mint a token. Store the returned wnr_ value as a secret. Every later call is scoped to the owning account, so you never pass an account ID around.
curl -X POST https://api.winnr.app/v1/auth/tokens \
-H "Authorization: Bearer YOUR_EXISTING_TOKEN" \
-H "Content-Type: application/json" \
-d '{"name": "ai-sdr-provisioner", "permissions": ["read", "write"]}'2. Buy domains. Use async for anything above two or three domains so you are not holding a request open through registration. You get a job back immediately.
curl -X POST https://api.winnr.app/v1/domains/purchase \
-H "Authorization: Bearer $WINNR_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"async": true,
"domains": [
{"domain": "acmegrowth.com", "tags": ["tenant:acme"]},
{"domain": "acmereachout.com", "tags": ["tenant:acme"]}
]
}'Winnr registers each domain, creates the DNS zone, and writes MX, SPF, DKIM, and DMARC. There is no DNS work on your side. Tag domains with your internal tenant ID at purchase time and every later query can filter by it.
3. Poll the job. Registration is not instant, and this is the right place to drive a progress indicator in your onboarding UI.
curl https://api.winnr.app/v1/jobs/JOB_ID \
-H "Authorization: Bearer $WINNR_TOKEN"4. Create mailboxes. Up to 500 per request, all on one domain, so loop per domain. Let your agent generate the personas, since names that match the customer's actual team read better than sales1 through sales5.
curl -X POST https://api.winnr.app/v1/email-users/bulk \
-H "Authorization: Bearer $WINNR_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"domain": "acmegrowth.com",
"users": [
{"username": "dana.reyes", "name": "Dana Reyes"},
{"username": "m.okafor", "name": "Michael Okafor"},
{"username": "priya.n", "name": "Priya Nair"}
]
}'5. Start warming. The async variant takes up to 500 mailbox IDs per call and does not block. Use slow ramp-up for a fresh domain.
curl -X POST https://api.winnr.app/v1/warming/enable-async \
-H "Authorization: Bearer $WINNR_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"user_ids": ["eu_abc123", "eu_def456", "eu_ghi789"],
"settings": {"emails_per_day": 20, "rampup_speed": "slow"}
}'6. Hand credentials to the sending layer. GET /v1/email-users returns mailboxes with SMTP and IMAP details and passwords, filterable by domain. If your customers plug into an existing sequencer instead of your own sender, POST /v1/export emits a CSV in that tool's exact import format.
curl "https://api.winnr.app/v1/email-users?filter[domain]=acmegrowth.com" \
-H "Authorization: Bearer $WINNR_TOKEN"That same six-call sequence covers both architectures. For the dedicated model, run it once per customer with their branded domains and the tenant tag from step 2; for the shared pool, run it against your own domain inventory ahead of demand and assign mailboxes at signup. Filtering any later query by tag gives you per-customer usage without a second bookkeeping system.
Winnr publishes an MCP server that exposes this same API as tools, so an agent can size and provision its own infrastructure rather than calling a service you wrote around it. Full REST reference is at app.winnr.app/docs.
Isolation and Blast Radius
Multi-tenant sending has one failure mode that matters more than the rest: one customer's behavior degrading another customer's delivery. A single tenant importing a stale purchased list will generate bounces and complaints, and you need that damage to stop at their boundary.
Reputation is evaluated at several levels at once, and they are not equally shared:
- The registered domain. The primary unit. Blocklists list domains, and a burned domain takes its mailboxes with it. This is the boundary you control, and it is why the domain layout is the isolation decision that actually matters.
- The mailbox. Each sending identity carries its own engagement history. Five mailboxes on a domain share the domain's fate but build individual histories.
- The sending IP. Shared across tenants on standard plans, which is normal and fine, because reputable providers weight domain reputation far more heavily than IP for low-volume cold sending. If a customer needs a hard IP boundary, dedicated IPs are $20 per month.
The practical rules that follow: never let two tenants share a sending domain, treat 5 mailboxes as the blast radius you are willing to lose in one incident, and enforce list hygiene at your application layer rather than hoping infrastructure absorbs it. Infrastructure cannot fix a bad list, and an AI SDR that sources its own contacts is entirely capable of generating one.
Keeping the Fleet Healthy
A mailbox fleet is not a thing you provision once. It is inventory with a lifecycle, and the teams that run this well treat it that way.
Replace burned domains rather than rehabilitating them. When a domain's placement degrades badly, retire it. Reputation damage attaches to the registered domain, and a replacement costs a few dollars plus a warmup cycle, which is almost always cheaper than the weeks of reduced sending that rehabilitation requires. Budget domain replacement as a normal operating cost.
Keep warming on in production. Warmup is not only an onboarding phase. Continuous low-volume warming traffic maintains engagement signal on mailboxes whose real campaigns are bursty, which matters because a mailbox that sends 200 emails on Monday and nothing until Thursday looks stranger than one with a steady baseline. At $0.60 per mailbox per month this is the cheapest insurance in the stack.
Rotate rather than concentrate. Spread a campaign across the whole fleet instead of exhausting mailbox one before touching mailbox two. Most sequencers do this natively; if your agent is sending directly, implement it deliberately.
Monitor placement, not just delivery. Accepted by the receiving server and landed in the inbox are different outcomes, and only the first shows up in SMTP responses. Track reply rate per domain as your leading indicator: it falls before anything else in your telemetry does. A domain whose reply rate halves week over week is telling you something no bounce metric will.
Build vs Buy, Honestly
You could build this. It is not secret technology. You would need mail servers with correctly configured MTAs, IP allocation with clean reputation and proper reverse DNS, automated DNS across registrars, DKIM key management per domain, a warmup network with real mailboxes exchanging real messages, bounce and complaint handling, blocklist monitoring, and someone who owns all of it when Google changes bulk sender requirements again.
The honest case for building it yourself: at very large scale the unit economics eventually favor owning the stack, and if deliverability infrastructure is your actual product rather than a dependency, you should own it.
The honest case against: it is six to twelve months of specialized work that is entirely orthogonal to the thing your customers are buying. Nobody chooses an AI SDR because its vendor operates its own mail servers. They choose it because it books meetings. Every month spent on MTA configuration is a month not spent on the agent.
For context on the scale that goes into operating this properly, Winnr runs DNS, authentication, warming, and reputation monitoring per domain across a fleet in the tens of thousands of mailboxes. That is the surface area you would be taking on, and it never stops needing attention.
Frequently Asked Questions
What email infrastructure does an AI SDR actually need?
Authenticated sending domains that are not the company's primary domain, a pool of mailboxes across those domains at roughly 5 per domain, full DKIM, SPF, and DMARC on each, two to four weeks of warmup before production volume, and SMTP plus IMAP credentials the agent can send and read replies through. The AI reasoning layer needs none of this to function, which is exactly why it gets underestimated until inbox rates fall.
How many mailboxes does an AI SDR need per customer?
Divide target daily sends by 10 to 20. A customer sending 200 a day needs roughly 10 to 20 mailboxes across 2 to 4 domains; 1,000 a day needs roughly 50 to 100 mailboxes across 10 to 20 domains. The binding constraint is per-mailbox daily volume rather than total capacity, because reputation is tracked per sending identity.
How do you avoid making every new customer wait weeks for warmup?
Keep a pre-provisioned buffer of warmed mailboxes ahead of demand, buy from the pre-warmed marketplace where domains are aged and already warming, or run a hybrid that seats the customer on pre-warmed capacity while their branded domains warm in the background. The one approach that does not work is skipping warmup, because the damage lands on the domain and cannot be undone by slowing down afterwards.
Should each customer get their own sending domains or share a pool?
Give each customer dedicated domains when they are paying, when their recipients should see their brand in the From address, or when an incident must not cross tenants. Use a shared pool of generic domains for trials and entry tiers, where already-warm fungible capacity means instant activation. Most teams run both, and the deciding principle is that reputation follows the domain, so the domain boundary is the real tenant boundary.
Can an AI SDR platform white label Winnr?
Yes. On request, Winnr will set up a dedicated mail server on a hostname you control, so the IMAP and SMTP endpoints your customers connect to are branded as yours rather than Winnr's. Put that together with sending domains registered in each customer's own name and the entire stack reads as your product, with nothing customer-facing pointing back at Winnr. Most platforms also drive provisioning through the API and never surface a Winnr interface to their users. Talk to us about the mail server hostname when you are ready to set it up.
What happens when a sending domain gets burned?
Retire and replace it. Damage attaches to the registered domain, and rehabilitation usually costs more sending time than a replacement plus a fresh warmup cycle. This is the argument for many small domains over few large ones: the blast radius of any incident is 5 mailboxes, and recovery is a purchase call plus a warming call.
Does Winnr send the emails, or does the AI SDR?
Winnr provides mailboxes, domains, authentication, and sending infrastructure. Your agent decides who to contact, writes the message, and sends through the SMTP credentials Winnr issues. Winnr does no lead sourcing, copywriting, or sequencing, so it composes with whatever agent framework, data provider, and sequencer you already use instead of competing with them.
How much does the infrastructure cost?
Plans start at $69/month for 50 mailboxes and 10 domain slots, or $189/month for 200 mailboxes and 40 domain slots. Extra mailboxes are $1 each per month, domains are a one-time $1 to $10 depending on TLD or free if you bring your own, and warming is $0.60 per mailbox per month. A customer sending 500 emails a day runs roughly $60 per month all in.
Can the agent provision its own infrastructure?
Yes. The Winnr MCP server exposes the same API as agent tools, so an agent can size a fleet, buy domains, create mailboxes, enable warming, and read back credentials on its own. Teams typically start with a service wrapper around the REST API and move to agent-driven provisioning once the sizing logic is stable.
Putting It Together
The agent layer of an AI SDR is where the visible innovation happens and where every team is racing. The sending layer is where the product quietly succeeds or fails, and it runs on a slower clock that no amount of model improvement speeds up. Size the fleet from daily volume with two constants, solve the onboarding cold start with buffered or pre-warmed capacity before you need it, isolate tenants at the domain level rather than the account level, and treat domains as inventory with a lifecycle rather than a one-time setup. Winnr handles the registration, DNS, authentication, warming, and reputation work behind one API so your team can spend its months on the agent instead of on mail servers.
Related reading: build a personal pipeline with Claude Code and Winnr, go deeper on embedding email infrastructure in your app, see the MCP server for agent-driven provisioning, size a fleet with the cold email inbox calculator, understand pre-warmed mailboxes, or review how to scale cold email.