Mailbox history and domain history overlap but are not identical
The new address benefits from an established domain context, yet it does not have its own recent sending behavior. Receivers can observe signals at several levels, including domains, IPs, authentication identities, and individual senders. Treat the additional mailbox as new operational capacity that must be introduced gradually. The mistake is assuming the domain’s prior 30-message pattern authorizes every new mailbox to start at 30 independently.
Set a domain-wide ceiling before mailbox caps
Define the total planned volume for the domain first, then allocate it across mailboxes. If the domain normally sends 30 and you want to introduce mailbox B, one conservative shape might be A=24 and B=6 rather than A=30 plus B=30. The exact numbers are not universal recommendations; the point is to keep the total pattern near the known baseline while the new mailbox proves authentication, queue behavior, and reply handling. Increase the domain envelope only after both identities behave normally.
Warm the new mailbox with real operational checks
Confirm the new mailbox can send authenticated mail, receive replies, and be read correctly over IMAP or the provider API. Send a small set of verified messages and inspect Authentication-Results. Check that the new mailbox uses the expected DKIM domain and Return-Path and that replies cancel follow-ups. A mailbox that passes DNS tests but cannot receive or classify responses is not ready for campaign volume.
Watch combined burst rate
Two workers can each obey a daily cap while sending at the same minute. If they both wake at 09:00 and drain ten messages, the domain-level burst can double even though the day total remains controlled. Stagger queues or use a shared domain scheduler so per-mailbox pacing composes into a smooth aggregate. Record actual timestamps across all mailboxes and compare them with the previous single-mailbox traffic shape.
Do not use the second mailbox to route around a bad signal
If mailbox A is being throttled or the domain shows deteriorating replies and bounces, adding mailbox B is not recovery. The shared domain or other identities may still carry the problem. Pause and diagnose before expanding capacity. A new mailbox is appropriate for scaling a healthy system, not for hiding a reputation incident behind another local part.
Reallocate before increasing
During the first several days, think of the second mailbox as taking a slice of existing domain volume. If B sends 5, reduce A by roughly that amount. Once B shows normal acceptance and replies and the domain has no new negative provider signals, raise the domain total in small steps. This creates an observable transition: you can tell whether problems began with the new mailbox configuration or with a domain-wide volume increase.
A two-week operating example
Suppose the established domain has been stable at 28 actual sends/day. Week one introduces B at 4–6/day while A drops to 22–24. Week two moves B toward 8–10 while A remains similar, keeping the domain around its former envelope. Only after the new mailbox shows clean authentication, no unusual provider deferrals, and reliable reply ingestion does the operator consider taking the domain beyond 28. The example illustrates sequencing, not a provider-approved safe limit.
Track capacity as a domain resource
Store planned and actual sends per mailbox plus a computed domain total. Add temporary retries to a separate attempt counter so a provider throttle cannot be hidden by campaign-only metrics. When a new mailbox is created, require an explicit domain allocation rather than defaulting to a global per-mailbox cap. This small data-model choice prevents accidental doubling every time the team adds an address.
Plan capacity at domain level before assigning a new mailbox quota
A second mailbox does not create a second independent domain reputation. It has its own account history and behavior, but recipients also observe shared identifiers such as the signing domain, visible From organization, links, and sometimes infrastructure. Before sending from the new account, write down the domain’s current accepted daily volume and peak hourly shape. Then allocate part of that existing envelope to the new mailbox instead of immediately adding the new mailbox’s target on top. This lets you observe the account without creating a simultaneous domain-level volume jump.
For example, if two established mailboxes together send a stable 60 messages on a normal day, a test week might shift a small slice—say 5 to 10 carefully selected messages—to the new mailbox while keeping the domain total near its recent range. The exact numbers are not universal limits; they are an experiment relative to your own baseline. Compare authentication, temporary deferrals, hard recipient failures, and real reply handling by mailbox. Only increase the domain ceiling after the new path behaves normally and list quality remains stable. If the reason for adding the mailbox was to escape deferrals on the old accounts, stop: capacity expansion should not be used to route around a sender-quality problem that already exists.
Keep mailbox ramp decisions reversible
Every increase should have a rollback target. If the new mailbox moves from 8 to 15 daily sends, note the previous stable level and the signals that justified the change. If provider-specific 4xx responses or bounce mix worsen, return to that known level instead of shutting down the entire domain or opening more mailboxes. Reversible steps keep the experiment interpretable. They also help separate a mailbox-specific setup issue from a list-wide problem, because only one variable—the new account’s allocation—needs to change during the rollback.
Field checklist
- Define a domain-level volume envelope before assigning mailbox caps.
- Introduce the new mailbox by reallocating existing volume first.
- Test authentication, reply ingestion and follow-up cancellation on the new address.
- Stagger workers so combined bursts do not double.
- Do not add a mailbox while the domain is already showing negative signals.
- Track planned and actual volume per mailbox and per domain.
Primary sources
Standards and provider policies can change. These links are the reference points used for this field note.
- Email sender guidelinesGoogle Gmail Help — Authentication, TLS, DNS, spam-rate and bulk-sender requirements.
- Gmail SMTP errors and codesGoogle Gmail Help — Temporary and permanent Gmail SMTP errors, including authentication and unusual-rate failures.
- Sender Requirements & RecommendationsYahoo Sender Hub — Yahoo authentication, complaint-rate, DNS, unsubscribe and flow-control requirements and recommendations.