Subdomain or Separate Domain for Bulk Email?

Introduction

For most organisations, send bulk and marketing email from a subdomain of the main brand domain, such as news.example.com, not from a separate domain. A subdomain stays recognisably yours, inherits DMARC protection from the organisational domain and keeps marketing platforms out of the main domain's SPF record. A separate domain looks unfamiliar to recipients and needs its own full authentication setup.

A subdomain is not a reputation firewall, though, and it does not get around bulk sender thresholds. This article explains what the mailbox providers actually say, how RFC 9989 handles subdomain policy, and the setup an MSP should recommend. For the policy mechanics in general, see DMARC for subdomains, and for the protocol, the DMARC guide.

Key takeaways

• A subdomain such as news.example.com is usually the right choice for marketing and bulk mail.
• Google counts subdomain mail towards the primary domain's bulk threshold, so a subdomain does not avoid the bulk sender rules.
• Google advises separating message types by From address and sending IP. It does not promise separate reputation for subdomains.
• Under RFC 9989, a subdomain without its own record inherits the organisational domain's sp= policy through the DNS tree walk.
• A separate domain needs its own SPF, DKIM, DMARC and parked-domain hygiene, and can look like phishing to recipients.

Why use a subdomain for bulk email?

Because it separates the work without separating the brand. Each marketing or bulk platform gets its own namespace, so its SPF include, DKIM keys and return-path live on the subdomain rather than crowding the main domain. Recipients still see the brand they know, and aggregate reports show the subdomain's traffic on its own lines.

The practical benefits are operational:

• SPF lookup budget. The main domain's SPF record keeps its 10-lookup limit for the mail platform; each sending subdomain has its own budget.
• Independent enforcement. A subdomain can carry its own DMARC record, so it can move to p=reject on its own timetable, or stay behind while a new platform is fixed.
• Clean reporting. Traffic and failures for the marketing platform are easy to separate in the reports.
• Contained mistakes. A misconfigured marketing platform affects the subdomain's authentication, not the main domain's mail flow.

Does a subdomain protect the main domain's reputation?

Not reliably, and the providers do not promise it. Google's sender guidelines advise separating message categories by From address and, where several IPs are used, by sending IP. They do not say that subdomains carry separate reputation, and they warn that spam reports can lower a domain's reputation over time.

Google is explicit on one related point: in its sender guidelines FAQ, messages from subdomains count towards the primary domain for the bulk sender threshold. Its example adds 2,500 messages from a domain and 2,500 from its promotions. subdomain, which together make the sender a bulk sender. So treat a subdomain as an organisational and authentication boundary, not as a way to escape the rules or hide poor list hygiene.

How does DMARC treat a subdomain?

A receiver first looks for a DMARC record at the subdomain itself. If there is none, RFC 9989 has it perform a DNS tree walk up to the organisational domain and apply that domain's subdomain policy. The tree walk makes at most eight DNS queries, however long the name.

Three tags decide what happens to a subdomain without its own record:

If the subdomain publishes its own record, that record wins. The sp= tag is ignored on records published at subdomains. Alignment works naturally: under relaxed alignment, a DKIM signature from news.example.com aligns with a From address at news.example.com or at example.com, because both share the organisational domain. Non-existent subdomains and the np tag covers the new tag in detail.

What is wrong with a separate domain for marketing?

Mostly that it is a second domain to secure, and that recipients cannot tell it is yours. A brand that sends from example.com but markets from example-news.com or getexample.com trains its customers to trust unfamiliar domains, which is exactly what phishing relies on.

It also doubles the work:

1. Full authentication again: SPF, DKIM and a DMARC record moving from p=none to p=reject, all maintained separately.
2. No inherited policy: the main domain's sp= and np= do nothing for an unrelated domain.
3. Separate monitoring and renewals: reports, registrar access and expiry dates for one more domain.
4. A lapse risk: when the campaign or agency relationship ends, the domain is often abandoned, and an abandoned domain with a good sending history is attractive to attackers.

A separate domain makes sense in narrower cases: a genuinely separate brand, a business unit with its own identity, or a legal entity that must not share the parent's name. Then it is not a marketing trick but a different organisation, and it deserves its own full setup.

Which setup should an MSP recommend?

One subdomain per sending purpose, each with its own authentication, under a main domain that is already at enforcement. A typical layout:

And the matching records on the organisational domain and one sending subdomain:

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

The organisational domain protects every subdomain that has no record of its own, including names nobody has created yet. The marketing subdomain publishes its own record while the platform is being fixed, then moves through p=quarantine to p=reject. Under RFC 9989 there is no pct tag, so each move is a full step. Marketing mail also needs one-click unsubscribe, signed by the subdomain's DKIM key.

How do you move bulk mail to a subdomain?

Plan it as a sender migration, not a DNS change. In order:

1. Choose the subdomain and tell the client's marketing team what will change in the From address.
2. Set up SPF and custom DKIM for the platform on the new subdomain, and publish its DMARC record at p=none with reporting.
3. Send a small volume first from the new From address and confirm alignment in the aggregate reports.
4. Move campaigns over gradually, starting with the most engaged recipients, and keep From addresses consistent per category, as Google advises.
5. Remove the platform from the main domain's SPF record once nothing sends from it there.
6. Enforce the subdomain in full steps once the reports are clean.

How to handle third-party senders covers the vendor side of the move, and DMARC client discovery helps find every platform that should move.

FAQ

Does sending from a subdomain avoid Google's bulk sender rules?

No. Google counts messages from subdomains towards the primary domain's total, so mail from example.com and promotions.example.com is added together when deciding whether a sender is a bulk sender.

Does a marketing subdomain need its own DMARC record?

Not strictly: without one, receivers apply the organisational domain's sp= policy. A record of its own is useful while the platform is being configured, because it lets the subdomain stay at p=none while the main domain is at p=reject.

Will spam complaints on the subdomain hurt the main domain?

They can. Google does not say that subdomains carry separate reputation. Use a subdomain for clean authentication and reporting, and keep complaint rates low on every stream.

Should transactional and marketing mail use different subdomains?

It is a good default. Google advises keeping each category of message on a consistent From address and, where you use several IPs, a separate IP per type. Different subdomains make that separation visible in your reports as well.

What policy should unused subdomains get?

Reject. Set sp=reject and np=reject on the organisational domain once its own mail is at enforcement, so subdomains without their own record, and names that do not exist, cannot be spoofed.

Final thoughts

A subdomain is the sensible home for bulk email: it keeps the brand, isolates the configuration and inherits protection from a domain that is already at p=reject. Just do not expect it to hide a bad list or dodge the bulk rules. The reputation is still yours, and the providers count it that way.