Subdomain architecture — the reputation firewall between corporate and outbound.

The central premise

A corporate organizational domain — the registrable label and public suffix, example.com per RFC 7489 §3.2 — has a single reputation identity across mailbox providers. That identity is fungible from the receiver's perspective. Mail from founder@example.com, mail from reports@example.com, and mail from a marketing platform signing under example.com all contribute to, and draw from, the same reputation pool at Gmail, Yahoo, Outlook, Apple, and every enterprise tenant.

The consequence is operational. A cold-outreach campaign that produces, over a week, a complaint rate of 0.6% and a hard-bounce rate of 8% — both unremarkable numbers for an undisciplined first-time sender — degrades the deliverability of every transactional, marketing, and corporate flow on the same organizational domain. Password-reset emails routed through a SaaS authentication provider begin landing in spam. Billing notifications degrade from primary placement to promotions. The CEO's reply to a board member is silently quarantined at the recipient's exchange tenant. None of those flows have anything to do with the cold campaign — but the reputation system at the receiver does not distinguish between them.

A founder who runs cold outbound from the corporate primary has not chosen to risk the deliverability of the cold outbound. They have chosen to risk the deliverability of every email the company will ever send, in exchange for not provisioning a second domain. The risk-reward asymmetry is severe and one-directional.

The two-tier architecture

The correct configuration separates corporate mail and cold-outbound mail at the organizational-domain level, not the subdomain level. A representative deployment for a company operating as example:

Corporate tier      example.com           transactional, marketing, internal mail
Sending tier        tryexampleco.com      cold outbound, mailbox 1
                    useexampleco.com      cold outbound, mailbox 2
                    getexampleco.com      cold outbound, mailbox 3
                    exampleco.co          cold outbound, mailbox 4
                    exampleco.io          cold outbound, mailbox 5
                    ...

The corporate root sits at example.com, with its standard authentication record set, its existing transactional and marketing flows, and its DMARC policy escalating toward p=reject on the timeline appropriate to its audit surface. The sending tier sits on a population of distinct organizational domains — each one a separate registrable label, each one with its own complete authentication record set, each one with its own DMARC policy, each one accruing its own reputation independently.

When a single sending domain in the tier accumulates a complaint pattern, the reputation damage is contained to that domain. The corporate root is untouched. The other sending domains in the tier are untouched. The damage is recoverable — the affected domain is rested, retired, or rehabilitated — without exposing any flow outside the domain itself.

Why "subdomain" is a misnomer

The architecture is colloquially called subdomain isolation, and the colloquialism is misleading. A subdomain — mail.example.com, outbound.example.com, sales.example.com — does not isolate reputation from the parent organizational domain. It shares it.

The organizational-domain concept defined in RFC 7489 §3.2 is exactly this: receivers identify the organizational domain by stripping subdomain labels until what remains is the registrable label plus the public suffix. mail.example.com and outbound.example.com and bare example.com are all the same organizational domain. Reputation is scored at the organizational-domain layer at the major providers — no public documentation confirms this for every provider, but the empirical signal in seed testing is consistent across Gmail, Outlook, Yahoo, and Apple: a complaint pattern at any subdomain measurably degrades placement of mail sent from any other subdomain on the same organizational domain.

True isolation requires a separate organizational domain. mail.example.com is not isolated. exampleco.com is. The distinction is not pedantic — it is the entire purpose of the architecture.

The lookalike-domain selection pattern

A sending tier composed of arbitrary unrelated domains is unworkable. Recipients verify sender identity by inspecting the visible domain, and an unrelated domain — contactnow.com, outbound247.com — reads as obvious spam infrastructure. Replies routed to an unfamiliar domain produce confused-recipient bounces and a non-trivial complaint rate driven entirely by sender-identity ambiguity.

The selection pattern that operates as a tier is the lookalike — a registrable label that visually and semantically maps to the corporate brand without being a literal copy:

