Picture the moment it goes wrong. Marketing sends a big campaign to a list that has gone stale, complaints tick up, and a few days later your support queue fills with users who never got their password-reset email. The campaign and the password reset have nothing to do with each other, except that they went out from the same domain. To the mailbox providers, that makes them the same sender with the same reputation.
This is one of the most common and most avoidable deliverability mistakes: running every kind of email through one domain. The fix is not a better ESP or a magic header. It is structure. Send each type of mail from its own subdomain so a problem in one stream cannot drag down the others.
TL;DR: Mailbox providers score reputation per sending domain. Different mail types (transactional, marketing, employee) have very different engagement profiles, so mixing them averages your reputation and lets the worst stream hurt the best. Split them onto real subdomains (
mail.yourdomain.comfor transactional,news.for marketing), give each its own SPF, DKIM, and DMARC, warm up each new sender, and lock down any domain that should never send.
Why one domain hurts you
Gmail and Microsoft assign every sending domain a reputation score, and that score is built from engagement signals: are your messages opened, replied to, marked as spam, or left to rot unread? Those signals decide where your future mail lands, inbox, promotions tab, or spam.
The catch is that different kinds of email produce completely different engagement profiles. A password-reset email is opened almost 100% of the time and usually clicked, which is a dream signal. A newsletter with a 25% open rate is perfectly healthy, but next to that reset email it looks dull. Cold outreach from a salesperson can look outright suspicious. Run all of it through yourdomain.com and the provider blends those signals into one average. A neglected marketing list can quietly pull your invoices and login links down with it.
Separating the streams keeps each reputation where it belongs, and that protects marketing as much as it protects transactional. On a subdomain of its own, your campaign reputation reflects your list quality and nothing else, you can warm it up and manage it deliberately, and when deliverability shifts you know which stream owns the problem instead of arguing about it. What happens on news.yourdomain.com barely touches mail.yourdomain.com, and the reverse is just as true.
The setup: one subdomain per job
The established practice, recommended by the major ESPs and spelled out in Google's and Yahoo's bulk-sender guidelines, is to split sending across subdomains. A workable layout for an app called Example looks like this:
| Subdomain | Used for |
|---|---|
example.com (root) | Employee mail through your mailbox provider (Google Workspace, Microsoft 365) |
mail.example.com | Transactional mail from your application (welcome, password reset, receipts) |
news.example.com | Marketing and newsletters |
Each subdomain builds its own reputation, and you can point each one at a different provider. If one goes down or loses IP reputation, the rest of your mail is unaffected.
One thing that catches people out: changing only the part before the @ does nothing. [email protected] and [email protected] are the same domain with the same reputation as far as a mailbox provider is concerned. It has to be a real subdomain in DNS.
Where AhaSend fits
The structure means each stream gets the provider that suits it: a campaign platform for news., your mailbox provider on the root. For the transactional subdomain, the stream where a missed email costs you a signup, a payment, or a support ticket, AhaSend is built for exactly this: transactional-only sending on European, geo-redundant infrastructure, automated DNS setup and continuous verification, automatic DKIM rotation, and full delivery logs and webhooks so you can see every message's fate. Because each domain and subdomain is configured independently, isolating your transactional stream is the default, not a special project. If you send on behalf of many customers, Sub Accounts takes the same idea further, giving each customer its own fully isolated sending identity and reputation.
Credit where it is due: this best practice is laid out in detail by Andreas Lehr of We Manage in his guide on separating email reputation by subdomain, where AhaSend is listed among the EU transactional options worth a look. It pairs well with our own deep dive on SPF, DKIM, and DMARC for developers if you want the authentication mechanics in full.
Frequently asked questions
Should marketing email use its own subdomain? Yes. A dedicated marketing subdomain means your campaign reputation reflects your list quality and nothing else.
Should transactional email use its own subdomain? Yes, for most senders. Transactional mail has near-perfect engagement, and you do not want a marketing list or cold outreach averaging that reputation down. A dedicated subdomain like mail.yourdomain.com keeps it isolated.
Does a subdomain actually improve deliverability? Indirectly. The subdomain itself is not magic, but isolating your highest-engagement stream means its reputation is judged on its own merits instead of being dragged down by unrelated mail. That is what keeps password resets and receipts in the inbox.