How to Set Up Multiple Email Subdomains in DNS: A Practical Guide

When your domain starts sending email from more than one place, you need a plan for keeping each sender separate. Marketing platforms, transactional systems, internal IT, support tools - each may send from your domain, and each needs its own authentication records in DNS. If you skip the subdomain structure now, you will pay for it in configuration headaches later.

This guide covers how to set up multiple email subdomains in DNS, with correct SPF, DKIM, and DMARC records for each one. By the end you will have a repeatable process for adding new sending subdomains and a clear view of which tool actually monitors all of them without manual report parsing.

Why Separate Email Subdomains?

Email authentication is tied to domains. SPF authorizes specific mail servers to send for a domain. DKIM adds a cryptographic signature tied to a domain. DMARC checks that the domain in the From header matches the domains proven by SPF and DKIM. If every sender on your domain uses the same root domain configuration, one misconfigured platform can break authentication for everything else.

Separating senders onto subdomains fixes this. When your marketing platform sends from marketing.example.com and your transactional system sends from transactional.example.com, each subdomain has its own SPF, DKIM, and DMARC configuration. A problem with one does not automatically cascade to the others.

Separation also gives you visibility. DMARC aggregate reports show you exactly which subdomain had a failure, so you can identify which platform needs attention without guessing.

Planning Your Subdomain Structure

Before touching DNS, decide which subdomains you need. Common examples:

• marketing.example.com - mass email campaigns from your marketing platform
• transactional.example.com - order confirmations, password resets, receipt notifications
• support.example.com - helpdesk system outgoing mail
• internal.example.com - internal IT systems and automated alerts
• notifications.example.com - application-level notifications from your product

You do not need all of these. Start with the subdomains that correspond to your current sending infrastructure. Add more as you grow.

For each subdomain, assign it a specific sending platform or service. One subdomain, one platform is the cleanest rule. If one platform sends from multiple subdomains, that is fine - but one subdomain should not try to handle two different sending systems.

Setting Up SPF Records for Multiple Subdomains

Each subdomain can have its own SPF record. The record is a TXT record at the subdomain, not at the root.

Example - root domain SPF:

 

example.com TXT v=spf1 include:_spf.example.com ~all

 

Example - marketing subdomain SPF:

 

marketing.example.com TXT v=spf1 include:servers.mcsv.net ~all

 

The marketing subdomain SPF says "only the MailChimp servers at mcsv.net are authorized to send for marketing.example.com." That record does not affect transactional.example.com at all.

If you want a centralized SPF approach, you can also use subdomains to delegate to separate include mechanisms. But the simplest setup for most organizations is a dedicated SPF record per subdomain, listing only the servers that send for that specific subdomain.

Common mistake: copying the same SPF record to every subdomain when the authorized servers are different. Each subdomain needs its own include statements matching its actual senders.

Another common mistake: exceeding the 10 DNS lookup limit in your SPF record. If your include mechanisms chain deeply, test with an SPF checker tool before deploying.

Setting Up DKIM Records for Multiple Subdomains

DKIM works differently from SPF. Instead of listing authorized servers, you add a public key to DNS and the sending platform provides the matching private key. Most email service providers give you a DKIM record to add under a specific selector subdomain.

Example - adding a DKIM record for MailChimp on the marketing subdomain:

 

mcsv1._domainkey.marketing.example.com TXT v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA...

 

The selector (mcsv1._domainkey) is set by your email platform. Each platform typically gives you a different selector name, so you will have different DKIM records for different sending services, even on the same subdomain.

If you run your own mail server, you generate your own DKIM keys and publish them under your own selector. The process is the same - add the TXT record to DNS, and your mail server uses the private key to sign outgoing mail.

Important: DKIM keys are per-selector, not per-domain. Two different selectors on the same subdomain can have different keys, and both are valid. This means you can have DKIM signatures from multiple platforms on the same subdomain, each using its own selector.

If you are migrating platforms, do not remove the old DKIM record until you have confirmed the new platform is signing correctly. A gap in DKIM coverage causes authentication failures.

Setting Up DMARC Records for Each Subdomain

DMARC has two placement options for multi-subdomain setups.

Option 1: Wildcard DMARC at the root domain

Create a DMARC record at _dmarc.example.com that applies to all subdomains:

 

_dmarc.example.com TXT v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; sp=quarantine; adkim=r

 

The sp tag sets the policy for subdomains separately from the root. With sp=quarantine and adkim=r (relaxed alignment), every subdomain inherits the same DMARC policy unless overridden.

This approach is simple to manage. One record covers everything. The tradeoff is that you do not get per-subdomain failure isolation in the aggregate reports.

Option 2: Dedicated DMARC record per subdomain

