Email Reputation: Separate Use-Cases on Subdomains | We Manage
07139 / 9363342
Email us
de
en
*:first-child]:mt-0">
28. May 2026 · by Andreas Lehr
Email Reputation: Why You Should Separate Use-Cases Across Subdomains
Email is a historically grown beast, and you can feel it to this day. What was once a simple transfer protocol 40 years ago has become a fragile construct of authentication layers and reputation scores. Yet in practice I still see companies running their entire email communication — employee mail, newsletters, transactional mail — over a single domain. And then wondering why their important password-reset mails suddenly land in spam.<br>In issue 130 of my newsletter (German) I promised a small blog series on email validation and reputation — this article delivers on that. I use statuswerk.eu as a running example, a current Laravel project where I implemented the per-use-case separation consistently from day one.<br>The problem with one big domain<br>Mailbox providers like Google, Microsoft and Apple score every sending domain on reputation. That score is based on engagement signals: are your mails opened? Replied to? Marked as spam? Left unread? From those signals, ISPs decide where your future mail lands — inbox, promotions tab, or spam folder.<br>The problem: different mail types produce completely different engagement profiles. A password-reset mail is opened nearly 100% of the time and usually clicked — dream metrics. A newsletter with a 25% open rate is solid, but compared head-to-head it looks "uninteresting". And employee mail to external recipients? Anything goes, from intense conversations down to mail nobody ever opens.<br>If you send all of that over @statuswerk.eu, the reputation averages out. In the worst case, a poorly maintained newsletter list wrecks the delivery of your invoice and login mails. And the moment your sales rep starts a cold-outreach campaign from firstname.lastname@statuswerk.eu, things get tight.<br>The solution: separation by use-case<br>The established practice — recommended not only by the big ESPs like Mailgun, Postmark or SendGrid, but explicitly part of Google's and Yahoo's bulk-sender guidelines — is separation via subdomains. Each subdomain builds its own reputation with mailbox providers. What happens on news.statuswerk.eu only marginally affects the delivery of mail.statuswerk.eu.<br>My setup for statuswerk.eu looks like this:<br>Subdomain<br>Use-case<br>statuswerk.eu (root)<br>employee mail via Google Workspace<br>mail.statuswerk.eu<br>transactional mail from the Laravel app (welcome, password reset, invoices)<br>news.statuswerk.eu<br>newsletter (if one ever joins the show)<br>The upside: I can wire each of these streams to a separate provider. If one goes down or loses its IP reputation, the rest of my communication is unaffected.<br>One important caveat: splitting only by name in front of the @ (so noreply@statuswerk.eu vs. newsletter@statuswerk.eu) gets you absolutely nothing . To ISPs, that's the same domain with the same reputation. It has to be a real DNS subdomain.<br>Providers: it doesn't always have to be Postmark or SendGrid<br>Search online for tutorials on transactional mail and you'll almost always land at the usual US suspects: Postmark, SendGrid, Mailgun, Resend, Amazon SES. They all work, no question — but for setups with EU customers or GDPR requirements, it's worth a look at the European alternatives that have matured significantly in recent years.<br>For transactional mail from the application (everything that runs on mail.statuswerk.eu):<br>Provider<br>Location<br>Highlight<br>AhaSend<br>Netherlands<br>Transactional-only, generous free tier, aggressive pricing<br>Lettermint<br>Netherlands<br>Laravel & Node.js SDKs, explicit EU-only data residency<br>Scaleway TEM<br>France<br>Handy when you're already in the Scaleway stack<br>For newsletter and broadcast on the self-hosted or semi-hosted end:<br>Provider<br>Model<br>Highlight<br>Mailcoach<br>Self-host or SaaS (Belgium, by Spatie)<br>Flexible between on-premise and hosted<br>Sendy<br>Self-hosted PHP, AWS SES backend<br>The PHP classic; powers allesnurgecloud.com for years now<br>Listmonk<br>Open source, written in Go<br>Native PostgreSQL backend<br>If you want to run the whole sending stack yourself, I'll recommend Postal as an open-source alternative to Sendgrid and Mailgun — DKIM signatures, bounce handling, suppression lists, it's all there. I introduced it in issue 137 (German) and use it productively in a few places. If you want to self-host but don't want the operational overhead: that's exactly what our Managed Cloud Servers are made for — we'll happily take over operations and reputation monitoring.<br>The nice thing about subdomain separation: if your chosen provider disappears tomorrow or triples its pricing, you move that stream to a different provider without putting the rest of your communication at risk.<br>SPF, DKIM and DMARC per subdomain<br>For the separation to actually work, each sending subdomain needs its own set of authentication records. That sounds like a lot of work but is just routine — and as a...