Sending Subdomain Strategy: Structuring Domains for Multiple Brands, Products and Mail Types

Choosing a sending subdomain sounds like a small DNS task, but it shapes reputation for years. At first, one company has one domain and sends everything from it. Then a second brand arrives, then a product with its own customers, a regional team, a receipts stream and a newsletter, and the question appears: which names should send which mail? The answer shapes your reputation, your authentication records and how easily you can fix problems. A well-chosen sending subdomain layout keeps a bad campaign from hurting password resets. A careless one leaves you with dozens of half-documented names that nobody dares to touch. This guide helps us choose a structure that is simple enough to maintain and separate enough to protect what matters.

Root domain or subdomain?

Your organisational domain is the registered name, such as example.com. A subdomain is anything below it, such as news.example.com. Mailbox providers keep reputation signals for several levels, including the sending IP address, the domain used in DKIM signing, the envelope sender and the visible From domain. Reputation attached to a subdomain is tracked separately from the rest, although the wider organisational domain may also be taken into account. That is why a subdomain gives you useful separation but not complete insulation.

As a rule of thumb, we keep the root domain for people and for the most critical mail, and put bulk or experimental streams on subdomains. A new subdomain also gives you a clean place to apply stricter practices, as in our guide to separating transactional and marketing streams.

Choice	Strengths	Weaknesses	Good fit
Everything on the root domain	Simple; one set of records	One bad stream affects all mail; hard to separate later	Very small senders with one mail type
One subdomain per mail type	Reputation separated by purpose; easy to explain	More records to maintain	Most single-brand senders
One subdomain per brand	Each brand builds its own reputation and identity	Needs a clear owner per brand	Companies with distinct brands or products
Brand and mail type combined	Maximum separation	Many names; easy to over-engineer	Large senders with high volume per stream
Separate registered domains per brand	Strongest separation; fits distinct public brands	Cost, registrar work and no shared organisational domain	Unrelated brands or customers who own their domain

What to separate and what to share

Not every distinction deserves a subdomain. Separate things that have different risk or different audiences.

• Mail type. Password resets, receipts and alerts should not share reputation with promotions. Complaint rates differ widely between these streams.
• Brand. If two brands have different customers and different public names, give each a subdomain of its own domain so that recipients see a consistent identity.
• Region. Separate regions only when audiences, languages or legal entities differ, or when volumes are large enough for each region to build its own history. A region with tiny volume is better placed inside a shared brand subdomain.
• Product. A product with its own customer base and sign-up flow can have its own name, but a feature inside an existing product usually cannot justify one.
• Risk level. New lists, acquired lists and experiments belong on a separate subdomain, so that a problem does not touch established mail.

Naming conventions that last

Names are read by people as well as machines. Support staff, auditors and recipients will see them in headers and in the From address. Pick a convention once and apply it everywhere.

• Use meaning, not codes: mail.example.com or news.example.com is clearer than a string of letters.
• Keep one pattern, for example purpose first (alerts, news, billing) and brand as part of the domain.
• Avoid names that look like phishing, such as a brand name followed by words like secure or login.
• Do not reuse a name for a different purpose later. If news changes meaning, create a new subdomain and retire the old one.
• Make the From address match the subdomain, so that the visible identity and the authenticated identity agree.

Authentication per subdomain

Each sending subdomain needs its own authentication. Records are not copied downwards, apart from the DMARC lookup rule described below. The full basics are in how to authenticate a sending domain.

SPF

SPF is evaluated for the name used in the envelope sender (the return-path) and, in some cases, the HELO name. A record on the root domain is not consulted for a subdomain. Publish an SPF record on each return-path domain you use, and keep each one inside the ten-lookup limit, as covered in fixing SPF permerror. Splitting streams across subdomains also helps here, because each record includes only the services that stream needs.

DKIM

A DKIM signature names a domain and a selector, and the public key is published at selector._domainkey under that domain. Use the subdomain you want recipients to credit as the signing domain, and use separate selectors per stream or per brand so you can rotate or revoke one without touching the others. See DKIM key rotation for a safe procedure.

Return-path and tracking subdomains

Bounce handling and link tracking often use their own names. For DMARC, the SPF result only counts if the return-path domain aligns with the From domain. Under relaxed alignment, a return-path subdomain that shares the same organisational domain as the From domain can align, but under strict alignment it must match exactly. A tracking domain on your own organisational domain also keeps links consistent with the sender. Setup details, HTTPS and alignment are in custom return-path and tracking domains and DMARC alignment explained.

DMARC policy inheritance and the sp tag

DMARC is where subdomain planning gets its structure. When a message arrives, the receiver looks for a DMARC record at _dmarc under the exact From domain. If none exists, it falls back to the record at the organisational domain. This is described in RFC 7489. Two consequences follow.

1. A subdomain without its own record is covered by the policy published at the organisational domain. If that record has an sp tag, the sp value applies to the subdomain. If it has no sp tag, the p value applies to subdomains as well.
2. A subdomain with its own DMARC record is governed by that record, not by the parent. This lets a brand or stream move to a stricter policy at its own pace, or lets a new, unproven subdomain sit on a softer policy while the main domain is enforced.

_dmarc.example.com.        TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com"
_dmarc.news.example.com.   TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

