Subdomain Rotation

Receivers track sender reputation per IP and per domain. Domain reputation usually means the organisational domain (example.com), but subdomains are tracked separately for some signals.

Without subdomain isolation, all your mail flows under one reputation profile. A reputation hit from a poorly-targeted marketing campaign damages the same reputation profile that handles password resets and account verifications. The transactional mail, which is critical and engagement-heavy, pays for the marketing mail's mistakes.

With subdomain isolation, marketing mail flows under news.example.com while transactional flows under mail.example.com. A reputation incident on news.example.com doesn't affect mail.example.com.

That's the entire idea. Simple in theory. Slightly nuanced in practice.

Common patterns major senders use:

• Transactional: mail.example.com, notify.example.com, system.example.com. Low volume, very high engagement, near-zero complaints. Reputation is gold.
• Marketing newsletters: news.example.com, updates.example.com. Medium volume, moderate engagement, occasional complaints from list-quality issues.
• Promotional / commercial: promo.example.com, offers.example.com. Higher complaint rates expected. Isolated to contain reputation impact.
• Cold outreach (B2B): outreach.example.com, connect.example.com. Highest complaint and bounce rates. Sometimes on a separate root domain entirely.
• Internal corporate: usually the apex (example.com) or a dedicated corp.example.com. Different threat model: receivers trust corporate-style mail more if it looks like real human correspondence.

The exact subdomains don't matter. What matters is consistent assignment over time. news.example.com always handles newsletters, mail.example.com always handles transactional. Never swap them mid-month.

Receivers compute reputation at multiple granularities:

