Domain Strategy for Complex Senders

Mailbox providers like Gmail give every sending domain a reputation, built from how people react to its mail. This article shows how to split your email across your main domain, subdomains and separate domains, so a risky newsletter can’t drag down your password-reset emails. It also covers the DNS records each domain needs, and how to start and retire one safely.

Why your domain matters

Providers judge both the IP address an email came from (the numeric address of the sending server) and the domain in its From address. You can change or warm up an IP in weeks. A domain’s reputation takes months to build, and longer to repair.

A good domain plan:

1. Contains damage. A problem in one kind of mail doesn’t spread to the others.
2. Keeps your brand clear. Readers see a name they know.
3. Lets teams work on their own. Marketing can send without putting product email at risk.

Three ways to set up your domains

The volumes below are rules of thumb, not provider rules.

One domain

shop.example
├── Transactional: noreply@shop.example
├── Marketing: hello@shop.example
└── Support: support@shop.example

Use it for: under about 50,000 emails a month, one product, a small team. It’s simple, and all your reputation builds on one name.

Risk: there’s no separation. Transactional email is mail people get because of something they did, like receipts and password resets. If a marketing email draws lots of spam complaints, that mail suffers too.

Subdomains

A subdomain is a name under your domain, like news.shop.example. You create it in DNS at no cost.

shop.example (website, not used for bulk sending)
├── mail.shop.example (transactional)
├── news.shop.example (marketing and newsletters)
├── alerts.shop.example (automated notifications)
└── support.shop.example (support conversations)

Use it for: about 50,000 to 1 million emails a month, with several kinds of mail that carry different risk. Each subdomain builds its own reputation, and starts with some of the main domain’s trust. A marketing problem hurts your transactional mail much less. You can add a subdomain whenever you add a new kind of mail.

Risk: providers can still see that the subdomains belong together. Serious damage to one can partly spill over.

Separate domains

shop.example (website, not used for bulk)
├── mail.shop.example (transactional)
└── news.shop.example (newsletters)

newsletter.example (separate marketing domain)
├── promo.newsletter.example (promotions)
└── events.newsletter.example (event invitations)

Use it for: over about 1 million emails a month, several business units, or high-risk mail you want fully apart. This gives the strongest separation.

Risk: each domain needs its own DNS records, warm-up and monitoring. Readers may not recognize an unfamiliar domain and report it as spam. And separation isn’t total: providers can link domains through shared IPs, the same links or the same sending patterns. A separate domain protects you from one bad campaign. It doesn’t hide bad practice.

Naming your subdomains

Pick short names that say what the mail is:

Good	Avoid
mail.shop.example	m.shop.example (too cryptic)
news.shop.example	marketing-v2.shop.example
notifications.shop.example	n.shop.example
support.shop.example	cs.shop.example

DNS records for each sending subdomain

DNS is the internet’s address book. Each subdomain you send from needs the records below. Check them with the DNS lookup.

SPF

SPF is a DNS record that lists the servers allowed to send email for a domain.

news.shop.example  TXT  "v=spf1 include:_spf.esp.example -all"

v=spf1 marks it as SPF. include: allows your ESP’s servers (an ESP, or email service provider, sends your mail for you). -all refuses every other server. List only the services that really send from this subdomain. SPF is checked on the bounce address, so if your ESP uses its own bounce domain, follow its setup steps.

DKIM

DKIM adds a digital signature to each email. Receivers check it with a public key you publish in DNS.

selector._domainkey.news.shop.example  TXT  "v=DKIM1; k=rsa; p=..."

selector is a name you choose for the key, k=rsa is the key type, and p= holds the public key. Use a different selector for each subdomain, so you can replace one key without touching the others. The DKIM key generator creates the key and the record for you.

DMARC

DMARC tells receivers what to do with mail that fails SPF and DKIM, and where to send reports. When Gmail gets mail from news.shop.example, it looks for a DMARC record on that subdomain first. If there isn’t one, it uses your main domain’s record at _dmarc.shop.example. So one record can cover every subdomain. Add a subdomain record only when it needs a different policy:

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

p=reject asks receivers to refuse mail that fails. rua= is where daily summary reports go. On your main domain, sp= sets the policy for subdomains without their own record. np=, added in RFC 9989 (the current DMARC standard), covers subdomains that don’t exist, so nobody can send as random.shop.example.

MX

An MX record tells other servers where to deliver mail for a name.

news.shop.example  MX  10  inbound.esp.example

10 is the priority (lower is tried first), and inbound.esp.example is the server that receives the mail. It gives replies somewhere to go. It also receives bounces (messages saying an email couldn’t be delivered) if this subdomain is your bounce address.

A record

An A record points a name to an IP address, usually for a website.

news.shop.example  A  192.0.2.1