Also direct reports from all subdomains to one mailbox or reporting tool, so that you see the whole tree in one place. One caution: the DMARC specification is being revised, and the way receivers find the policy domain may change in newer versions, so check current documentation when you design for edge cases.

Agencies and platforms sending on behalf of customers

If you send for other people, such as clients of an agency or customers of a software platform, the main decision is whose domain appears in the From address and in the authentication.

Model	How it works	Benefits	Risks
Customer-owned domain	Customer adds records (or delegates a subdomain) for a name they own	Brand trust; reputation tied to the real sender; easy to leave	Customer DNS work; mistakes in their zone
Provider-owned shared domain	All customers send from names you control	No setup for customers	One customer can damage everyone; weak brand identity
Provider-owned subdomain per customer	You create a subdomain per customer under your own domain	Separation without customer DNS	Many subdomains to manage; customers cannot take the name with them
Mixed	Shared domain for trials, customer domain after verification	Easy start, clean path to production	Needs clear rules and migration steps

We lean towards customer-owned domains for anything beyond testing, because the sender who earns the reputation keeps it. Whatever model you choose, write it into your terms and onboarding so that customers know who controls DNS, what happens if they leave and what limits apply. For the verification steps themselves, see verifying your sending domain. Check your MigoSMTP dashboard or API reference for the domain options available to your account.

Avoiding the throwaway-subdomain trap

Some senders respond to every deliverability problem by creating a new subdomain. It feels like a clean start, but the pattern has costs. Large numbers of new, low-volume names that appear quickly and send similar content resemble snowshoe sending, a technique spammers use to dilute reputation across many identities. Filters are designed to notice it, and a legitimate sender who looks similar can be penalised. You also never build the steady history that earns good placement.

• Fix causes first: list quality, consent, content and complaint rates. A new name does not remove them.
• Create a subdomain only when you can name its purpose and owner.
• Let each subdomain build volume steadily, rather than spreading small amounts across many names.
• Retire subdomains you no longer need, and remove their DNS records.
• Do not rotate subdomains to escape a block. See blocklist removal for the right approach.

Migrating an existing domain

Moving from a single root-domain setup to a structured layout should be gradual. Mail that suddenly appears from a new name has no history, so recipients and filters treat it with caution.

1. Inventory current senders using your DMARC reports, so you know every system that sends as your domain.
2. Create and authenticate the new subdomain, with its own SPF, DKIM and DMARC alignment, before any live mail uses it.
3. Start with a small, engaged segment and increase volume in steps, following the principles in our warm-up guide.
4. Keep the old domain authenticated and monitored while traffic moves. Replies, links and forwarded copies may still use it.
5. Update the From address, reply handling, unsubscribe links and any templates together, and test the result.
6. Retire the old stream only when volume has moved and reports show no legitimate senders left.

For a change of provider as well as domain layout, the steps in migrating without losing deliverability apply too.

A worked example: one company, three brands

A company runs two consumer brands and one business software product. All mail currently leaves from its main corporate domain: receipts, newsletters for both brands, product alerts and staff email. A promotional campaign for one brand produces a high complaint rate, and receipts for the other brand start landing in spam.

After a review the team makes a plan. Staff mail stays on the corporate root domain. Each consumer brand has its own registered domain, because the public names differ, and each uses two subdomains: one for transactional mail and one for marketing. The software product uses a subdomain of the corporate domain for alerts and another for product news. That gives six sending subdomains, each with a stated purpose and an owner.

Every subdomain gets its own DKIM selector, an SPF record on its return-path name and a tracking name on the same organisational domain. The corporate domain publishes a DMARC policy with an sp tag, and each brand domain publishes its own. Marketing subdomains start on a softer DMARC policy until reports show clean alignment, then move up. The team migrates one stream at a time, warming each, and records everything in a register. The example is illustrative and the numbers are only for the layout, not a target to copy.

Documentation and ownership

Structure that lives only in one person memory is a risk. Keep a simple register, in a shared document or configuration repository, and update it whenever you add or remove a name.

Field	Why it matters
Domain or subdomain	The exact name used in From, return-path, tracking and DKIM
Purpose and mail type	Stops reuse for unrelated mail
Brand or customer	Shows who is affected by a problem
Owner and backup	Someone accountable who can change DNS and the sending account
Records and selectors	SPF include list, DKIM selectors and DMARC policy in force
Created, reviewed, retired	Makes clean-up routine, not a hunt

Protect the accounts behind the names too: the registrar, the DNS host and the sending platform, with multi-factor sign-in and more than one administrator. Expiring domains and forgotten delegations are a common source of outages and of takeover risk. Monitor each subdomain separately, using the approaches in email deliverability metrics and Google Postmaster Tools.

A short checklist

1. Every brand, product, region and mail type is listed with an owner.
2. Each sending subdomain has a stated purpose and a consistent name.
3. Transactional and marketing mail are on different names.
4. SPF, DKIM and aligned return-path records exist for every sending subdomain.
5. DMARC is published at the organisational domain, with sp set on purpose, and reports go to one place.
6. Customer-owned or provider-owned domains are decided and documented for agency or platform sending.
7. New subdomains are warmed up and watched separately.
8. Unused subdomains are retired and their records removed.

Further reading and sources

• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures