Multi-mailbox setup — the bridge to authentication.

The premise

A registered domain at a configured registrar with hosted DNS is, from a sender's perspective, an inert asset. It accepts no mail, sends no mail, and produces no reputation signal. The mailbox provider — Google Workspace or Microsoft 365, in the scope of this reference — is the system that converts the domain into a sending entity, but only after a sequence of per-mailbox and per-domain configuration steps that bulk-creation tooling does not perform automatically.

For a 30-domain estate at 3 mailboxes per domain, the scope is roughly 90 mailbox provisions, 30 MX changes, 30 SPF additions, 30 DKIM key generations, 30 DMARC publications, 90 display-name and signature configurations, and 30 root-domain HTTP-response decisions. Compressed into a single sitting, the work is six to twelve hours. Spread across a week of partial sessions, it is the tier most likely to leave a domain half-provisioned and silently broken.

The 2-3 mailboxes-per-domain rule

Chapter 07 of the email cluster establishes the per-domain mailbox count: two to three sending mailboxes per domain is the ceiling that holds reputation intact across the major receivers. Four or more on a single sending domain begin to pattern-match against the bulk-sender signature that Gmail and Microsoft both penalize. One mailbox per domain produces inflated per-mailbox cost. The two-or-three rule is the equilibrium.

The operational implication is a fixed naming convention applied across the entire estate. The canonical pattern: three mailboxes per domain, three semantic roles, one mailbox per role:

founder@trybrand.com       founder@usebrand.com       founder@getbrand.com
sales@trybrand.com         sales@usebrand.com         sales@getbrand.com
partnerships@trybrand.com  partnerships@usebrand.com  partnerships@getbrand.com

The local-parts are selected for semantic legitimacy. founder@ reads as a real person; sales@ reads as a department; partnerships@ reads as a credentialed business function. Aliases that pattern-match as generated — outreach@, contact1@, info1@ — produce measurable reputation degradation at the major receivers and are avoided.

Mailbox naming consistency across domains

A subtler decision: should the same three local-parts repeat across all 30 domains, or should each domain carry its own variation? The empirical pattern is consistency. The same three local-parts repeated across all 30 domains is the configuration that holds reputation; varied local-parts per domain produce inconsistency that receivers, on aggregate, treat as suspicious.

The reasoning is mechanical: when a receiver observes the same local-part under 30 domains with consistent sending behavior, the receiver can treat the local-part itself as a stable identity signal. When the local-part varies per domain, no such cross-domain signal exists. The three local-parts selected at the start of estate procurement should propagate across every subsequent domain; mid-estate naming changes produce a discontinuity that takes weeks to recover.

Display-name configuration

The display name is the human-readable identity attached to each mailbox — the string that appears in a recipient's inbox before the email address. The canonical pattern: set the display name to the founder's real name across the founder@ mailboxes, and to a consistent first-name-plus-surname identity across the sales@ and partnerships@ mailboxes. The From: line then renders as Display Name <local-part@domain> — for example, Phillip An <founder@trybrand.com>. The display name is the field a recipient pattern-matches against; the email address is the field they ignore unless something is wrong.

A mailbox with no display name configured renders as the bare email address in most mail clients. This is the single most common configuration omission and produces an immediate reputation differential: receiver-side classifiers treat unnamed senders as lower-trust, and open-rate response is correspondingly lower.

Reply-to configuration

The Reply-To: header is the address a recipient's reply is routed to, independent of the sending address. The two configurations: leave Reply-To: unset (replies route to the sending mailbox), or set Reply-To: to a single corporate inbox that aggregates replies across the estate.

The threading implication is material. Replies to a sending mailbox accumulate there; the conversation history lives at the sending domain. Replies routed to a corporate inbox aggregate centrally and allow a single operator to triage 90 mailboxes' worth of reply volume, but the conversation history then lives at a domain the sender did not use to initiate. Mail clients may treat the transition as suspicious, particularly when the corporate domain does not share organizational identity with the sending domain.

The pattern that holds reputation: leave Reply-To: unset, aggregate replies via a mailbox-level forwarding rule that copies inbound mail to the corporate inbox while leaving the original thread intact at the sending mailbox. The recipient sees clean threading; the operator sees aggregated inbound in a single triage queue.

Email signature configuration at scale

The signature is the per-mailbox HTML block appended to outbound mail. Configured one mailbox at a time, the work is roughly three minutes per mailbox — call it 4.5 hours across 90 mailboxes. Configured via the provider's admin API with a templated signature and per-mailbox variable substitution, the work is 20 minutes of script-writing and one minute of execution.

