Should you use different domains for different emails?
We asked ourselves this while cleaning up how DocuRise sends email. Login links, receipts, product update letters, and the emails creators send to their subscribers were all going out through the same system.
DocuRise has no passwords. You log in with a link we email you. If that email lands in spam, you can't use the product that day. We didn't want a newsletter to be the reason someone got locked out.
When we looked up email subdomain best practices, we found plenty of "use a subdomain" advice but very little on which emails should go where, or what to name them. So we opened the original headers of real emails from 19 companies and wrote down what we found. If you're working through the same question, we hope this saves you some time.
Here's the short answer: split your sender domains by purpose. Keep transactional email (logins, payments) on your root domain, put team letters (product updates, newsletters) on one subdomain, and put email you send for customers on another. Set up SPF, DKIM, and DMARC on all three, and give transactional email its own sending account.
Splitting domains alone isn't enough, though. The address people see, the domain that signs the email, and the account that actually sends it are three separate things. Let's go through them one by one.
Email subdomain best practices in one picture: 3 addresses, 2 sending accounts
Here's the setup we chose, on one page.

๐บ Split what people see into 3 addresses, and split what actually sends into 2 accounts: one for transactional email, one for bulk
| Purpose | Example address | What it sends | Sending account |
|---|---|---|---|
| Transactional | noreply@example.com | Login links, codes, payments, receipts, security alerts | Transactional only |
| Team letters | team@updates.example.com | Product updates, newsletters, event invites | Bulk |
| Sent for customers | {customer}@send.example.com | Emails your customers send to their subscribers | Bulk |
| 1:1 email from people | name@example.com | Founder email, support replies | Work email (Google Workspace, etc.) |
The idea is simple. Don't mix email that breaks your product when it doesn't arrive with email that doesn't.
Do transactional and marketing emails really need different domains?
Yes. Inbox providers remember reputation separately for each domain and IP address.
Google's sender guidelines say Gmail tracks sending limits and feedback per domain and IP address. The same page recommends using the same From address for the same type of email, and a different IP for each type if you send from more than one.
Email sending services point the same way.
- Postmark recommends keeping transactional and bulk email on separate subdomains, each with its own DKIM and Return-Path.
- Resend recommends sending from a subdomain like updates.example.com instead of your root domain, with separate subdomains for newsletters and account email.
- Customer.io recommends separating your transactional domain from your marketing domain so marketing doesn't hurt your critical messages.
There's an important caveat. ActiveCampaign is clear that subdomains aren't a way to avoid a bad reputation. A subdomain's reputation still affects the root domain. Only the effect between subdomains is small.
So subdomains limit how far a problem spreads. They don't make spam safe to send.
How do other companies split their sender addresses?
We opened the original headers of emails in our own inbox, one by one. We checked the From address, the signing (DKIM) domain, the Return-Path, and the sending tool. Everything below is as of October 2026.
Global companies: transactional on the root, letters on a subdomain
| Company | Transactional and alerts | Product updates and marketing | What stands out |
|---|---|---|---|
| Linear | notifications@linear.app | changelog@updates.linear.app | Both on Amazon SES, letter replies go to support@linear.app |
| Vercel | notifications@vercel.com | ship@info.vercel.com | Letters sent with a separate marketing tool (Marketo) |
| Stripe | notifications@stripe.com | Not checked | Merchant receipts come from receipts+acct_โฆ@stripe.com with the merchant's name |
| Anthropic | invoice+statements@mail.anthropic.com | team@email.anthropic.com | Receipts on SES, marketing on Mailgun |
| Attio | Not checked | hello@mail.attio.com | Changelog from a subdomain, replies go to support@attio.com |
| Notion | notify@mail.notion.so | raphael@mail.notion.so | Alerts and marketing share a subdomain, security alerts use updates.notion.so |
| Supabase | noreply@supabase.com | welcome@supabase.com | Both on the root, transactional on Postmark and letters on Customer.io |
| PostHog | billing@posthog.com | sara@posthog.com | Letters from a person's name, signed by a Customer.io subdomain |
| Mobbin | noreply@mobbin.com | newsletter@mobbin.com | Root address, signed by a Customer.io subdomain |
Three patterns stand out.
- Linear, Vercel, and Stripe send transactional email from the root domain. Only bulk and marketing email moved to a subdomain or another tool.
- No one split product updates and marketing onto different domains. Linear sends its changelog and pricing notices from the same updates.linear.app.
- Some keep the root address and only split the signature. Supabase, PostHog, and Mobbin do this.
Which one fits your company?

