Should you use separate subdomains for marketing and transactional email?

Most businesses send three kinds of email: people writing to people, transactional messages such as invoices and password resets, and marketing. If they all share one domain, a bad newsletter can drag down your invoices and your sales team's replies. Separate subdomains let receivers judge each stream on its own record. This guide explains why, where the isolation stops, and how to set up authentication for each subdomain.

Why separate marketing and transactional email?

Mailbox providers build reputation from what recipients do with your mail. Marketing draws more complaints and less engagement than receipts and alerts. Mixed together, the weaker stream pulls the stronger one down.

The industry guidance is consistent:

• M3AAWG's Sending Domains Best Common Practices says: "Receivers request (and may require) that different types of email traffic be separated when possible." It recommends that senders "assign a separate subdomain of the main domain name for each distinct sending purpose", keeping the main domain for corporate, one-to-one mail.
• Microsoft Learn advises using a subdomain such as marketing.contoso.com for services "that aren't under your direct control (for example, bulk email services)", because "You don't want issues with mail sent from those email services to affect the reputation of mail sent by users in your main email domain."
• Yahoo says: "Don't send bulk/marketing email from the same IPs you use to send user mail, transactional mail, alerts, etc." and that "Each IP and DKIM domain has a reputation."

Separation also helps you. When deliverability drops, you can see which stream caused it.

What does a sensible layout look like?

For a typical small business:

M3AAWG's own example uses offers.mybrand.com for marketing and info.mybrand.com for transactional mail. Larger senders can split further, by country or department. M3AAWG says that helps "distinguish reputations and aid in troubleshooting".

Naming tips

• Make the name match the mail. M3AAWG says the subdomain "should be relevant to the type of email traffic sent", noting that filtering can include human review, "so 'words matter'". news. or offers. for marketing, mail., notify. or billing. for transactional.
• Use a subdomain of your real domain, not a lookalike. M3AAWG says cousin domains such as example-mail.com "look like phishing campaigns to users and anti-abuse systems alike" and that their use is "strongly discouraged".
• Put a web page behind it. M3AAWG recommends that domains in the visible From "resolve or forward to a live current web page".
• Keep it for years. Reputation builds over time. M3AAWG recommends continuing to use the chosen domain over time.

How much does a subdomain really isolate reputation?

Less than many guides suggest. A subdomain gives receivers a separate identity to score, but it stays tied to its parent.

Gmail counts by the primary domain. Google's sender guidelines FAQ says "we count all messages sent from the same primary domain". Its example is a sender that sends 2,500 messages a day from solarmora.com and 2,500 from promotions.solarmora.com, which together make it a bulk sender. Google adds that bulk sender status is permanent: "Bulk sender status doesn't have an expiration date."

Alignment is checked at the organizational level. The same FAQ requires the From header's "organizational domain" to align with the SPF or DKIM organizational domain. Google doesn't document how it weighs a subdomain's reputation against its parent's, so don't assume a subdomain walls off your main domain.

Some blocklists list the whole domain. The Spamhaus DBL FAQ says: "DBL lists at the main domain level, and all hostnames and subdomains of that domain also return a 'listed' result." If marketing on news.example.com gets your domain onto the DBL, example.com is listed too.

Reputation flows both ways. M3AAWG says "Proper use of subdomains will help your sending program benefit from the organizational domain's existing reputation." That's the upside of using a subdomain rather than a new domain, and also a sign that the two are linked.

So separate subdomains reduce the impact of a problem stream; they don't remove it. Bad list practices, such as hitting spam traps or ignoring complaints, can still hurt the whole domain.

How do you set up SPF, DKIM and DMARC per subdomain?

SPF and DKIM are per domain name, not inherited. DMARC is inherited unless a subdomain publishes its own record. Microsoft summarizes it: the DMARC record "automatically covers all subdomains", but "each subdomain requires an SPF and DKIM record for DMARC."

SPF: on the Return-Path domain

