A subdomain strategy for sending mail

19 March 2026 · 12 min read

Why one domain sending everything is a reputation trap

Most organisations start with a single sending domain. The marketing team blasts a newsletter from marketing@yourcompany.com, the app fires password resets and receipts from noreply@yourcompany.com, the sales team sends one-to-one mail from real firstname@yourcompany.com mailboxes, and the finance system emails invoices from somewhere in the same namespace. Every one of those streams shares a single reputation at the mailbox providers, because Gmail, Microsoft and Yahoo increasingly attach reputation to the signing domain (the DKIM d= value and the aligned From domain), not just to the sending IP.

That shared reputation is the problem. A marketing send to a stale list that draws spam complaints does not just hurt the newsletter. It drags down the reputation of the exact same domain your password resets and invoices depend on. Suddenly a customer who clicked "forgot password" does not get the email, because the domain's reputation tanked over a promotion they never asked for. The streams have completely different risk profiles, but they are tied to one fate.

A subdomain sending strategy fixes this by giving each stream its own identity. Transactional mail goes out as t.yourcompany.com, marketing as news.yourcompany.com or mkt.yourcompany.com, corporate person-to-person mail stays on the apex yourcompany.com, and each carries its own DKIM keys, its own reputation, and its own DMARC controls. This article is specifically about how to design that split, what it buys you for deliverability and for DMARC enforcement, and the concrete DNS and policy records you need to make it work without breaking anything.

If you want to see what your domain looks like today before you carve it up, run it through the DMARC checker and the SPF checker first, and map your current senders with the DMARC report analyzer. You cannot split traffic sensibly until you know what is actually sending.

Reputation is per identity, so isolate the risky streams

The single strongest argument for subdomains is reputation isolation. Each sending stream has a different complaint rate, a different bounce rate, and a different engagement profile, and the mailbox providers judge them on exactly those signals.

• Transactional mail (password resets, receipts, order confirmations, security alerts, two-factor codes) is the gold standard for reputation. Recipients open it, expect it, almost never mark it as spam, and it goes to clean addresses they just typed in. This stream wants the highest, most protected reputation you have, because it is the mail that absolutely must reach the inbox.
• Marketing and bulk mail (newsletters, promotions, lifecycle campaigns) is the volatile stream. It goes to large lists, some of which decay, and it attracts the "this is spam" clicks. Its complaint rate is structurally higher than transactional, no matter how good your list hygiene is.
• Corporate person-to-person mail (your employees emailing customers, partners, suppliers from real mailboxes) is low volume, high trust, and replied to. It should never share an identity with a bulk sender.

If all three share yourcompany.com, the marketing complaint rate becomes the apex domain's complaint rate, and the transactional and corporate streams inherit it. Split them, and a bad campaign on news.yourcompany.com stays contained on news.yourcompany.com. The receivers learn three separate reputations, and the one that matters most (transactional) is insulated from the one that is hardest to control (marketing).

This is the same logic behind dedicated IP warming, where you build reputation on an isolated IP rather than poisoning a shared one. The domain dimension matters just as much now, often more, because IP reputation has been steadily giving ground to domain reputation. If you are also warming IPs, the two strategies reinforce each other; see IP warming for new sending IPs for how the IP side works.

How subdomains make DMARC enforcement dramatically easier

Reputation is the deliverability case. The DMARC case is just as strong, and it is the one most people underestimate.

DMARC enforcement (getting to p=reject) is hard in proportion to how many distinct sources send as a single domain. Every source has to be authenticated and aligned before you can safely turn on enforcement, because at p=reject any unaligned mail is rejected. The more crowded a domain is, the more sources you have to chase down, and the higher the chance one of them quietly breaks when you tighten the policy.

When you split streams across subdomains, you split the enforcement problem too. Each subdomain has a small, well-understood set of senders:

• t.yourcompany.com is signed only by your transactional ESP. One source, easy to align, easy to push to p=reject.
• news.yourcompany.com is signed only by your marketing platform. One source, same deal.
• The apex yourcompany.com carries your corporate mail server (Google Workspace, Microsoft 365) and a much shorter list of anything else.

Instead of one domain with eight tangled senders that you dare not enforce, you have four namespaces each with one or two senders that you can confidently reach p=reject on. You can also enforce them independently and at different speeds: lock down the transactional subdomain to p=reject quickly because it is simple and clean, while you take longer over the apex where the corporate mail and stray legacy systems live.

There is a second, subtler DMARC win. DMARC has a sp= tag (subdomain policy) that sets the policy for subdomains that do not publish their own record, and an np= tag for non-existent subdomains. A clean subdomain strategy lets you publish a default-deny posture for everything you have not explicitly designated as a sender, which shuts down a whole class of subdomain spoofing. We cover the mechanics of that below.