๐บ Split the address like Linear (A), or only the signature like Supabase (B). If your root domain uses strict DMARC alignment, A is the right fit
Korean companies: Wanted splits three ways, platforms isolate customer email
| Company | Addresses we saw | Email type | What stands out |
|---|---|---|---|
| Wanted | cs@mail.wantedlab.com / learning@mail.wantedlab.com / news@newsletter.wantedlab.com | Notices / promotions / newsletter | Three lanes, support answered by people uses the root cs@wantedlab.com |
| Coupang | noreply@e.coupang.com / no_reply@coupang.com | Order details / membership billing | Order emails on the e. subdomain (DMARC reject), billing on the root with SES |
| Toss Payments | notification@tosspayments.com / no-reply@tosspayments.com | Verification codes / service notices | Root domain with Amazon SES |
| Channel Talk | feedback@channel.io / team@{customer}.mail.channel.io | Own verification email / customer support email | A separate subdomain per customer, and replies go there too |
| Stibee | support@stibee.com / {id}-gm@send.stibee.com | Own notices / sends from customers using a personal address | Customers without their own domain send from send.stibee.com |
| Publy | hello@publy.co | (Ad) newsletter | Root address, sent through Stibee |
| FastFive | partners@fastfive.co.kr | (Ad) newsletter | Root address, sent through Stibee |
| Remember | notification@rememberapp.co.kr | Personal data usage notice | Root address, Return-Path on ses.rememberapp.co.kr |
| Airbridge | product@airbridge.io | Monthly product update | A dedicated product update address, replies go to the same address |
| Baemin | noreply@woowahan.com | Order details | Root domain |

๐บ Wanted had the cleanest split we found in Korea. Notices and promotions use the mail. subdomain, and the newsletter uses newsletter.
The biggest lesson from the Korean examples came from Channel Talk and Stibee. Services that send email for their customers keep their own email and customer email on different domains from day one. That way, one customer's problem doesn't spread to their own notices or verification emails.
What should you name your addresses? noreply, hello, team, and subdomains
Can a newsletter come from a noreply address?
We don't recommend it. Resend says no-reply addresses signal one-way communication and decrease trust. Stibee also advises against send-only addresses.
noreply is fine for transactional email. People rarely need to reply, and plenty of services already do this. But for a letter people might want to answer, use an address that reaches a real inbox.
hello, team, product, or marketing?
There's no technical difference. Here's what we saw in practice.
| Address | Who uses it | How it reads |
|---|---|---|
| team@ | Anthropic | News straight from the team |
| hello@ | Attio, Publy | A friendly brand hello |
| changelog@ / product@ | Linear / Airbridge | Clearly about product changes |
| newsletter@ / news@ | Mobbin / Wanted | A regular newsletter |
| a person's name@ | PostHog, Notion | A personal note |
| marketing@ | No one we checked | Tells people it's an ad before they open it |
Can people tell what the email is from the address alone? Then you're good.
Just follow one rule. As Google's guidelines say, keep sending the same type of email from the same address. That's where contacts and inbox providers build trust over time.
send, mail, updates, or news for the subdomain?
We found no evidence that a subdomain's name affects spam filtering. So pick a name your team can understand at a glance.
- updates.: Works for product updates and newsletters together. Linear uses it, and Resend uses it as an example.
- news. / newsletter.: Clear when you only send a regular newsletter. Wanted uses newsletter.
- mail. / email.: Means different things at different companies. Anthropic uses mail. for receipts and email. for marketing, while Notion sends almost everything from mail. It's easy to confuse internally.
- send.: Resend uses send. as the default Return-Path. If you want it as a visible address, check it doesn't clash with your Return-Path. Some services, like Stibee, use it for email sent on behalf of customers.
Can split domains still go down together?
Yes. This was the part we think is easiest to miss. Even with separate domains, email sent from the same sending account gets paused together.
Take Amazon SES. If your bounce rate reaches 5%, SES puts your account under review, and at 10% it may pause sending. For complaints, review starts at 0.1% and a pause is possible at 0.5%. These limits apply to the whole account, not to each domain.