Prefix pattern      try{brand}.com      use{brand}.com      get{brand}.com
                    join{brand}.com     hello{brand}.com    {brand}hq.com
Suffix pattern      {brand}.co          {brand}.io          {brand}co.com
                    {brand}app.com      {brand}team.com     {brand}mail.com

The trademark and typosquatting considerations are real but bounded. A lookalike domain operated by the brand itself, registered to the operating entity, redirecting to the brand's corporate site, is not typosquatting under any meaningful enforcement framework. The risk surface is the inverse — a competitor or a phishing operator registering the lookalikes the brand failed to register. The sending tier provides partial defense by occupying the most obvious lookalike slots. A domain that redirects to the corporate primary and sends mail with the corporate brand carries no UDRP exposure; one that resolves to a competitor's product does.

TLD reputation

The choice of top-level domain has a measurable effect on cold-start placement, smaller than the effect of authentication, smaller than the effect of warmup, but consistent and non-zero. Seed-list testing across Gmail, Outlook, Yahoo, and Apple consumer accounts, against new domains in their first 30 days of sending, surfaces the following empirical pattern:

.com                baseline                most reputation-neutral, lowest cold-start friction
.co                 -3% to -8% placement    visibly newer TLD, modest cold-start penalty
.io                 -5% to -12% placement   strong tech association, penalized in some enterprise filters
.net                -2% to -5% placement    aged TLD, neutral, occasional legacy-filter rules
.org                -10% to -20% placement  non-profit association produces filter friction for B2B outbound
.dev                -8% to -15% placement   newer gTLD, inconsistent across providers
.new gTLDs          -15% to -40% placement  heavily abused, several on enterprise blocklists by default

The differential is small relative to dominant factors — authentication, warmup, content, and complaint discipline produce placement swings of 30 to 70 points. The TLD differential is at most a 5-to-15-point variance and shrinks once a domain accumulates 60 to 90 days of clean sending history. But on the cold-start curve — the first three to four weeks of a domain's sending life, the highest-friction window for placement — the TLD choice is a free optimization. A tier composed primarily of .com domains, with .co as fallback when the preferred .com lookalikes are unavailable, is the cleanest default. The novel and abused gTLDs — registered for under $2 with no verification — are categorically unusable; several appear on enterprise blocklists by default.

Sending-domain count — the math

A single sending domain hosts a small number of mailboxes. The operational ceiling is roughly 2 to 3 mailboxes per domain — beyond which per-domain volume becomes detectable as bulk sending infrastructure, IP-level concentration produces cross-contamination across the mailboxes on the same domain, and a complaint pattern on one mailbox damages the others on the same registrable label. A single mailbox in steady-state operation supports roughly 30 to 50 sent messages per day. Higher volumes are achievable in the lab; in production, the engagement curve required to sustain placement caps daily volume below 50 per mailbox.

The math compounds. An SDR organization with 30 reps, each targeting 80 to 100 prospects per day, requires roughly:

30 reps × 80 sends/day                  = 2,400 sends/day target volume
2,400 / 30 sends/mailbox/day            = 80 mailboxes minimum
80 / 2.5 mailboxes/domain               = 32 sending domains

The result — 32 distinct organizational domains for a 30-rep SDR org — is the order-of-magnitude reality of professional cold outbound at scale. The inbox-calculator at the top of this reference computes the exact figure for a given target volume and per-rep allocation; the figure scales linearly with rep count and roughly linearly with volume per rep.

A founder running outbound from a single mailbox on the corporate primary is not operating at 1/32nd the scale of a professional operator. They are operating at 1/32nd the scale with 32 times the reputation exposure per failure, which is the exact opposite of the scaling property anyone would design for.

DNS architecture within the sending tier

Each sending domain in the tier is a self-contained authentication estate. The complete record set on a single sending domain looks approximately like this:

tryexampleco.com.                IN  MX     10 mx1.sending-platform.example.
                                  IN  MX     20 mx2.sending-platform.example.