Many receivers check that the sending domain exists, with an MX or an A record. A name that points nowhere looks fake, and some providers reject its mail.

How reputation moves between a domain and its subdomains

• A head start. A new subdomain borrows some of the main domain’s trust. If shop.example is trusted, news.shop.example starts ahead of a brand-new domain.
• Its own history. Over time, each subdomain earns its own reputation from its own mail.
• Shared damage. If Spamhaus DBL (a widely used blocklist of domains) lists shop.example, every subdomain suffers. Subdomains give partial separation, not complete.

Matching mail types to domains and IPs

A sending stream is one kind of mail with its own readers and risk:

Stream	Risk	Priority	Who gets it
Transactional (receipts, resets)	Low	Must arrive	All users
Product notifications	Low	High	Active users
Marketing, engaged	Medium	Medium	Opened or clicked in the last 30 days
Marketing, broad	High	Medium	The whole list
Re-engagement (win-back)	High	Low	People who stopped opening
Cold outreach	Very high	Low	People who never signed up

The rule: never let high-risk mail share a domain or IP addresses with mail that must arrive. An IP pool is a group of IP addresses your mail goes out from. Give each stream a subdomain and a pool:

MUST ARRIVE (protected)
├── Transactional         → mail.shop.example     → IP pool A
├── Product notifications → notify.shop.example   → IP pool A

STANDARD (monitored)
├── Marketing, engaged    → news.shop.example     → IP pool B
├── Marketing, broad      → promo.shop.example    → IP pool B

HIGH RISK (kept apart)
├── Re-engagement         → reach.shop.example    → IP pool C
└── Cold outreach         → hello.newsletter.example → its own domain and IPs

If a win-back campaign gets your IPs blocklisted, only pool C and reach.shop.example are hit. Receipts keep arriving through pool A.

Cold outreach draws the most complaints, and many countries require the reader’s consent by law. A separate domain limits the damage to your brand. It doesn’t make unwanted mail acceptable.

Starting a new sending domain

Register it

1. Choose a name people recognize. newsletter.example beats a string of random letters.
2. Stay reachable. WHOIS privacy (hiding the public owner record) is fine, but abuse desks must be able to contact you.
3. Put up a simple website. A blank or parked domain looks suspicious.
4. Let it age. A domain registered yesterday that sends 100,000 emails today looks like spam. Wait 2–4 weeks before your first bulk send.
5. Set up SPF, DKIM and DMARC first, before you send anything.

Warm it up

Warming up means raising volume slowly, so providers learn how readers react to you. Start with your most engaged readers:

• Weeks 1–2: 100–500 emails a day.
• Weeks 3–4: 500–2,000 a day.
• Weeks 5–6: 2,000–10,000 a day.
• Week 7 on: keep raising volume step by step while results stay good.

Expect more spam placement and some deferrals (temporary “try again later” replies) at first. Your numbers in Google Postmaster Tools (Google’s free dashboard for senders) should improve slowly.

Retire it

1. Stop sending from it.
2. Keep its DNS records for at least 90 days, so late bounces, replies and DMARC reports still arrive.
3. Keep it registered, or someone else can buy it and receive mail meant for you.
4. Lock it down. Set DMARC to p=reject so nobody can send as it. Once you don’t need replies, publish v=spf1 -all (no server may send) and a null MX record, MX 0 . (the domain receives no mail).
5. Redirect its website to your main domain.

Several brands

One parent domain suits brands that are closely related, share readers, and are known by the parent’s name:

example.com (company)
├── brand-a.example.com (Brand A newsletters)
├── brand-b.example.com (Brand B newsletters)
└── mail.example.com (transactional mail for all brands)

A domain for each brand suits independent brands with different readers. One brand’s problems then stay away from the other:

shop.example (Brand A)
├── news.shop.example
└── mail.shop.example

newsletter.example (Brand B)
├── news.newsletter.example
└── mail.newsletter.example

Monitoring many domains

• Daily, per domain: spam rate and delivery errors in Google Postmaster Tools, and blocklists such as Spamhaus DBL, SURBL and URIBL.
• Weekly: SPF, DKIM and DMARC pass rates per domain, and engagement compared across domains.
• Monthly: reputation compared across domains, and an overall health review.
• Quarterly: check that your split still fits, because your mail changes over time.

Set alerts for a reputation drop on any domain, any blocklist listing (alert right away), and authentication pass rates below 99%.

Checklist

• Choose a model: one domain, subdomains, or separate domains.
• At minimum, send transactional mail and marketing from different subdomains.
• Give each sending subdomain SPF, DKIM, MX and, if needed, its own DMARC record.
• Check them with the DNS lookup, then send to the test inbox to confirm they pass.
• Age and warm up every new domain.
• Lock down retired domains and keep them registered.
• Monitor every domain you send from.