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.

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.

The problem with one big domain

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.

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.

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.

The solution: separation by use-case

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.

My setup for statuswerk.eu looks like this:

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.

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.

Providers: it doesn't always have to be Postmark or SendGrid

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.

For transactional mail from the application (everything that runs on mail.statuswerk.eu):

For newsletter and broadcast on the self-hosted or semi-hosted end:

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.

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.

SPF, DKIM and DMARC per subdomain

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 side benefit you sidestep the infamous SPF 10-lookup limit, which you'd otherwise hit anyway with three or four senders on one domain.

Here is what mail.statuswerk.eu currently looks like — Scaleway TEM as the transactional sender:

The DMARC policy starts directly at p=quarantine — Statuswerk has only one authenticated sender (Scaleway TEM), which I control myself, and no forwarders or mailing lists that could break SPF/DKIM. That lets me skip the typical two-week p=none observation phase that I recommend further down in the monitoring section for more complex setups. After one or two weeks of clean aggregate reports (via rua=), this moves to p=reject. The same logic applies to news.statuswerk.eu with whichever newsletter service you pick. And the root domain gets a DMARC record that uses sp= to cover the behaviour for subdomains that aren't explicitly configured — important, so nobody can fire off a spam run from random.statuswerk.eu.

For deeper reading I'd recommend — besides issue 130 (German) — this excellent open-source guide on GitHub.

Don't forget warmup

A new subdomain also means a new, empty reputation. If you blast 10,000 transactional mails from mail.statuswerk.eu on day one, Gmail and Outlook interpret that as a suspicious volume spike. Result: greylisting, throttling, or straight to the spam folder.

Instead: ramp up gradually over four to six weeks, most engaged recipients first, increasing volume by 25 to 50 percent every two or three days. Keep an eye on bounce and engagement rates the whole time. If numbers slip, dial volume back down before continuing.

For low-volume setups (well below 50,000 mails per month per stream), a dedicated subdomain isn't necessarily a win — providers simply see too little signal to build a meaningful reputation. In that case, the root domain with a clean authentication setup is often enough.

Monitoring: see what's going on

A setup without monitoring is only half the deal. The following tools I use regularly — all free and easy to set up:

• Google Postmaster Tools and Microsoft SNDS — the official reputation dashboards of the two biggest mailbox providers, both free

• DMARC reports analysis — either through commercial services like Postmark DMARC, Dmarcian or Valimail (all with free tiers), or self-hosted with the open-source tool parsedmarc incl. an Elasticsearch/Kibana dashboard

• Mail-Tester and MXToolbox for point checks and blocklist monitoring

Important: start DMARC at p=none, look at the reports for four to six weeks, fold in every legitimate sender, then step up to p=quarantine and finally p=reject. Jumping straight to p=reject without reading the reports risks the total failure of individual mail streams.

What about the domains that don't send at all?

A blind spot I see all the time in practice: domains that should never send mail. The old domain from the last rebrand, the defensive registration of the typo variant, or simply the root domain in a setup where only subdomains send. Exactly these get abused for spoofing because nobody thinks to lock them down. Attackers know that — parked domains are the low-hanging fruit.

The M3AAWG Best Common Practices recommend a clear set of records for these non-sending domains:

Four DNS entries, five minutes of work — and a whole class of phishing attacks under your name is off the table.

Conclusion

Splitting by use-case at the subdomain level is no magic and no premium feature for enterprise setups. It's sound email hygiene that protects you from nasty surprises — like a misfiring newsletter campaign sinking your invoice mail into the void. Anyone running software where email plays a role should give themselves this hour of DNS work up front. Cleanup later is significantly more expensive.

If you need help setting things up or cleaning things up — talk to us, we do this regularly for our customers.