Send bulk marketing from a marketing subdomain if your program is above roughly 20,000 messages a month, or if your domain has been registered for less than a year. Below that, on a domain that has been sending business mail reliably for years, the root domain is usually the better choice, because you inherit history that a fresh subdomain does not have and cannot fake. The part most operators get wrong is what comes after the decision: a subdomain separates authentication identifiers and part of your reputation scoring, and it does not separate the links inside your message body, the organizational domain a blocklist acts on, or the volume threshold Gmail counts you against.
Key takeaways
- A subdomain isolates the DKIM signing domain, the Return-Path and the per-domain reputation score. It does not isolate the URLs you put in the body, which almost always point at the root.
- Gmail counts its 5,000 messages per day bulk sender threshold across your primary domain including every subdomain, so splitting sends does not put you back under it.
- A new subdomain starts with almost no reputation and needs a warming ramp. An established root domain gives you borrowed trust on day one.
- Publish DMARC at the organizational domain with an explicit
sptag before you move volume, or your subdomain inherits a policy you did not think about. - Under DMARC relaxed alignment, signing with a subdomain and displaying a From address on the root can both be true at once. Whether your ESP allows that is a separate question.
- For an established store under about 20,000 sends a month, staying on the root is defensible. Above roughly 100,000 a month, a subdomain is not a preference, it is operational hygiene.
What a marketing subdomain actually separates
Three things, and they are worth naming precisely because the marketing copy around this topic is vague. First, the DKIM signing domain: the d= value in the signature header becomes send.yourbrand.com instead of yourbrand.com, and the key lives in a selector record under that subdomain. Second, the Return-Path, which is the envelope sender that SPF is evaluated against, and which your ESP controls. Third, the domain reputation score that mailbox providers compute per sending identity. Google Postmaster Tools reports domain reputation and IP reputation as two separate scores (Postmaster Tools dashboards), and the domain score is keyed to the domain that authenticates the mail, so a subdomain does get its own line.
That third point is the actual argument for a subdomain. If your marketing program has a bad quarter, complaint rates climb, and the domain score drops, the score that dropped is the one attached to send.yourbrand.com. Your password resets, order confirmations and one to one sales mail from the root keep their own score. That separation is worth a lot in a business where a single bad list import can cost you two months of recovery. If you want the diagnostic side of that, see how to find which segment is burning your domain.
What a subdomain does not shield the root from
Four things, in rough order of how often they surprise people.
The links in your body. Every campaign you send contains URLs pointing at your storefront on the root domain. Filters evaluate those URLs. Domain blocklists list them. A subdomain moves the envelope and the signature, and it leaves your product links exactly where they were. This is the single biggest gap between what operators think a subdomain buys and what it buys.
The bulk sender threshold. Google's sender requirements apply to anyone sending 5,000 or more messages per day to Gmail accounts, and Google states that the count is per primary domain with subdomains included (Email sender guidelines). Splitting your sends across news. and send. does not get you back under the line. Yahoo applies a comparable set of requirements including a complaint rate ceiling (Yahoo sender best practices).
Domain blocklists. Listings frequently apply to an entire zone rather than a single hostname. Spamhaus documents its domain blocklist as covering domains found in message content and infrastructure (Spamhaus DBL), and a listing that catches your organizational domain catches every child of it.
Brand-level signals. Filters build a picture of a brand from more than one identifier: the friendly From name, the reply-to, the click tracking hostname, the images CDN. If most of those still resolve to the root, the isolation is partial by construction.
When the root domain is the right call
When the domain is old, the sending history is clean, and the volume is modest. A domain that has been running company mail through Google Workspace for six years carries positive engagement history that a subdomain created this morning does not. Mailbox providers do extend some of a parent domain's standing to a new subdomain, but the effect is partial and it fades quickly once the subdomain accumulates its own signal. If you are sending 8,000 marketing messages a month to a list of buyers who actually opened last quarter, moving to a subdomain trades a known-good reputation for an unknown one and buys you isolation you are unlikely to need.
The other case for the root is operational. Every additional sending identity is another set of DNS records to keep correct, another DMARC report stream to read, another thing that breaks silently when someone migrates DNS providers. Small teams routinely add a subdomain, get the CNAMEs half right, and end up with DKIM signing on a hostname nobody monitors.
When a subdomain stops being optional
Four conditions. Any one of them is enough.
- Volume above roughly 100,000 marketing messages a month. At that scale a bad send is measured in thousands of complaints, and you want that damage contained away from the mail that pays your invoices.
- Transactional and marketing share the root today. Order confirmations and shipping notices must land. Give them their own identity so a promotional misfire cannot take them down with it.
- Multiple brands or multiple ESPs on one registered domain. Separate identities are the only way to attribute a reputation problem to a specific program. This is the whole premise of a multi-brand sending domain model.
- You are about to import or reactivate a list you did not build. Do that on a domain you are prepared to lose. See clean, suppress or restart an inherited list before you send anything.
Naming, and the transactional split
Pick a hostname that describes the traffic, not the vendor. send.yourbrand.com, email.yourbrand.com and marketing.yourbrand.com are all fine. Avoid klaviyo.yourbrand.com, because you will change ESPs eventually and the name becomes a lie you have to migrate. Avoid mail.yourbrand.com if that host already carries MX or webmail, since you do not want bulk sending and inbound mail sharing a name.
Split transactional onto its own child, for example txn.yourbrand.com or whatever your commerce platform authenticates. Shopify documents its own domain authentication for store notification and marketing mail (Shopify domain authentication), and the practical outcome you want is that a receipt and a promotion never share a reputation score.
One nuance worth knowing before you commit. DMARC's relaxed alignment mode only requires the DKIM signing domain and the From header domain to share an organizational domain (RFC 7489 section 3.1). That means a message signed as d=send.yourbrand.com with a visible From of [email protected] passes DMARC cleanly. Whether your ESP will configure that combination is a product question, and platforms differ. Check it before you promise anyone the From address will not change.
The DMARC policy that has to come with it
Publish the record at the organizational domain and set sp explicitly. RFC 7489 defines sp as the requested policy for all subdomains, and when it is absent, subdomains inherit the p value (RFC 7489 section 6.3). The failure mode this creates is specific: you set p=reject on the root before you had visibility into everything sending as a subdomain, and an internal system that was never authenticated starts getting rejected.
The sequence I use is p=none; sp=none with aggregate reporting on, read reports for two to four weeks until every legitimate source is identified and aligned, then move to p=quarantine; sp=quarantine, then to reject on both. Do not skip the reporting window because a tool told you the record is valid. A record can be syntactically perfect and still be enforcing against mail you forgot about. Alignment also fails asymmetrically across receivers, which is its own diagnosis problem, covered in DMARC alignment failing per recipient.
While you are in DNS, check the SPF record for the sending domain against the ten DNS lookup limit in RFC 7208 section 4.6.4. Adding a subdomain is the moment teams stack another include: and quietly cross the limit, which produces a permerror that some receivers treat as a fail. That specific trap is worked through in why SPF passes a checker but Outlook says junk.
Moving volume off the root without a reputation dip
Treat it as a warm-up, not a cutover. The subdomain has no history, so the first sends are being judged almost entirely on recipient behaviour. Send your highest engagement cohort first, at low volume, and grow from there. A workable ramp for a list of a few hundred thousand:
| Stage | Audience | Daily volume | Watch |
|---|---|---|---|
| Days 1 to 5 | Opened or clicked in last 30 days | 1,000 to 3,000 | Postmaster domain reputation appearing at all |
| Days 6 to 14 | Engaged last 60 days | 5,000 to 15,000 | Spam rate holding under 0.10 percent |
| Days 15 to 30 | Engaged last 90 days | 25,000 to 75,000 | Delivery errors and any provider specific deferrals |
| Day 30 onward | Full active list | Normal | Reputation stable before you add reactivation |
Keep transactional mail on its existing identity throughout, so a ramp problem never touches receipts. Run both identities in parallel rather than switching in one release, and keep the old path configured until the new one has held for a full send cycle. The longer version of this, including what to do when a provider starts deferring mid ramp, is in how to warm a new sending domain. If you are also weighing IP strategy at the same time, that is a separate decision with a different answer: see dedicated vs shared IP.
Trade-offs and what I would do
The trade is isolation against borrowed trust, and the exchange rate depends almost entirely on how much history your root domain has and how much volume you are about to put through it.
| Situation | Recommendation |
|---|---|
| Domain under 12 months old, any volume | Subdomain. There is no history to borrow, so isolate from the start. |
| Established domain, under 20,000 marketing sends a month | Root domain. The borrowed trust is worth more than the isolation. |
| Established domain, 20,000 to 100,000 a month | Subdomain, warmed over 30 days. This is the band where a bad send starts to cost more than the migration. |
| Above 100,000 a month, or transactional shares the domain | Subdomain for marketing, separate identity for transactional, no exceptions. |
| Multiple brands or ESPs on one registered domain | One subdomain per program, so reputation is attributable. |
Two opinions I hold more strongly than the consensus. First, the isolation a subdomain gives you is smaller than most vendors imply, because your body links, your organizational domain and your bulk sender threshold all stay shared. Treat it as containment for authentication and reputation scoring, not as a firewall, and stop using it as an excuse to send to a list you would not otherwise send to. Second, migrating a healthy low volume program from an established root to a fresh subdomain is a net loss more often than people admit. You give up years of accumulated standing for isolation against a risk your current sending practices are not generating. Make the move when volume or list risk justifies it, and not because a checklist said subdomains are best practice.
If you are making this decision because mail is already landing in spam, the domain choice is downstream of the actual problem. Fix the sending practices first, using the deliverability diagnosis, then decide where to send from.