E-Mail-Reputation: Warum du deine Use-Cases auf Subdomains trennen solltest

E-Mail ist historisch gewachsen, und das merkt man bis heute. Was vor 40 Jahren als einfaches Übertragungsprotokoll gedacht war, ist mittlerweile ein fragiles Konstrukt aus Authentifizierungs-Layern und Reputations-Scores. Trotzdem sehe ich in der Praxis noch immer Unternehmen, die ihre komplette E-Mail-Kommunikation – Mitarbeiter-Mails, Newsletter, transaktionale Mails – über eine einzige Domain laufen lassen. Und sich dann wundern, warum die wichtigen Password-Reset-Mails plötzlich im Spam-Ordner landen.

In Ausgabe 130 des Newsletters hatte ich eine kleine Blog-Serie zu E-Mail-Validierung und Reputation in Aussicht gestellt – dieser Artikel ist die Einlösung. Als durchgängiges Beispiel nehme ich statuswerk.eu, ein aktuelles Laravel-Projekt, bei dem ich die Trennung pro Use-Case von Anfang an konsequent umgesetzt habe.

Das Problem mit der einen großen Domain

Mailbox-Provider wie Google, Microsoft und Apple bewerten jede sendende Domain mit einem Reputations-Score. Dieser Score basiert auf Engagement-Signalen: Werden deine Mails geöffnet? Beantwortet? Als Spam markiert? Bleiben sie ungelesen liegen? Aus diesen Signalen leiten ISPs ab, wo deine künftigen Mails landen – Inbox, Promotions-Tab oder Spam-Ordner.

Das Problem: Verschiedene Mail-Typen erzeugen völlig unterschiedliche Engagement-Profile. Eine Passwort-Reset-Mail wird zu fast 100 % geöffnet und meist angeklickt – traumhafte Werte. Ein Newsletter mit 25 % Öffnungsrate ist solide, aber im direkten Vergleich wirkt er "uninteressant". Und Mitarbeiter-Mails an externe Empfänger? Da ist alles möglich, von intensiven Konversationen bis hin zu Mails, die nie geöffnet werden.

Wenn du all das über @statuswerk.eu versendest, mittelt sich die Reputation. Im schlimmsten Fall ziehst du dir mit einer schlecht gepflegten Newsletter-Liste die Zustellung deiner Rechnungs- und Login-Mails kaputt. Spätestens wenn dann der Vertriebsmitarbeiter seine Cold-Outreach-Kampagne über vorname.nachname@statuswerk.eu startet, wird es eng.

Die Lösung: Trennung nach Use-Case

Die etablierte Praxis – nicht nur bei den großen ESPs wie Mailgun, Postmark oder SendGrid empfohlen, sondern explizit auch in den Bulk-Sender-Guidelines von Google und Yahoo – ist die Trennung über Subdomains. Jede Subdomain baut bei den Mailbox-Providern eine eigene Reputation auf. Was auf news.statuswerk.eu passiert, beeinflusst die Zustellung von mail.statuswerk.eu nur am Rand.

Mein Setup für statuswerk.eu sieht so aus:

Der Vorteil: Ich kann jeden dieser Streams an einen separaten Dienstleister anbinden. Geht einer offline oder verliert seine IP-Reputation, ist der Rest meiner Kommunikation davon nicht betroffen.

Ein wichtiger Hinweis dabei: Das nur namentliche Aufteilen vor dem @ (also noreply@statuswerk.eu vs. newsletter@statuswerk.eu) bringt gar nichts. Für ISPs ist das die gleiche Domain mit der gleichen Reputation. Es muss eine echte Subdomain im DNS sein.

Dienstleister: Es muss nicht immer Postmark oder SendGrid sein

Wer im Netz nach Tutorials für transaktionale Mails sucht, landet fast immer bei den üblichen US-Verdächtigen: Postmark, SendGrid, Mailgun, Resend, Amazon SES. Funktioniert alles, keine Frage – aber für Setups mit EU-Kundschaft oder DSGVO-Anspruch lohnt sich ein Blick auf die europäischen Alternativen, die in den letzten Jahren deutlich an Reife gewonnen haben.

Für transaktionale Mails aus der Anwendung (also alles, was auf mail.statuswerk.eu läuft):

Für Newsletter und Broadcast im selbst-gehosteten oder semi-gehosteten Bereich:

Wer den kompletten Versand selbst betreiben will, dem sei Postal als Open-Source-Alternative zu Sendgrid und Mailgun ans Herz gelegt – DKIM-Signaturen, Bounce-Management, Suppression-Listen, alles drin. Ich hatte es in Ausgabe 137 schon mal vorgestellt und nutze es vereinzelt produktiv. Wer selbst hosten möchte, den Aufwand aber scheut: Genau für solche Setups sind unsere Managed Cloud Server gedacht – wir übernehmen Betrieb und Reputation-Monitoring gerne.

Das Schöne an der Subdomain-Trennung: Wenn der gewählte Anbieter morgen weg ist oder die Preise verdreifacht, ziehst du den entsprechenden Stream zu einem anderen Provider um, ohne den Rest deiner Kommunikation zu gefährden.

SPF, DKIM und DMARC pro Subdomain