Create separate DMARC records for each sending subdomain:

 

_dmarc.marketing.example.com TXT v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=r _dmarc.transactional.example.com TXT v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=r

 

With this approach, marketing uses a quarantine policy while transactional uses reject. Each subdomain can have its own policy based on how critical that sending channel is. Your transactional system should probably be at p=reject from day one because those are your real customer communications. Your marketing subdomain might start at p=quarantine while you confirm all your list sources are correctly configured.

The tradeoff is more DNS records to manage. The benefit is granular control and clearer failure reporting per subdomain.

For most growing setups, starting with a wildcard DMARC at the root domain and using the sp tag to set subdomain defaults is the right move. You can migrate to per-subdomain DMARC records once you have more sophisticated sending infrastructure.

Common Configuration Mistakes

Starting with p=reject before testing. If you set p=reject on a subdomain before confirming your SPF and DKIM are working correctly, you will lose legitimate email. Always start at p=none, review aggregate reports for two to four weeks, move to p=quarantine, and only go to p=reject when you have confirmed zero alignment failures from legitimate senders.

Using the same DKIM selector for different platforms. A DKIM selector is a string like "mcsv1" or "google". If you add DKIM records for two different platforms using the same selector name, the second one overwrites the first. Always use the selector name your platform specifies.

Forgetting that SPF lookups count toward the 10-lookup limit. If your SPF record has 10 includes and one of those includes another SPF record, you have already used one of your lookups. Exceeding the limit causes SPF to return permerror and servers may fall back to softfail. Use include: carefully and check with an SPF analyzer.

Not monitoring aggregate reports. Setting DMARC records without reviewing the reports means you are flying blind. Most organizations that have DMARC failures do not know about them until a deliverability problem surfaces. Aggregate reports are the only way to see which senders are failing and why.

Monitoring All Your Email Subdomains in One Place

When you have three, five, or ten email subdomains, reviewing separate DMARC reports for each one becomes a manual task that nobody does consistently. That is where a dedicated DMARC monitoring tool earns its place.

DMARCFlow processes DMARC aggregate reports for all your subdomains into a single dashboard. Instead of downloading XML files from multiple subdomains and cross-referencing them manually, you see authentication health across your entire domain portfolio in one view. You can see at a glance which subdomain had a spike in failures, which platform is generating alignment errors, and which senders still need their SPF or DKIM configuration corrected.

For organizations running multiple email sending subdomains, this is not a nice-to-have - it is the difference between actually reviewing your authentication reports and meaning to review them. Manual DMARC report parsing for five subdomains takes hours per week. DMARCFlow automates the aggregation so your team spends time fixing problems instead of finding them.

Each subdomain you configure becomes a discrete monitoring channel. When a marketing platform changes their sending infrastructure and forgets to update their SPF record, you see it as a spike in marketing.example.com failures before it affects your deliverability.

FAQ

Can one SPF record cover all my subdomains?

Yes, technically. You can use a wildcard in your root SPF record or create a record at _dmarc.example.com that applies to all subdomains. But a single root SPF record means every subdomain authorizes the same servers. If your marketing platform sends from marketing.example.com and your transactional system sends from transactional.example.com, they probably do not use the same mail servers. Separate SPF records per subdomain are cleaner and give you better failure isolation.

Do I need separate DKIM keys per subdomain?

You need separate DKIM selectors per sending platform, which may mean separate subdomains. Most email service providers give you a DKIM record to publish under a subdomain you control. If you use two different platforms, they will give you different selector names. You can publish both under the same subdomain if the selectors are different, or use separate subdomains for each platform. Either works - just do not use the same selector name for two different platforms.

What DMARC policy should I start with?

Start at p=none. This collects aggregate reports without taking action. After two to four weeks of reports, review who is failing and why. If failures are from legitimate senders with misconfigured authentication, help them fix it. Once the failure rate from legitimate senders is near zero, move to p=quarantine. Then monitor for another two to four weeks before moving to p=reject.

How do I monitor all my subdomains at once?

Use a DMARC reporting tool that supports multiple subdomain monitoring. DMARCFlow aggregates reports from all your subdomains into a single dashboard, so you can track authentication health across your entire domain portfolio without logging into separate platforms or manually parsing XML reports. If you are managing multiple subdomains without a dedicated monitoring tool, that is a sign you need one - the manual effort of cross-referencing multiple DMARC reports is what causes teams to stop reviewing their reports entirely.

What happens if I set p=reject before my SPF and DKIM are correct?

Legitimate email stops being delivered. Your transactional confirmation emails, password reset links, and notification messages will be rejected by receiving servers. This is why the progression from p=none to p=quarantine to p=reject exists. Each step gives you time to discover and fix problems before email stops flowing.