SPF is checked against the envelope sender, also called the Return-Path or bounce address. M3AAWG says the SPF record goes "in the DNS zone of the Return-Path domain". If your marketing platform uses an address at news.example.com as the Return-Path, that's the name that needs the platform's SPF include:

news.example.com.         TXT  "v=spf1 include:spf.marketing-platform.example ~all"

Some platforms use a deeper name, such as bounce.news.example.com, and host the record for you through a CNAME. Publish exactly what the platform asks for.

Keep the main domain's SPF record for your mailbox provider only. That also keeps it under the 10-lookup limit. See SPF record syntax for the details.

DKIM: sign with the subdomain or the main domain

Each provider should sign with your domain, not its own. M3AAWG says "It is best practice for each sending subdomain to send using a different selector", so a leaked key affects only one stream. Most platforms give you CNAME or TXT records to publish under the subdomain, such as s1._domainkey.news.example.com. Check them with the DKIM Checker, and see how to find a DKIM selector if you don't know it.

MX and role addresses

M3AAWG says domains used to send email "should have a proper MX record pointing to a functional email server", and that abuse@ and postmaster@ "must exist, be read, and never bounce". Many platforms handle bounces at their own MX for the Return-Path subdomain. Make sure replies to the visible From address reach a real mailbox.

DMARC: one record on the parent, or one per subdomain

You have two options.

Option 1: one record on the organizational domain, using sp. sp sets the policy for existing subdomains that don't have their own record. RFC 9989 says that if sp is absent, and np doesn't apply, the p policy "MUST be applied for subdomains".

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

Option 2: a separate record on a subdomain. Useful while a new stream is still being tested:

_dmarc.news.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

RFC 9989 notes that sp "will be ignored" in a record published on a subdomain, so control a subdomain's policy with its own p. M3AAWG treats per-subdomain records as acceptable but says "the goal is for the record to ultimately be on the organizational domain". Microsoft agrees: once the policies match, you can remove the subdomain records and rely on the parent. Our DMARC subdomain policy guide covers sp and np in depth, and DMARC record examples has more patterns.

Does the From address need to use the subdomain?

Not for authentication. M3AAWG says sending from a subdomain "does not mean that the visible From: must also use the subdomain, so long as the organizational domains in each match". DMARC's default relaxed alignment allows billing@example.com in the From with DKIM signed by mail.example.com. Using the subdomain in the From as well keeps the separation clear to receivers and recipients, which is common for marketing.

Setup checklist

1. List your streams and which platform sends each one.
2. Choose a subdomain per stream, named for the mail it carries.
3. Add each subdomain in the sending platform and publish the SPF, DKIM and, if needed, MX or tracking records it gives you.
4. Check each record with the SPF Checker, DKIM Checker and DMARC Checker.
5. Decide on DMARC: sp on the parent, or a temporary p=none record on the new subdomain.
6. Warm up the new subdomain. M3AAWG notes that changing the sending domain "can require a ramp-up for the new combination" and suggests considering "6 weeks of warm-up as an average". See email warm-up.
7. Monitor each stream separately in Google Postmaster Tools and your DMARC reports.

When is separation not worth it?

M3AAWG says each segment should be able to "create and grow its own reputation, which requires sufficient and relatively consistent traffic volume". A subdomain that sends a few hundred messages a quarter never builds much reputation. For small volumes, M3AAWG says "it is acceptable to use different local parts", such as news@ and receipts@ on one domain.

The split that almost always pays off is the first one: keep bulk and automated mail off the domain your staff use every day. If you send through a dedicated provider, read shared vs dedicated IPs before paying for a dedicated IP.

Next steps

• Write down every service that sends as your domain, and decide which subdomain each should use.
• Move marketing first, since it carries the most risk, and warm the new subdomain up gradually.
• Set sp= on your main DMARC record so subdomains are covered, and check it with the DMARC Record Generator.
• For low-volume mail from scanners and website forms, a relay that signs with your domain helps too. iBlockSpam's outbound relay adds DKIM signing and includes 500 messages a month per domain; it isn't meant for bulk marketing.