Damit die Trennung funktioniert, brauchst du für jede sendende Subdomain einen eigenen Satz an Authentifizierungs-Records. Das klingt nach viel Arbeit, ist aber Routine – und nebenbei umgehst du damit das berüchtigte SPF-10-Lookup-Limit, an das du sonst mit drei bis vier Sendern auf einer Domain ohnehin stößt.

So sieht das bei mail.statuswerk.eu aktuell aus – Scaleway TEM als Versanddienst:

Die DMARC-Policy startet hier direkt bei p=quarantine – Statuswerk hat nur einen authentifizierten Sender (Scaleway TEM), den ich selbst kontrolliere, und keine Forwarder oder Mailing-Listen, die SPF/DKIM brechen könnten. Damit fällt die typische zweiwöchige p=none-Beobachtungsphase weg, die ich weiter unten im Monitoring-Abschnitt für komplexere Setups empfehle. Nach ein bis zwei Wochen sauberer Aggregat-Reports (über rua=) wandert das auf p=reject. Für news.statuswerk.eu ginge das analog mit dem jeweiligen Newsletter-Dienst. Und die Root-Domain bekommt ein DMARC-Record, das mit sp= auch das Verhalten für nicht explizit konfigurierte Subdomains festlegt – wichtig, damit niemand auf random.statuswerk.eu einen Spam-Versand starten kann.

Wer tiefer einsteigen will, dem sei – neben Ausgabe 130 – dieser exzellente Open-Source-Guide auf GitHub empfohlen.

Warmup nicht vergessen

Ein neuer Sub-Domain-Eintrag bedeutet auch eine neue, leere Reputation. Wenn du auf mail.statuswerk.eu am ersten Tag direkt 10.000 transaktionale Mails verschickst, interpretieren Gmail und Outlook das als verdächtigen Volume-Spike. Die Folge: Greylisting, Throttling oder direkt der Spam-Ordner.

Stattdessen: schrittweise hochfahren über vier bis sechs Wochen, mit den engagiertesten Empfängern zuerst, alle zwei bis drei Tage das Volumen um 25 bis 50 Prozent steigern. Bounce- und Engagement-Raten dabei kontinuierlich im Blick behalten. Wenn die Werte kippen, das Volumen wieder zurückfahren, bevor du weitermachst.

Für niedrigvolumige Setups (deutlich unter 50.000 Mails pro Monat pro Stream) ist eine eigene Subdomain übrigens nicht zwingend ein Gewinn – die Provider sehen schlicht zu wenig Signal, um eine belastbare Reputation aufzubauen. In dem Fall reicht oft die Root-Domain mit sauberem Authentifizierungs-Setup.

Monitoring: Sehen, was los ist

Ein Setup ohne Monitoring ist nur die halbe Miete. Folgende Tools nutze ich regelmäßig – alle kostenlos und problemlos einrichtbar:

• Google Postmaster Tools und Microsoft SNDS – die offiziellen Reputation-Dashboards der beiden größten Mailbox-Provider, beide gratis

• DMARC-Reports auswerten – entweder über kommerzielle Dienste wie Postmark DMARC, Dmarcian oder Valimail (alle mit kostenlosen Tarifen), oder selbst gehostet mit dem Open-Source-Tool parsedmarc inkl. Elasticsearch/Kibana-Dashboard

• Mail-Tester und MXToolbox für punktuelle Checks und Blocklist-Monitoring

Wichtig: DMARC startest du mit p=none, schaust dir vier bis sechs Wochen lang die Reports an, ziehst alle legitimen Sender ein und wanderst dann sukzessive zu p=quarantine und schließlich p=reject. Wer direkt auf p=reject geht, ohne die Reports gelesen zu haben, riskiert den Totalausfall einzelner Mail-Streams.

Und die Domains, die gar nicht senden?

Ein blinder Fleck, den ich in der Praxis ständig sehe: Domains, über die nie Mails laufen sollen. Die alte Domain aus dem letzten Rebranding, die zur Verteidigung registrierte Tippfehler-Variante, oder schlicht die Root-Domain in einem Setup, bei dem nur Subdomains senden. Genau diese werden gerne für Spoofing missbraucht, weil niemand daran denkt, sie explizit dichtzumachen. Angreifer wissen das – geparkte Domains sind das tief hängende Obst.

Die M3AAWG Best Common Practices empfehlen für solche nicht-sendenden Domains einen klaren Satz an Records:

Vier DNS-Einträge, fünf Minuten Arbeit – und eine ganze Klasse von Phishing-Angriffen unter deinem Namen ist vom Tisch.

Fazit

Die Trennung nach Use-Case auf Subdomain-Ebene ist kein Hexenwerk und kein Premium-Feature für Enterprise-Setups. Es ist gesunde E-Mail-Hygiene, die dich vor unangenehmen Überraschungen schützt – etwa der Situation, dass eine schiefgelaufene Newsletter-Kampagne deine Rechnungs-Mails ins Nirwana befördert. Wer ernsthaft Software betreibt, in der Mails eine Rolle spielen, sollte sich diese Stunde DNS-Arbeit am Anfang gönnen. Später ist die Aufräumarbeit deutlich teurer.

Falls du beim Aufsetzen oder Aufräumen Hilfe brauchst – sprich uns an, wir machen das regelmäßig für unsere Kunden.