The signature template carries four variables: the mailbox's display name, the title, the company name, and the company URL. The script iterates across the mailbox roster, substitutes the variables, and posts the result to the provider's admin API. The signature itself is intentionally lightweight — text, a single link, no images, no tracking pixels — because image-heavy signatures degrade deliverability at receivers that flag image-to-text ratios.

One pattern to avoid: the same signature, with identical text and identical link target, deployed across 90 mailboxes under 30 domains. Receivers that fingerprint signature content treat the exact-match repetition as a bulk-sender signal. The mitigation is per-mailbox variation in non-load-bearing fields — the title, the optional tagline, the order of social links — sufficient to break the exact-match fingerprint while preserving brand consistency.

SMTP-direct vs sending-platform-relay

The sequencing platform that drives the outbound estate connects to each mailbox via one of two modes: direct SMTP authentication against the mailbox provider, or relay through the platform's own sending infrastructure with the mailbox identity attached at the envelope.

SMTP-direct produces a sending IP at the mailbox provider — Google Workspace's SMTP relay or Microsoft 365's outbound MTAs. The platform authenticates against the mailbox, submits the message, and the provider sends from its own IP space. The reputation signal is the mailbox provider's reputation, which is generally high. Platform-relay produces a sending IP at the platform's own infrastructure; the platform signs DKIM with its own keys and attaches the mailbox identity only at the visible From: header. The reputation signal is the platform's shared-IP reputation, which is highly variable and typically lower.

For a cold-sending estate at the 30-domain tier, SMTP-direct is the configuration that holds reputation. The operational implication is per-mailbox credential management: every mailbox needs an app-specific password or OAuth token registered with the sequencing platform, and the credential set must rotate when any individual mailbox is suspended or recovered.

Custom tracking domains

Sequencing platforms insert tracking links into outbound mail to measure opens and clicks. The default behavior routes those links through the platform's shared tracking domain — a single domain every customer shares. Receivers that observe large volumes of mail across many sending domains, all linking to the same endpoint, treat the shared tracking domain as a bulk-sender signature.

The mitigation is a custom tracking domain per sending domain: a CNAME record at the sending domain — typically track.trybrand.com — pointing to the platform's tracking infrastructure. The link then appears, from a receiver's perspective, native to the sending domain. One custom tracking domain per sending domain holds reputation; shared tracking domains across an estate are observably destructive at the volume tier where receivers fingerprint cross-domain link patterns.

The MX-record configuration

The MX record at each sending domain points the domain's inbound mail at the mailbox provider. Google Workspace and Microsoft 365 each publish their canonical MX record set; the configuration is a copy of those records into the DNS zone of each sending domain, with the relative priorities preserved.

The verification workflow at both providers is the same: domain ownership is established via a TXT record at the root, the MX records are pointed at the provider, and the provider runs a periodic check that confirms inbound mail to the domain reaches the provider's ingress. Until that check passes, the mailboxes cannot receive inbound mail, which means reply traffic is silently dropped at the recipient's sending MTA.

The common failure mode: the operator provisions the mailbox, configures the display name and signature, attaches the mailbox to the sequencing platform, and begins sending — without verifying that MX is correctly pointed. Outbound sends successfully because outbound does not depend on MX. Inbound fails silently at the MX lookup. The operator discovers the misconfiguration days or weeks into warmup, when the absence of reply traffic becomes statistically distinguishable from low reply rates.

The handoff to authentication

The mailbox infrastructure is provisioned, named, signatured, and pointed at the sending platform. The next configuration tier is the authentication record set — SPF, DKIM, and DMARC — covered in Chapters 01 through 04 of the cold email infrastructure reference.

The handoff is mechanical. SPF authorizes the sending platform's IP ranges and the mailbox provider's SMTP relay against the sending domain. DKIM publishes the signing public keys generated by the mailbox provider into the sending domain's DNS, with selector names dictated by the provider. DMARC publishes the policy contract that ties SPF and DKIM alignment to the visible From: header. Each authentication record references the now-provisioned mailbox infrastructure; without it, the records have nothing to authorize.

The redirect-or-park-page configuration

The final wiring is the root-domain HTTP response. A registered domain that resolves to no HTTP endpoint, or to a registrar-default park page, produces a negative reputation signal at any receiver-side classifier that probes the domain. The mitigation: a 301 redirect from the sending domain's root to the corporate domain, or a minimal static landing page at the sending domain's root.

The 301 redirect is the lighter option — a CNAME or A record plus a redirect rule, deployed once across all 30 domains with identical configuration. The minimal static landing page is higher-effort but produces a stronger signal: a recipient who hovers over the sending domain sees a real branded page rather than an instantaneous redirect, which produces a measurable click-through differential.

