Treat the sending setup as a set of boundaries. Begin by deciding which traffic must remain healthy when another stream develops a deliverability problem, then size domains and mailboxes around the volume each boundary can carry. The strongest practical insight is that mailbox count is a risk decision before it is a capacity decision. Separating email types across subdomains can keep a problem in one type of mail from harming transactional traffic.1 That makes architecture a sequence: isolate streams, protect the primary namespace, assign mailboxes, then test whether the portfolio can carry the plan.
Map mail streams
Start with traffic, not inbox inventory. Write down what each address will send and which traffic can tolerate a deliverability problem.
Place transactional, marketing, and product generated email on different domains.2 Promotional and transactional email are often sent from different subdomains, which separates the reputations those streams build.3 If third party suppliers send mail for the organization, create a separate subdomain for each supplier.4
Give every namespace a clear owner and a clear purpose. A campaign, team, or sender should be able to tell which traffic shares its domain and which traffic stays elsewhere. Move on when you can describe the mail stream carried by each namespace without using a broad label such as "all outbound."
Protect the primary namespace
Use the primary namespace for traffic whose failure would spread into daily business communication. Give cold capacity its own domain boundary.
When more sending capacity is needed, buy another domain.5 Keep sending identities separate with separate email addresses,6 and send mail from different domains and/or IP addresses.7 This gives you a place to add capacity without placing every stream behind the same reputation.
Assign each secondary domain to a defined stream or campaign group. Record the domain, mailbox, sending identity, and campaign together so a problem can be traced to the traffic that caused it. Move on when adding a campaign does not require changing the namespace used by unrelated mail.
Set the mailbox count per domain
A domain should carry a deliberate mailbox load. More inboxes can raise capacity while concentrating failure on the same domain, so start with a bounded allocation.
Start with two to three mailboxes per domain.8 More than three per domain concentrates risk because a flagged domain can take those mailboxes out together.9 Treat this as a starting design that you adjust after checking the volume and the tolerance for disruption.
Map each mailbox to a team, sender, or campaign, and keep that mapping visible. Avoid placing several unrelated campaigns behind an address when you need to diagnose performance. Move on when every mailbox has a defined stream, a defined sending identity, and a domain that can be retired without taking unrelated traffic with it.
Size the portfolio against volume
Volume determines how much infrastructure you need. Calculate the portfolio before provisioning mailboxes, then compare the result with the amount of risk you are willing to place on each domain.
There is no single correct domain count because the right design depends on the goal.10 Use monthly prospect volume and emails per prospect to size domains and mailboxes; one operating model keeps properly warmed domains under 30 emails per mailbox per day.11 For 50,000 emails per month, a published benchmark uses 3 to 5 domains and 5 to 10 mailboxes.12
Use that benchmark as a planning reference, not as an automatic allocation. If the plan calls for more capacity, expand the portfolio and recalculate the load on every domain and mailbox.
Check the technical boundaries
A sound allocation can still fail when authentication and policy boundaries are shared carelessly. Review the DNS and policy scope after deciding the domain and mailbox layout.
Put email services you do not control on subdomains to protect the main domain's reputation and avoid exceeding the DNS lookup limit.13 For SPF, separate transactional, corporate, marketing, and other mail streams onto distinct namespaces; each discrete subdomain has its own ten lookup maximum.14
Check the scope of any domain based outbound policy before assigning senders to it. A Domains condition targets every organizational sender whose primary email address is in the specified accepted domain.15 Move on when the policy scope matches the traffic map and an unrelated sender cannot enter the namespace by accident.
Watch for concentration problems
Review the architecture through changes in performance, not only through delivery volume. A falling reply rate can point to the sending setup itself.
If reply rates collapse, inspect mailbox count and rotation before rewriting copy or targeting; infrastructure can be the cause.16 Compare performance by domain, mailbox, and stream so a problem has a location. Pause expansion while you isolate the affected boundary, then change the smallest part of the setup that explains the result.
What not to do
Keep these failure modes beside the provisioning plan:
- Do not open a domain with 8 to 10 new mailboxes all sending outbound simultaneously; that pattern can trigger abuse detection.17
- Do not add multiple email accounts to each domain without accounting for the risk of blacklisting and spam placement.18
- Do not assume a flagged domain affects only cold email; future transactional and personal email can suffer too.19
Use the stream map to assign domains and mailboxes before a campaign goes live. When performance changes, trace the problem through the same map and adjust the affected boundary without disturbing unrelated traffic.