The reference layout: a worked example

Here is a concrete, opinionated layout for a typical company that does transactional, marketing and corporate mail. Adapt the names, keep the shape.

yourcompany.com          corporate person-to-person mail (Google Workspace / M365)
t.yourcompany.com        transactional (SES, Postmark, SparkPost, etc.)
news.yourcompany.com     marketing / bulk (Mailchimp, Klaviyo, HubSpot, etc.)

Some larger estates go further and split again, for example separating product notifications from billing, or separating different business units. The principle scales: the more independent the reputation needs to be, the more it earns its own subdomain. But do not over-split. Every subdomain needs its own DKIM keys, its own DMARC record, its own monitoring and its own warm-up. Three or four well-chosen subdomains beat a dozen half-managed ones.

A note on naming. Use short, boring, obviously-internal labels (t, news, mkt, mail, em). Do not use a separate organisational domain like yourcompany-mail.com for this. A different registered domain is a different organisational domain for DMARC purposes, it shares no reputation halo with your brand, it is a lookalike-domain risk in its own right, and it cannot benefit from your apex DMARC policy. Subdomains of your real domain are the right tool; cousin domains are a deliverability and trust mistake. (If you are worried about lookalikes generally, the lookalike domain checker is the relevant tool, but that is a separate concern from this strategy.)

Setting up each subdomain: the records you actually publish

A subdomain is a first-class email identity. Each sending subdomain needs the full authentication stack, published at the subdomain, not inherited from the apex.

SPF, published at the subdomain

SPF does not inherit down the tree. t.yourcompany.com needs its own TXT record, and it should list only the provider that sends transactional mail, nothing else:

t.yourcompany.com.  TXT  "v=spf1 include:amazonses.com -all"

This is a hidden bonus of the split. Because each subdomain has only one sender, its SPF record is tiny and nowhere near the 10-DNS-lookup limit that strangles crowded apex SPF records. The classic too many SPF DNS lookups failure happens on overloaded single-domain SPF; a per-subdomain split sidesteps it almost entirely. Use the SPF checker to confirm each subdomain's record resolves within budget.

Note that the SPF check authenticates the envelope-from (return-path) domain, which your ESP usually controls, not the visible From. Alignment is what ties it back to the subdomain you care about. If the distinction is fuzzy, header From versus envelope From is the explainer.

DKIM, with keys scoped to the subdomain

Have the provider for each stream generate DKIM keys and publish the selector under the relevant subdomain. The transactional provider's selector lives under t.yourcompany.com:

selector1._domainkey.t.yourcompany.com.  CNAME  selector1.dkim.amazonses.com.

The marketing provider signs with d=news.yourcompany.com and publishes its selector there. The crucial outcome is that each provider signs with a d= value that is the subdomain you assigned it, so its reputation accrues to that subdomain and its DMARC alignment is clean. If your provider lets you choose the signing domain, set it to the subdomain explicitly. Verify with the DKIM checker once published.

DMARC, one record per sending subdomain

Each sending subdomain publishes its own DMARC record at _dmarc.<subdomain>. This is what lets you enforce streams independently:

_dmarc.t.yourcompany.com.     TXT  "v=DMARC1; p=reject; rua=mailto:reports@yourcompany.com; adkim=s; aspf=s"
_dmarc.news.yourcompany.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:reports@yourcompany.com; adkim=r; aspf=r"

Notice the two records can differ. The transactional subdomain is at p=reject with strict alignment, because it has exactly one well-understood sender and you can guarantee an exact-match d=. The marketing subdomain might sit at p=quarantine with relaxed alignment for a while longer because the marketing platform's mechanics are messier. That independence is the entire point. If you are weighing strict against relaxed for each stream, relaxed versus strict DMARC alignment walks through the decision per source.

A subtle DMARC fact worth knowing: when a subdomain publishes its own _dmarc record, that record governs it completely. When a subdomain does not publish its own record, receivers fall back to the apex policy, specifically the apex sp= tag. So a sending subdomain always gets its own record; the apex sp= covers everything else.

Locking down the apex and the subdomains you do not send from

Once your real senders each have a subdomain, the apex record does two jobs: it sets the policy for your corporate person-to-person mail, and it sets the default policy for every subdomain you have not explicitly designated. This is where sp= and np= earn their keep.

_dmarc.yourcompany.com.  TXT  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:reports@yourcompany.com; adkim=r; aspf=r"

• p=reject enforces the apex itself.
• sp=reject says: any subdomain that does not publish its own DMARC record gets reject. Your real sending subdomains override this with their own records (which is exactly why each one publishes its own); everything else, including subdomains an attacker might try to spoof, is rejected by default.
• np=reject (non-existent subdomain policy, from the later DMARC tightening guidance) says: mail claiming to come from a subdomain that does not exist in DNS at all is rejected. Attackers love to spoof random.yourcompany.com precisely because it has no records of its own; np=reject shuts that down.

