Sending subdomain selection — choosing which subdomain of the primary domain to use for each type of email the programme sends — is one of the foundational decisions in email infrastructure design that most programmes do not make deliberately enough. The subdomain choice determines how reputation isolation works between email streams, how DMARC policy applies to different sending types, and how recipients perceive the email's relationship to the brand. A poorly designed subdomain structure conflates marketing and transactional email reputation, exposes the primary domain to cold email complaint signals, and makes DMARC enforcement operationally difficult. A well-designed structure provides clean isolation between streams, clear recipient recognition, and simple DMARC policy management.
Why Sending Subdomains Matter for Deliverability
The primary domain of a business (brand.com) serves multiple email functions simultaneously: outbound corporate email from employees (@brand.com), inbound customer service (support@brand.com), transactional system email (no-reply@brand.com), marketing campaigns, and potentially cold outbound sales. When all of these functions send from the same domain, the reputation signals from each function aggregate under the same domain reputation that ISPs track. A marketing campaign that generates a complaint rate spike affects the domain reputation that employees' outbound corporate email depends on. A cold email programme generating above-threshold complaint rates drags down the domain reputation that transactional email — password resets, account alerts — needs to be reliable.
Sending subdomains create functional separation between email streams: each subdomain develops its own reputation history, its own authentication configuration, and its own complaint rate profile. A reputation event on mail.brand.com (marketing campaigns) does not contaminate the reputation of transact.brand.com (transactional email) or outreach.brand.com (cold email). The primary domain brand.com — from which employees send corporate email — is protected from all of these external-facing programme reputation signals.
The caveat: subdomain reputation isolation is stronger at some ISPs than others. Most corporate email security gateways and many regional ISPs track subdomain reputation as independent from root domain reputation. Gmail partially isolates subdomain reputation but also considers the organisational domain (brand.com) as a factor in evaluating mail.brand.com reputation — a severe reputation event on mail.brand.com does bleed through to affect brand.com's reputation at Gmail to some degree. The isolation is imperfect but meaningful — a moderate complaint rate spike on mail.brand.com is contained to that subdomain's reputation at most ISPs; only a severe, sustained event on a subdomain affects the root domain's reputation at Gmail.
Stream Isolation: Marketing, Transactional, Cold
The standard subdomain structure for a complete commercial email programme isolates the three primary sending functions that have different reputation requirements:
| Email stream | Recommended subdomain | Reputation requirement | Complaint tolerance |
|---|---|---|---|
| Marketing campaigns, newsletters | mail.brand.com or newsletter.brand.com | High (Gmail) — sustained through good list management | Below 0.05% for sustained High reputation |
| Transactional (receipts, alerts, MFA) | transact.brand.com or notify.brand.com | High — critical for user experience and security | Near-zero — transactional email almost never generates complaints |
| Cold outreach / sales | Separate purchased domain (outreach-brand.com) — NOT a subdomain of brand.com | Variable — cold email generates higher complaint rates | Below 0.10% — but separate domain protects brand.com |
| Corporate employee email | Root domain brand.com — not a sending subdomain | Critical — employee email reputation is the brand's direct communication reputation | Zero — employee email should never generate complaints |
The cold email exception: cold email should use a completely separate purchased domain (outreach.brand.com is too close to the primary brand) rather than a subdomain of the primary business domain. Cold email generates complaint rates 5-20x higher than opt-in marketing email — the complaint signals from a cold email programme on any subdomain of brand.com create some reputation signal exposure for brand.com, even with subdomain isolation. A separate domain (outreachbrand.com, getbrand.com) eliminates this cross-contamination completely.
Subdomain Naming Best Practices
Subdomain naming affects both technical configuration and recipient recognition. Recipients who see the From address (hello@mail.brand.com) should immediately recognise both the brand and the email type. Subdomains that are clearly associated with the sending function provide better sender recognition than generic subdomains:
Marketing and newsletter subdomains: news.brand.com, newsletter.brand.com, letters.brand.com, email.brand.com, mail.brand.com. These names clearly associate the subdomain with a newsletter or email communication function — recipients recognise them as intentional newsletter infrastructure rather than a technical server name.
Transactional subdomains: notify.brand.com, notifications.brand.com, alerts.brand.com, noreply.brand.com, system.brand.com. Clear functional association helps recipients recognise that the email is an automated system notification rather than marketing.
Avoid: Generic server names (smtp.brand.com, mx.brand.com, relay.brand.com) — these look like infrastructure hostnames and reduce sender recognition. Very short subdomains (e.brand.com, m.brand.com) — these are efficient but provide no sender recognition signal and look more like tracking infrastructure than branded email. Randomly generated subdomains — these strongly signal spam sending infrastructure and are treated with maximum suspicion by spam filters.
DMARC Subdomain Policy and Inheritance
DMARC policy applies to the domain where the DMARC record is published. By default, the DMARC policy at brand.com also applies to subdomains of brand.com (through the sp= subdomain policy parameter). Understanding this inheritance is critical for correct DMARC subdomain configuration:
# brand.com DMARC record with explicit subdomain policy: _dmarc.brand.com TXT "v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@brand.com" # p=reject: applies to brand.com itself # sp=quarantine: applies to all subdomains (mail.brand.com, notify.brand.com, etc.) # If sp= is omitted, subdomains inherit the root domain policy: _dmarc.brand.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@brand.com" # → all subdomains also get p=reject # Override for a specific subdomain: _dmarc.mail.brand.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-mail@brand.com" # → mail.brand.com gets p=quarantine; brand.com and other subdomains still get p=reject
The subdomain DMARC override pattern is useful when the root domain is at p=reject but a specific subdomain needs a different policy (for example, during a new subdomain warmup where p=quarantine is appropriate until the authentication is confirmed correct). After warmup is complete and authentication is confirmed, advance the subdomain to p=reject to match the root domain's policy.
Authentication Configuration Per Subdomain
Each sending subdomain requires its own complete authentication configuration: SPF record, DKIM signing key, and DMARC record (or inherits from root domain DMARC). The configuration must be specific to the sending subdomain because authentication alignment requires that the From: header domain matches the DKIM signing domain (d=) or the SPF MAIL FROM domain.
# Authentication for mail.brand.com: # SPF record for mail.brand.com (covers only this subdomain's sending sources): mail.brand.com TXT "v=spf1 include:mailchimp.com ~all" # DKIM record for mail.brand.com (selector "campaign2027"): campaign2027._domainkey.mail.brand.com TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY" # ESP signs outbound email with d=mail.brand.com, s=campaign2027 # DMARC for mail.brand.com (optional override — inherits from brand.com if absent): _dmarc.mail.brand.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@mail.brand.com" # Authentication for notify.brand.com (transactional): notify.brand.com TXT "v=spf1 include:postmarkapp.com ~all" mail2027._domainkey.notify.brand.com TXT "v=DKIM1; k=rsa; p=TRANSACT_KEY"
How Gmail Treats Subdomain Reputation
Gmail's reputation model is domain-level but considers both the sending subdomain and the organisational domain (the registered domain — brand.com, the second-level domain before the TLD). Gmail Postmaster Tools displays reputation per domain — mail.brand.com and notify.brand.com have separate reputation dashboards in Postmaster Tools, confirming that Gmail tracks subdomain reputation separately.
However, Gmail's filtering algorithm also considers the organisational domain's reputation as a factor. A subdomain that is new (mail.brand.com, just started sending) can benefit from the established reputation of the organisational domain (brand.com) that has a positive history. Conversely, a subdomain with a severe reputation event (mail.brand.com at Bad reputation) does create some negative signal for brand.com's organisational reputation in Gmail's model — the isolation is real but not absolute for severe events.
This Gmail organisational domain consideration is the reason to treat all subdomains with the same reputation discipline as the primary domain — the complete isolation that makes a subdomain reputation event fully contained to that subdomain does not exist at Gmail. What does exist is meaningful partial isolation that makes moderate reputation events in one subdomain not affect other subdomains, and makes only severe sustained events create cross-contamination.
Warming Up New Sending Subdomains
A new sending subdomain — even for a brand with established organisational domain reputation — requires warmup before full-volume sending begins. The new subdomain's reputation is separate from the root domain's reputation at most ISPs. Gmail Postmaster Tools will show a new subdomain as having no reputation initially, and will build a reputation based on the engagement signals from early sends to the subdomain.
The subdomain warmup benefit from organisational domain reputation: a new mail.brand.com subdomain warming up alongside an established brand.com domain reputation may experience faster reputation building than a completely new domain with no organisational domain history. Gmail's partial consideration of the organisational domain's reputation provides a head start — the new subdomain does not start from exactly zero. The warmup still takes 4-8 weeks to reach High reputation at full volume, but the trajectory is typically faster than a completely fresh domain with no associated organisational reputation.
Subdomain warmup protocol mirrors IP warmup: start with the highest-engagement contacts, gradually increase volume week-over-week, monitor Postmaster Tools daily for the new subdomain, and advance volume only when the subdomain reputation shows Medium or High at the current volume level. Do not rush subdomain warmup by deploying full volume immediately — the reputation building on the new subdomain requires the same patient engagement signal accumulation as any IP warmup.
Common Subdomain Strategy Mistakes
- Using the root domain for marketing email: The most common mistake. Marketing email from brand.com shares reputation with employee email from @brand.com. Any marketing reputation event affects employee email deliverability directly.
- Using the same subdomain for transactional and marketing: When a marketing campaign complaint spike affects the same subdomain that sends password resets and order confirmations, critical transactional email delivery is degraded. These streams should always be isolated.
- Cold email from a subdomain of brand.com: Cold email complaint rates (0.08-0.25%) are incompatible with brand.com reputation protection. Cold email must use a completely separate purchased domain.
- Forgetting to configure authentication for new subdomains: Adding a new sending subdomain without publishing an SPF record, configuring DKIM signing, and verifying DMARC inheritance creates authentication failures that cause MAGY compliance problems immediately.
- Skipping subdomain warmup: Deploying full campaign volume to a new subdomain on day one generates the cold-start reputation building problems that rushed warmup always creates — high deferral rates, potential spam folder placement, and a slower overall reputation build than a gradual warmup would have achieved.
Subdomain strategy is one of the foundational infrastructure decisions that shapes everything else in the email programme. Make it deliberately, document the intended structure, implement authentication for each subdomain correctly, warm up new subdomains properly, and monitor each subdomain's reputation separately. The programme that has clear subdomain isolation between its email streams operates with the resilience that makes any single stream's reputation event a contained operational issue rather than a programme-wide crisis.
Subdomain Strategy for Multi-Brand and Agency Programmes
For agencies managing multiple clients' email programmes or organisations with multiple distinct brands under one corporate parent, the subdomain strategy extends to brand separation as well as stream separation. Each client or brand should send from subdomains of their own primary domain -- not from the agency's infrastructure domain. mail.clientbrand.com provides client brand recognition and builds client brand reputation; mail.agencyname.com builds agency reputation, not client reputation, and conflates all clients' reputation signals under a single domain that none of them own.
The multi-client subdomain structure: each client domain has its own complete authentication configuration (SPF, DKIM, DMARC), its own sending subdomain (mail.client1.com, mail.client2.com), and its own reputation tracking in Postmaster Tools and SNDS. The agency's MTA infrastructure can serve all these subdomains from shared servers using VMTA-per-client isolation (PowerMTA) or separate sending streams, but the outward-facing authentication and reputation is client-brand-specific, not agency-specific. This provides complete brand and reputation isolation between clients -- a reputation event for client A does not affect any other client's programme.
The subdomain strategy decision, made correctly at the programme's inception and maintained correctly through its growth, is the infrastructure foundation that makes reputation management predictable and controllable. Each stream has its own reputation story; each subdomain's reputation responds directly to the quality of that stream's sending practices; reputation events are contained by design rather than accidentally. That predictability and control is worth every hour of careful subdomain strategy planning before the first email is sent.