tryexampleco.com.                IN  TXT    "v=spf1 include:_spf.sending-platform.example. -all"
selector1._domainkey.tryexampleco.com.  IN  TXT    "v=DKIM1; k=rsa; p=MIIBIjANBg..."
_dmarc.tryexampleco.com.         IN  TXT    "v=DMARC1; p=reject; rua=mailto:rua@reports.example.com"
_mta-sts.tryexampleco.com.       IN  TXT    "v=STSv1; id=2026060100"
tryexampleco.com.                IN  A      <redirect-host-ip>

The record set is functionally identical across every sending domain in the tier — same SPF policy, same DKIM selector convention, same DMARC posture, same MTA-STS configuration. Variation across domains produces no benefit and introduces operational drift. The correct posture is full template parity, with the only per-domain variation being the registrable label and the DKIM public key (each domain has a distinct selector keypair).

The DMARC posture on the sending tier merits specific treatment. Sending domains have no inbound transactional flow and no legitimate sender population outside the operator's own infrastructure. The alignment audit surface is minimal, and DMARC escalation can compress to a 14-to-21-day timeline — p=none for the warmup window, p=reject on transition to production volume. The corporate tier follows the longer 60-day escalation in Chapter 3, because its audit surface is materially larger.

The redirect strategy

A sending domain must resolve to something. A domain that produces NXDOMAIN on the bare apex, or that returns a default registrar parking page, is de-ranked by recipient mail clients and by the reputation-scoring infrastructure that follows the link. The penalty is small per incident but accumulates across the tier.

The correct posture is a permanent 301 redirect from every sending domain to the corporate root. The bare apex of tryexampleco.com serves a 301 to https://example.com/, with both http:// and https:// configured and a valid TLS certificate on the sending domain — the certificate handshake itself is a positive reputation signal at several providers. A minimal landing page hosted on the sending domain is an acceptable alternative when the campaign benefits from a domain-specific landing context; for most operators the 301 to corporate is the cleaner default.

WHOIS configuration

The WHOIS record on a sending domain is itself a reputation signal. Several reputation-scoring services — Spamhaus, SURBL, the consumer-side filter populations — query WHOIS as part of their classification logic, and a record that does not match the outbound claim is a measurable detractor.

The correct posture is WHOIS privacy enabled, with the underlying registrant matching the operating entity. A sending domain registered under a personal name, a shell entity, or a hosting provider's default registrant produces a misalignment between the outbound brand and the WHOIS-visible owner that several classifiers treat as suspicious. Privacy is acceptable — the underlying registrant on file with the registrar is what matters when the registrar is queried directly. A working abuse mailbox at every sending domain, routed to a monitored inbox, is required by several reputation systems and is a precondition for any meaningful blocklist-delisting process.

Burning a sending domain

The expected lifecycle of a heavily-used sending domain is 12 to 24 months. The cycle: registration, warmup over 21 to 28 days, production sending at the per-mailbox rate, gradual accumulation of complaint signal and blocklist exposure, observable degradation in placement-rate over the back half of the lifecycle, retirement and replacement.

A burned domain is one whose reputation has degraded past the threshold of operational use. The signal is unambiguous in seed testing — placement-rate at Gmail drops below 40%, Outlook below 25%, Yahoo below 30%. The decision is simple: stop sending, allow in-flight replies to drain over 30 days, then retire the domain or rest it for 90 days before any rehabilitation attempt. Rehabilitation succeeds in a minority of cases; retirement is the dominant default.

A sending tier in steady state is therefore a domain population with continuous turnover — new domains entering warmup, mature domains in production, late-stage domains in retirement queue. The operator who treats sending domains as permanent infrastructure watches the entire tier degrade in parallel and discovers, six months in, that no domain in the tier is performing.

Common deployment failures observed in production