๐บ If one customer's bulk send crosses the bounce or complaint limit, login and payment emails on the same account stop too
The risk is higher for platforms that send email for customers. One send to an old list or a list full of typos can spike your bounce rate.
How do you set up SPF, DKIM, and DMARC?
Each one does a different job.
- SPF: A list of servers allowed to send email for your domain. You add it as a TXT record in DNS.
- DKIM: A digital signature on each email. You add the CNAME or TXT values your sending service gives you.
- DMARC: A policy that says what to do when SPF or DKIM doesn't match the From domain. You pick p=none (monitor only), p=quarantine (spam folder), or p=reject (block).

๐บ Example records for a new subdomain. Copy the exact values from your sending service's dashboard
Three mistakes come up often.
- Leaving your work email out of the root SPF. If you send founder email from Google Workspace and your SPF doesn't include include:_spf.google.com, that email fails SPF. It still passes while DKIM holds, but if the signature breaks in forwarding, your DMARC policy can block it.
- Signing only with a subdomain under strict DKIM alignment (adkim=s). With adkim=s on your root DMARC, a root From address needs a signature from exactly the root domain. In that case, move the visible address to the subdomain too.
- Sending a big blast from a brand-new subdomain. Postmark recommends starting with your most engaged users and increasing volume gradually.
How did Gmail and Outlook sender rules change in 2024โ2026?
Big inbox providers have made authentication effectively required.
| Provider | When | Who | Key requirements |
|---|---|---|---|
| Gmail | Feb 2024, stricter enforcement from Nov 2025 | 5,000+ emails a day to personal Gmail | SPF, DKIM, DMARC, From alignment, one-click unsubscribe, spam rate under 0.3% |
| Gmail | Feb 2024 | All senders | SPF or DKIM, spam rate under 0.3% (aim for under 0.1%) |
| Outlook.com | May 5, 2025 | 5,000+ emails a day | Rejected if SPF, DKIM, and DMARC (at least p=none) aren't met |
| Naver Mail (Korea) | Per Stibee's guidance | Sending through outside services | Can't use a naver.com address as the sender |
Gmail says that starting November 2025, it's ramping up enforcement with temporary and permanent rejections for non-compliant mail.
Outlook.com announced that from May 5, 2025, high-volume mail that fails authentication is rejected with error 550 5.7.515.
What about Naver, Korea's biggest email provider? Stibee notes that under Gmail and Naver Mail policies, outside services can't send from gmail.com or naver.com addresses. If you enter a personal address as the sender, Stibee switches it to a send.stibee.com address.
What if you send marketing email to people in Korea?
Korea's Network Act (Article 50) has its own rules for promotional email. The anti-spam guide from KISA and the Korea Media and Communications Commission sets these email rules:
- Get explicit consent first. There's an exception for customers who bought a similar product, for up to 6 months after the purchase.
- Start the subject line with (๊ด๊ณ ), Korean for "ad".
- Include your name and contact details, plus unsubscribe instructions in both Korean and English.
- Let people unsubscribe right away, without logging in.
- The 9 p.m. to 8 a.m. ban on promotional messages doesn't apply to email.
Even a product update letter counts as promotional if it includes a discount, an event invite, or an upgrade pitch. If you're not sure, treat it as promotional and only send it to people who opted in.
๐ Which setup fits your situation?