This default-deny posture is only safe because you have inventoried and designated your real senders. If you set sp=reject while a legacy system is quietly sending from an undeclared subdomain, you will reject that legacy mail. So the order is: find every sender (via aggregate reports), give each legitimate one a designated subdomain with its own record, then tighten sp= and np= to reject. Do it in that order and nothing breaks.

There is a related security angle here. Subdomains that exist in DNS but no longer point at anything live (a CNAME to a deprovisioned service, for instance) are a takeover risk: an attacker who claims the dangling target can send authenticated mail from your subdomain. A subdomain strategy means you have more subdomains to keep tidy, so audit them. Subdomain takeover covers the mechanics and the cleanup.

Migrating an existing single-domain setup without an outage

If you are sending everything from one domain today, do not move it all at once. Reputation does not transfer between identities; a brand new subdomain starts from zero reputation, exactly like a cold IP. Moving a large stream onto a fresh subdomain overnight will tank deliverability while receivers learn the new identity. Migrate stream by stream, warming each one.

1. Inventory first. Turn on DMARC aggregate reporting at the apex (p=none is fine to start) and read several days of reports to build a complete list of who sends as your domain. The DMARC report analyzer turns the XML into a readable source breakdown, and if reports surface senders you do not recognise, DMARC reports show unknown sources helps you triage them.
2. Stand up the new subdomain fully. Publish SPF, DKIM and a p=none DMARC record on, say, news.yourcompany.com, and configure the marketing platform to send and sign from it. Confirm alignment with the report data before you move volume.
3. Warm the new identity. Move traffic onto the subdomain gradually, starting with your most engaged recipients, exactly as you would warm an IP. A fresh signing domain needs the same ramp. Do not cut the whole list over on day one.
4. Tighten that subdomain's policy. Once reports show clean alignment and reputation is established, take the subdomain from p=none to p=quarantine to p=reject on its own schedule.
5. Repeat per stream, then finally lock the apex with sp= and np=.

The reason this avoids an outage is that each new identity is enforced only after it has been observed clean, and the old apex policy stays permissive until its dependent streams have moved off. Nothing is enforced before it is proven.

Where this strategy interacts with the rest of the stack

A few practical interactions to keep in mind once you are running multiple sending subdomains.

• Reporting addresses. You can point every subdomain's rua= at the same mailbox or endpoint; the reports identify themselves by domain, so a single inbox handles them all. What you must not skip is reading them per subdomain, because each identity now has its own failure surface. Continuous monitoring matters more, not less, when you have more identities. Our emailed monitoring with change alerts watches every record and tells you when one drifts.
• MTA-STS and TLS. MTA-STS protects inbound mail to your domain and is largely an apex-level concern; it is not duplicated per sending subdomain. Check yours with the MTA-STS checker. It is orthogonal to the sending split but worth confirming while you are in the DNS anyway.
• BIMI. If you run BIMI, each From domain that should show your logo needs its own BIMI record and a DMARC policy at enforcement. With a subdomain strategy, your transactional subdomain is the prime BIMI candidate because it is at p=reject and high-trust. Plan BIMI per sending subdomain, not just at the apex; the BIMI checker confirms each one.
• DKIM canonicalisation and forwarding. Per-subdomain signing does not change how forwarding can break DKIM. If your transactional mail is forwarded (helpdesk, distribution lists), the same survival rules apply; see DKIM canonicalisation, simple versus relaxed.

The practical takeaway

Splitting your mail across subdomains is not cosmetic tidiness. It is the single highest-leverage decision for both deliverability and DMARC enforcement, because reputation and enforcement difficulty are both attached to the sending identity, and a subdomain gives each stream its own identity to succeed or fail on its own terms. Transactional mail gets the protected, high-trust reputation it needs to always reach the inbox; marketing volatility stays quarantined on its own subdomain; corporate person-to-person mail keeps the apex clean; and every stream becomes small and simple enough to push to p=reject independently, while sp=reject and np=reject slam the door on every subdomain you never send from.

The order is what keeps you safe: inventory your real senders from aggregate reports, give each legitimate stream a fully authenticated subdomain, warm each new identity, enforce it once it is observed clean, then lock the apex default to deny. Do it in that sequence and you reach p=reject across the whole estate with no email outage.

Start by seeing what your domain looks like today with the DMARC checker and mapping your real senders with the DMARC report analyzer. If designing the subdomain split, generating and publishing per-stream SPF, DKIM and DMARC records, warming each identity and tuning the policies from p=none to p=reject is more than you want to own in-house, our done-for-you hosted DMARC service takes the whole estate, subdomains included, safely to enforcement without breaking a single legitimate stream.