• The founder sending the first 200 cold emails from founder@theirstartup.com. The most damaging failure observed across early-stage senders. The corporate primary accumulates a complaint pattern in the first week, investor updates and customer communications begin landing in spam, and the founder discovers the problem 30 to 60 days later when a customer asks why they never received an invoice. Rehabilitation takes 90 days minimum. The opportunity cost is the entire transactional flow of the company for a quarter.
• Sending from a subdomain of the corporate primary. mail.example.com is configured as the cold-outbound origin under the assumption that the subdomain isolates reputation from the apex. It does not — the organizational domain is shared, the reputation pool is shared, the damage is shared.
• A tier composed of arbitrary unrelated domains. Recipients see contactnow.com as the sender, the brand is not recognized, reply-rate collapses, complaint rate inflates from sender-identity confusion alone. The tier produces no pipeline regardless of authentication quality.
• Sending domains that NXDOMAIN on the bare apex. The A record is omitted, the redirect is not configured, the domain produces a hostname error when any recipient or reputation system attempts to resolve it. Placement-rate degrades by 5 to 15 points across the tier.
• WHOIS records under a personal name with the operating entity nowhere visible. Reputation classifiers flag the misalignment between the corporate brand in the outbound and the personal name in the WHOIS, and a fraction of the volume is downranked accordingly.
• A single sending domain hosting 10 to 20 mailboxes. Per-domain volume saturates the reputation ceiling, mailboxes cross-contaminate, a complaint on one drags the others, the tier collapses to a single point of failure. The 2-to-3-mailbox-per-domain rule exists for a reason.
• Never retiring a sending domain. The tier is provisioned once and operated indefinitely, the back half of the lifecycle is ignored, placement degrades continuously, and the operator concludes that cold outbound "stopped working" rather than that the infrastructure aged out. Continuous registration of replacement domains is a steady-state operational cost, not an optional improvement.

Pre-deployment checklist

• Corporate organizational domain identified and explicitly excluded from the cold-outbound configuration
• Sending tier composed of a population of distinct organizational domains, not subdomains of the corporate primary
• Lookalike pattern selected — try/use/get prefixes or .co/.io suffixes — and the trademark posture verified for the brand
• TLD distribution weighted toward .com, with .co as the secondary fallback
• Per-mailbox-per-domain ratio capped at 2 to 3
• Sending-domain count sized to the per-rep volume target (see the calculator at the top of this reference)
• Complete authentication record set on every sending domain (Chapters 1–4)
• 301 redirect from every sending domain to the corporate root, with valid TLS
• WHOIS privacy enabled, registrant on file matching the operating entity, working abuse mailbox routed to a monitored inbox
• DMARC escalation timeline documented per tier — corporate on the 60-day path, sending on the 14-to-21-day path
• A replacement cadence documented for the sending tier, with the next registration batch scheduled before the first tier reaches the back half of its lifecycle

Where this fits in the broader infrastructure

Subdomain architecture is the highest-leverage decision in the entire setup. Every other layer in the stack — SPF, DKIM, DMARC, MTA-STS, BIMI, ARC, warmup, monitoring — is configured on a domain or set of domains. The architectural choice of which domains determines whether a failure in any of those layers is contained or catastrophic.

A misconfigured DKIM key on a sending domain in a properly isolated tier is a 30-minute incident — rotate the key, regenerate the selector, resume sending. The same misconfiguration on the corporate primary is a multi-week incident that touches every transactional and corporate flow. A complaint spike on a sending domain in a properly isolated tier is a single-domain retirement event. The same complaint spike on the corporate primary is an existential event for the company's email infrastructure.

The architectural choice is also the one decision in the stack that cannot be retrofitted cheaply. Record updates, policy escalations, and monitoring deployments can be applied incrementally to a live estate. The decision to send cold outbound from a separate organizational domain, made on day one, costs a few hundred dollars in domain registrations. Made retroactively, after the corporate primary has accumulated a quarter of complaint signal, it costs 60 to 90 days of corporate-mail rehabilitation and an indeterminate amount of business not transacted in the interim. The reputation firewall exists or it does not.