The pre-warmup verification

Before warmup begins, the entire stack — domain, DNS, mailbox, authentication, tracking domain, MX, root-domain response — needs to be verified end-to-end. Chapter 13 of the email cluster covers the inbox-placement test; the pattern is to run one placement test per sending mailbox before adding it to the warmup pool.

The placement test sends a single message from the sending mailbox to a curated list of seed accounts at Gmail, Microsoft 365, Yahoo, and the major enterprise providers, and reports the placement result — inbox, promotions, spam, or missing — per receiver. A mailbox that fails placement at any major receiver pre-warmup has a misconfiguration somewhere in the stack; the diagnostic order is authentication records first, then MX, then tracking domain, then root-domain response. A mailbox that passes placement at every major receiver is the operational target. The warmup pool — Chapter 09 of the email cluster — accepts only mailboxes that have cleared this gate.

Documentation and runbooks

The operational record of the estate is itself an artifact. The minimum-viable documentation set: a spreadsheet of every mailbox (domain, local-part, display name, provider, signature template ID, sequencing platform attachment, custom tracking domain, warmup status); a per-domain DNS record manifest (SPF, DKIM selectors, DMARC, MX, tracking-domain CNAME, root-domain redirect); and a credential rotation runbook covering re-issuance of an app-specific password or OAuth token when a mailbox is suspended.

The credential rotation runbook is the artifact most operators omit and eventually need. Recovery of a suspended mailbox — at either provider — is roughly 30 minutes of admin work plus a placement re-test. Without a runbook, the procedure is discovered incrementally under time pressure; with one, recovery is repeatable and institutional knowledge survives operator turnover.

Common operator failures

• Inconsistent mailbox naming across domains. The operator selects founder@ on the first ten domains, switches to ceo@ on the next ten, and reverts on the final ten. The cross-domain signal that consistent naming produces is lost; each domain accumulates reputation from zero.
• Missing display names. The admin console leaves the display-name field empty unless explicitly set. Mailboxes provisioned via bulk-creation tooling inherit the default. The From: line renders as the bare email address; open-rate degradation is immediate.
• No reply-to strategy. The operator never makes the explicit decision between leaving Reply-To: unset and aggregating to a corporate inbox. Most sequencing platforms default to a platform-tracked address, producing both threading discontinuity and an additional cross-domain reputation signal.
• Shared tracking domains. The operator skips the custom-tracking-domain step and accepts the platform's default. Receivers treat the shared endpoint as a bulk-sender signature; the entire estate carries the penalty.
• MX misconfiguration. The MX record is omitted, partially configured, or pointed at the wrong provider. Outbound sends; inbound fails silently. Reply traffic is dropped; the absence is misattributed to low reply rates rather than to MX failure.
• Authentication-without-mailbox-provisioning. The operator publishes SPF, DKIM, and DMARC against a domain with no functioning mailbox infrastructure. The records validate against nothing; the first outbound send fails authentication at every receiver. Observable at the pre-warmup placement test.

Pre-warmup checklist

• Two to three mailboxes per domain provisioned, with consistent local-part naming across the estate
• Display name configured per mailbox, matching the sending identity
• Reply-to strategy explicitly chosen (unset with forwarding rule, or set to corporate aggregation)
• Signature deployed per mailbox via templated bulk deployment, with per-mailbox variation sufficient to break exact-match fingerprinting
• SMTP-direct integration with the sequencing platform, per-mailbox credentials registered
• Custom tracking domain configured per sending domain (CNAME at track.trybrand.com per the platform's instructions)
• MX records pointed at the mailbox provider, ownership verification cleared, inbound mail confirmed reaching the mailbox
• SPF, DKIM, and DMARC published against the sending domain (per Chapters 01–03 of the email cluster)
• Root-domain HTTP response configured (301 redirect or minimal static page)
• Inbox-placement test cleared at every major receiver, per mailbox (per Chapter 13 of the email cluster)
• Documentation set complete: mailbox roster, DNS manifest, credential-rotation runbook

Where this fits

This chapter is the bridge between procurement and authentication. The preceding six chapters cover what to buy — domains, registrars, DNS hosting, mailbox providers — and the workflow of buying it. The cold email infrastructure reference picks up at the authentication layer, with SPF, DKIM, DMARC, MTA-STS, and the receiver-side compliance regime the authentication records produce.

The estate that emerges from this chapter is operational. The next tier — the authentication record set — references this infrastructure. Without it, the records have nothing to authenticate. With it, the estate is ready for the warmup pool.