• Per IP (the sending IP's history)
• Per organisational domain (example.com)
• Per subdomain (news.example.com specifically)
• Per DKIM signing domain (the d= tag)

Subdomain reputation operates somewhat independently of root-domain reputation. A bad subdomain doesn't fully poison the apex. So when you isolate marketing on news.example.com and the marketing campaign hits trouble, the apex example.com reputation absorbs less of the damage. Transactional on mail.example.com stays mostly clean.

This isn't complete isolation. Receivers do propagate severe reputation events upward to the apex (especially Spamhaus listings, which can list both subdomain and apex). But for ordinary fluctuations and even for moderate incidents, subdomain-level reputation provides genuine protection.

The same technique used differently becomes the spam pattern receivers most aggressively detect.

Snowshoe pattern: spammers create dozens of throwaway subdomains, send small amounts of spam from each one, rotate to new subdomains as they get detected. The point is to spread volume across so many subdomains that no single one accumulates enough volume to trigger reputation tracking. Combined with rotating IPs, the attacker stays below detection thresholds at the per-source level while shipping high aggregate volume.

Receivers learned this pattern years ago. Detection signals:

• Many subdomains under one organisational domain, all with similar low volume
• Subdomains with very recent first-send dates (just registered or just activated)
• Subdomain naming patterns that look generated rather than meaningful (x7f.example.com, m4q.example.com)
• Rapid creation and abandonment of subdomains
• Volume distributed evenly across subdomains rather than concentrated in a few stable ones

The tell: legitimate subdomain rotation uses few stable subdomains over months and years. Snowshoe rotation uses many throwaway subdomains over days and weeks.

For each subdomain you want to use:

1. Set up authentication. SPF record at the subdomain root (or at the apex with subdomain inheritance). DKIM key with selector under _domainkey.subdomain.example.com. DMARC at the apex applies to subdomains via sp= tag, or you can set subdomain-specific DMARC.
2. Configure your MTA to use the subdomain in the From: header and DKIM d= tag for that mail category. The envelope MAIL FROM should also be under the subdomain.
3. Warm the subdomain if it's new. New subdomain means no reputation. The same warmup principles that apply to fresh IPs also apply to fresh sending domains. 30-day logarithmic ramp.
4. Monitor reputation per subdomain. Postmaster Tools tracks subdomain reputation separately. Spamhaus DBL operates on domain (including subdomain) granularity. Watch each subdomain's metrics.

For the apex domain itself, use it sparingly. Treat it as the highest-trust subdomain, reserved for content that absolutely needs full apex reputation behind it. Most operational mail goes through subdomains, leaving the apex clean.

Counterargument: not every operator needs subdomain isolation.

• Low total volume. Splitting 10K monthly sends across three subdomains means each subdomain gets 3K monthly, which is below threshold for receivers to track reputation at all. Consolidate, don't fragment.
• Single mail category. If you only send one type of mail (only transactional, only newsletter), there's nothing to isolate from. Pick one good subdomain and stick with it.
• Established apex reputation. Apex domains with 5+ years of clean sending history have stronger reputation than any new subdomain ever will. Sometimes preserving and using the apex is the right move.
• BIMI deployment. BIMI is configured per organisational domain. If you want BIMI display, that's typically at the apex. Splitting heavily across subdomains weakens the BIMI signal.

Three structural changes through 2024-2026 have made subdomain rotation more valuable than it was when most legacy guidance was written. Senders relying on rotation strategies from two years ago should re-evaluate whether their pool design still satisfies the current receiver behaviour.

Gmail's enforcement transition in November 2025 moved bulk-sender evaluation from spam-folder routing to outright SMTP-level rejection. The bulk-sender threshold is 5,000 emails per day to personal Gmail accounts. Programmes running aggregate volume above that threshold without subdomain rotation produce a single reputation concentration point at the apex, which makes the enforcement boundary harder to manage. Distributing volume across appropriately-warmed subdomains keeps individual reputation pools below the threshold where receiver-side classification escalates, even when aggregate operator volume is well above it.

Microsoft's bulk-sender rule rollout completed by April 30, 2026 with the same 5,000-per-day threshold for consumer Outlook properties. Compliance now requires per-domain consideration in addition to per-IP and per-mailbox compliance, because Microsoft tracks domain-level signals independently of IP and mailbox signals. Subdomain rotation distributes the per-domain signal across multiple reputation pools, each of which stays well within the compliance envelope.

Postmaster Tools v2 launched in October 2025 with binary Pass/Fail compliance status replacing the previous High/Medium/Low gradient. Senders who relied on the warning band to detect deteriorating reputation before enforcement no longer have that band. Per-subdomain monitoring provides the granularity that operators need to detect and respond to specific pool degradation before the binary signal flips to Fail.

The combined effect is that 2026 cold outreach and bulk mail environments reward architectural designs that distribute volume across stable subdomain pools, while penalising both concentrated single-domain sending (which hits enforcement thresholds) and aggressive snowshoe rotation (which receivers detect as evasion).

The "right number" of subdomains is the smallest number that keeps each pool below the receiver-side thresholds where bulk-sender heuristics activate. Larger pools add operational overhead in DNS management, DKIM key rotation, and warmup pipeline load without adding meaningful resilience past a point. Smaller pools concentrate volume and bring per-pool numbers closer to enforcement thresholds.

Practical sizing guidance based on aggregate volume:

• Under 5,000 daily aggregate: One sending subdomain plus the apex for transactional is sufficient. Splitting further fragments reputation without producing isolation benefit.
• 5,000-20,000 daily aggregate: 3-5 subdomains. One for transactional (or apex), one for marketing newsletters, optionally one for promotional, one for cold outreach if applicable. Each pool carries 2,000-5,000 daily, comfortably below bulk-sender thresholds.
• 20,000-100,000 daily aggregate: 8-15 subdomains. Multiple sending pools per category, ideally with hot-standby pools that can absorb traffic if a primary pool develops reputation issues.
• Above 100,000 daily aggregate: 15-25 subdomains with structured rotation cycles, dedicated IPs per pool, and operational tooling for managed rotation between primary and standby roles. At this scale the architecture is more important than the absolute subdomain count.

The case study documenting a B2B outreach agency's 15-subdomain pool design (under "agency cold outreach pool rotation" in our case-study library) walks through the specific reasoning for choosing 15 over smaller or larger pool sizes, plus the rotation cadence and hot-standby structure that has continued working through 2025-2026 receiver tightening.

The authentication setup for subdomain rotation is where most implementations fail. The receiver evaluates DKIM signing identity, SPF alignment, and DMARC policy at the per-subdomain level, but inheritance from the apex domain has to be configured correctly or the subdomain inherits no protection at all.

DKIM should run per-subdomain signing keys, not a shared apex key. Per-subdomain keys produce independent reputation tracking and let receivers attribute engagement signal to the specific sending pool. The selector should follow a predictable naming convention (e.g. k2026q2._domainkey.s7.example.com) and rotate quarterly. Rotation is a normal operational task receivers expect, not an unusual event.

SPF should be authorised at the apex with explicit include directives covering all sending infrastructure. Subdomain SPF inheritance through the apex works correctly when the apex SPF record authorises the sending IPs. If subdomain-specific SPF records are needed (some receivers handle them differently), they should explicitly authorise only the IPs that subdomain uses, not the full apex set.

DMARC at the apex with sp= subdomain policy applies to all subdomains. The recommended 2026 pattern is p=quarantine; sp=quarantine; pct=100; rua=mailto:dmarc-reports@example.com with progression to p=reject; sp=reject after 60 days of clean reporting confirms alignment. DMARC at p=reject is increasingly expected by major receivers and is required for BIMI eligibility.

Subdomain-level DMARC overrides are sometimes used when one subdomain needs different enforcement than the apex (typically transactional needs reject while marketing pools need quarantine during warmup). These overrides are valid but operationally complex; most programmes are better served by consistent enforcement across all subdomains with apex-level reporting aggregation.

Static pools where each subdomain handles the same role permanently produce stable reputation but expose individual pools to repetitive volume signatures that receivers can fingerprint. Dynamic pools where roles rotate among subdomains produce harder-to-fingerprint patterns at the cost of operational complexity. The right balance depends on aggregate volume and the specific receiver behaviour being optimised for.

For pools under 10 subdomains, static role assignment usually works. Each subdomain handles its assigned category consistently over months, accumulating clean per-pool reputation that compounds positively over time. The cost of operational simplicity is that any pool failure requires manual intervention (suspending the failed pool, redirecting traffic) rather than automatic absorption by other pools.

For pools of 10-15 subdomains, weekly rotation of primary versus hot-standby roles produces meaningful diversification without adding excessive operational complexity. The pattern: 7-10 subdomains carry primary production load each week, 3-5 hot-standby subdomains operate at low volume to maintain reputation, 1-2 cold-standby subdomains stay pre-warmed but inactive. Rotation cycles displace longest-active primaries into hot-standby roles for rest periods, and rotate hot-standby subdomains into primary positions to redistribute load.

For pools larger than 15 subdomains, the rotation cadence becomes structurally important. Daily rotation produces volume patterns that look uniform across subdomains and can themselves become a detectable signature. Weekly rotation with offset cycles between subdomains preserves the per-pool reputation benefit while avoiding the uniform-rotation fingerprint that aggressive snowshoe detection systems are designed to catch. The case-study deployment that uses 15 subdomains with offset 6-week rotation cycles has continued working through 2024-2026 receiver conditions without modification, which is some evidence that the structural design holds under tightening enforcement.

The architecture is the structural design. The runbook is what makes the structural design operate cleanly over time as receiver conditions evolve and individual pools occasionally develop reputation issues. Programmes that deploy subdomain rotation without runbook discipline usually find themselves managing the same incidents repeatedly because the underlying patterns are not being detected early enough to prevent escalation.

The minimum monitoring stack: Postmaster Tools v2 dashboard per sending domain (apex plus each active subdomain), Microsoft SNDS per sending IP, weekly Spamhaus and major blocklist checks against both apex and each subdomain, daily DMARC report aggregation routed to a dedicated mailbox, daily bounce-rate trend per pool with alerting on slope. The slope alerts are more important than the absolute-value alerts because reputation deterioration usually shows as a trend before it crosses absolute thresholds.

Alerting thresholds that have proved useful across 2024-2026 deployments: complaint rate above 0.1% on any single pool (warning), complaint rate above 0.2% (escalate), complaint rate above 0.3% (pause that pool immediately). Bounce rate above 1% sustained for 48 hours (warning), bounce rate above 2% (escalate). Postmaster Tools status flips from Pass to Fail (immediate page). Spamhaus listing on any apex or active subdomain (immediate page). SNDS rating moves from green to yellow on any sending IP (warning). These thresholds catch most incidents before they require multi-week recovery.

Incident response when a pool degrades: pause that specific subdomain rather than the entire pool, route its traffic to hot-standby subdomains in the same category, audit the specific cause (content change, list-quality issue, infrastructure change in the previous 7-14 days), document findings, fix root cause before resuming. A degraded pool that resumes sending without root-cause fix usually re-degrades within 2-3 weeks. The pause-and-fix discipline costs operational time in the short term and prevents the longer recovery cycles that uncontrolled degradation produces.