๐บ Decide by what breaks if the email doesn't arrive, not by volume
| Situation | Recommended setup | Why |
|---|---|---|
| Solo creator, newsletter only | One domain you own + your sending service's SPF and DKIM | Low volume means split domains never build a reputation. gmail.com and naver.com senders get replaced |
| Transactional + occasional letters (early SaaS) | Keep transactional as is, move letters to one updates. subdomain | Keeps your sending history and isolates only bulk email |
| Brand-new product | Put transactional on a subdomain from the start (e.g. notify.) | No history to lose, so following Resend's advice costs nothing |
| Magic-link login or payments | The above + a sending account only for transactional email | Email delivery is your login uptime |
| Platforms sending for customers | 3 addresses + 2 sending accounts + auto-pausing per customer | Lists and content you don't control are the biggest risk |
| Many email types (commerce, marketplaces) | A subdomain and address per type | Like Wanted and Coupang, manage notices, orders, and newsletters separately |
If you've sent transactional email from your root domain for a long time, don't move it to a new subdomain. You'd throw away your sending history and start your reputation from zero.
Here's what we chose at DocuRise
DocuRise helps creators share content, collect leads, turn them into paying customers, and follow up by email. We send the follow-up emails creators write to their subscribers, so we're a "sends for customers" platform.
Here's the setup we picked.
| Purpose | Sender address | Sending account |
|---|---|---|
| Login links, payments, alerts | noreply@docurise.io | Transactional only |
| Product updates, newsletters, meetup invites | team@updates.docurise.io | Bulk |
| Email creators send to their subscribers | {creator}@send.docurise.io | Bulk |
We chose team@ for a reason. Our letters already went out from a team@ address, so keeping the name and changing only the domain felt least jarring for readers. Replies go to the founder's inbox through a separate Reply-To.
You can compare monthly email limits by plan on our pricing page.
FAQ
Will splitting sender domains keep me out of spam?
Not on its own. Splitting domains stops a problem with one type of email from spreading to another. Whether you land in spam still comes down to consent, bounce rate, complaint rate, and content.
Do I need DMARC if I send fewer than 5,000 emails a day?
Gmail's DMARC requirement applies to senders of 5,000+ emails a day. Google still recommends SPF, DKIM, and DMARC for every domain, and volume grows faster than you expect. Set it up now, even at p=none.
Where can I check my spam rate?
For email sent to Gmail, Google Postmaster Tools shows spam rate per domain. Split domains also let you see transactional and newsletter spam rates separately.
Should I buy a completely different domain, like example-mail.com?
We don't recommend it. Postmark notes that using two entirely different domains can look like phishing or spoofing. A subdomain of your main domain is also more trustworthy to readers.
Which DMARC policy should I use: none, quarantine, or reject?
Start with p=none. Google says bulk senders can set their DMARC policy to none. Collect DMARC reports (rua) while on none. Once every sending path passes SPF and DKIM, move to quarantine, then reject. none doesn't stop spoofed email, so move up once you've checked.
Wrapping up
The examples here come from emails in our inbox and public DNS as of October 2026. Companies change their sending setup often, so some of this may already be different.
- We found no evidence that subdomain names (updates, news, send) affect spam filtering. The name is for people.
- If your volume is low, splitting into too many domains means none of them sends enough to build a reputation.
- Splitting only limits how far a problem spreads. Sending without consent or to old lists hurts your reputation with any setup.
If you remember one thing, make it this.
"Does my product break if this email doesn't arrive?" Split out every email where the answer is yes.
Whether it's a login link or a receipt, that email shouldn't share an address or a sending account with anything else.
Related reading
See What Happens After the Click: A Guide to Connecting Meta Pixel to DocuRise
Auto DMs Not Sending on Just One Instagram Post? What to Check



