Sende von beiden. Behalte die Adresse, die deine Empfänger sehen, auf deiner Root-Domain und verschiebe die technische Sendeidentität, also den Return-Path und die DKIM-Signaturdomain, auf eine Subdomain, die für genau eine Art von Mail reserviert ist.
Das liest sich nur deshalb wie ein Entweder-oder, weil „von welcher Domain sende ich“ in Wahrheit vier getrennte Entscheidungen sind und fast jede Anleitung eine davon verschiebt, ohne zu sagen welche. Sobald du die vier trennst, löst sich der größte Teil der Uneinigkeit in den Threads auf, und mit ihm die Nervosität: wenn du weniger als rund 5.000 Marketing-Nachrichten pro Monat sendest oder dein Marketing-Volumen deine übrige Mail nicht dominiert, lautet die richtige Antwort: Finger weg von deinem Setup und verbring den Nachmittag stattdessen mit deiner Liste.
Hier ist die ganze Entscheidung, noch vor der Begründung dahinter.
| Deine Situation | Was zu tun ist |
|---|---|
| Du sendest noch nicht, oder weniger als rund 5.000 Marketing-Nachrichten pro Monat | Bleib auf der Root-Domain. Veröffentliche SPF, DKIM und DMARC ordentlich und halte die Liste sauber. Ein kleines Signal in zwei Teile zu schneiden verschafft dir zwei zu wenig beobachtete Identitäten statt einer warmen. |
| Dein Marketing-Volumen ist ein Mehrfaches deiner Firmen- und Transaktionsmail zusammen | Trenne. Marketing-Umschlag und DKIM auf news.yourbrand.com, Transaktionsmail auf txn.yourbrand.com, Firmenmail bleibt auf der Root, und jedes sichtbare From: bleibt auf der Root. |
| Du sendest schon von der Root ohne Probleme und mit einer Spam-Rate in den Postmaster Tools unter 0,10 % | Migriere nicht. Du gäbst eine warme Sendeidentität auf, um einen Vorteil zu kaufen, den du derzeit nicht messen kannst. Nimm die Subdomain beim nächsten Plattformwechsel dazu, wenn der Ramp-up sowieso ansteht. |
| Du sendest schon von der Root und deine persönlichen Antworten landen im Spam | Trenne, und sei dir klar, dass die Trennung allein nicht die Lösung ist. Das Verhalten, das den Schaden verursacht hat, reist mit. |
| Deine Plattform kann auf einer Subdomain kein Alignment herstellen | Bleib auf der Root, oder wechsle vorher den Plattform-Tarif. Eine Subdomain ohne Alignment ist schlechter als eine Root-Domain mit. |
| Cold Outreach | Eine separate Domain, keine Subdomain. Hier kippt die Antwort tatsächlich, und es kostet dich etwas. |
Eine Subdomain ist news.yourbrand.com. Eine ähnlich aussehende Domain ist yourbrand-news.com
Eine Subdomain liegt unterhalb einer Domain, die du schon besitzt, niemand außerhalb deiner Organisation kann also eine anlegen, während eine ähnlich aussehende oder „Cousin“-Domain eine separate Registrierung ist, die Empfänger und Filter dir auf keine Weise zuordnen können. Die Hälfte der widersprüchlichen Ratschläge zu diesem Thema kommt von Leuten, die das Wort „Domain“ für beides verwenden.
Deine Organisations-Domain ist der registrierbare Name, für den du zahlst, yourbrand.com. Alles links davon ist eine Subdomain, die du mit einem DNS-Eintrag und ohne zusätzlichen Kauf anlegst: news.yourbrand.com, txn.yourbrand.com, links.yourbrand.com. Eine Cousin-Domain wie yourbrand-news.com oder yourbrandmail.com ist eine zweite Registrierung ohne kryptografische oder administrative Beziehung zur ersten.
Diese Unterscheidung ist das stärkste Argument für Subdomains, und sie hat nichts mit Reputationsbewertung zu tun. Eine Subdomain lässt sich von außen nicht fälschen. M3AAWG rät genau aus diesem Grund von Cousin-Domains ab: Für Empfänger und für Anti-Abuse-Systeme sehen sie wie Phishing-Kampagnen aus, weil Angreifer genau das registrieren. Die drei Einträge, die ein Sendename braucht, sind in beiden Fällen dieselben, und die E-Mail-Authentifizierung funktioniert auf einer Subdomain identisch.
Ein Mythos, der vor der Mechanik weg muss. Den Mailbox-Namen vor dem @ zu ändern, von info@ zu hello@, ist keine Subdomain und trennt nichts. Jeder Reputations-Identifier, den Mailbox-Provider veröffentlichen, ist eine Domain oder eine IP-Adresse.
Eine Nachricht trägt vier Domains, und nur über eine davon wird gestritten
Jede Nachricht, die du sendest, legt vier unabhängig veränderbare Domains offen: die sichtbare From:-Domain, die Return-Path-Domain des Umschlags, gegen die SPF tatsächlich geprüft wird, die DKIM-Signaturdomain im d=-Tag und den Hostnamen in deinen getrackten Links. „Nutze eine Subdomain“ bedeutet mindestens vier verschiedene Dinge, je nachdem welche davon sich bewegt.
Dieses Modell der vier Oberflächen stammt von Laura Atkins bei Word to the Wise, und es löst den größten Teil der Debatte schon von selbst auf.
| Domain-Slot | Wo sie sitzt | Für den Empfänger sichtbar | Wofür sie verwendet wird |
|---|---|---|---|
Sichtbare From:-Domain | der From:-Header | Ja, das ist die Adresse im Posteingang | Das Alignment-Ziel von DMARC, und was Empfänger und Consumer-Filter lesen |
| Return-Path des Umschlags | SMTP MAIL FROM, angezeigt als Return-Path: | Nur wenn sie die Details aufklappen | SPF wird ausschließlich hiergegen ausgewertet, dazu das Bounce-Routing |
| DKIM-Signaturdomain | d= im DKIM-Signature-Header | Nein | Die Identität, die Verantwortung für die Nachricht übernimmt, und worauf Googles Domain-Reputationsbericht verweist |
| Link- und Tracking-Host | Hostnamen im HTML-Body | In der Statusleiste, beim Überfahren mit der Maus | Wird von Domain-Blacklists bei der Inhaltsprüfung aus dem Body ausgelesen |
Drei dieser vier können eine Subdomain sein, während das sichtbare From: auf deiner Root-Domain bleibt. Das ist kein Kompromiss, sondern genau das, was die Standards vorsehen. M3AAWGs eigenes durchgerechnetes Beispiel kombiniert ein From: von service@mybrand.com mit einem Return-Path von bounce@bounce.mybrand.com, und es besteht DMARC, weil relaxed Alignment nur verlangt, dass die Organisations-Domains übereinstimmen.
Das Audit unten nenne ich den Unspam Vier-Domain-Header-Check: Lies vier Werte aus einer einzigen zugestellten Nachricht, und du weißt genau, was dein aktuelles Setup isoliert. Mit der kostenlosen E-Mail-Header-Analyse dauert das etwa eine Minute.
| Lies das | So sieht eine gesunde Trennung aus | Wenn es stattdessen so aussieht |
|---|---|---|
From: | news@yourbrand.com | Die Domain der Plattform selbst, du sendest also überhaupt nicht als du selbst |
Return-Path: | ...@news.yourbrand.com | ...@sendgrid.net, ...@mcsv.net, ...@hubspotemail.net: SPF kann kein Alignment herstellen, und DMARC besteht allein über DKIM |
DKIM-Signature: d= | news.yourbrand.com oder yourbrand.com | Die Domain der Plattform, die Reputation, die du aufbaust, gehört also deinem Anbieter |
| Host der getrackten Links | links.yourbrand.com | Ein gemeinsam genutzter Tracking-Host des Anbieters, du teilst dir die Blacklist-Angriffsfläche also mit allen anderen Kunden darauf |
Diese letzte Zeile ist eine eigene Entscheidung mit eigenen Folgen, behandelt in Link-Tracking und Zustellbarkeit.
Was eine Sende-Subdomain isoliert, und was ohnehin übergreift
Eine Sende-Subdomain verschafft dir getrennte Authentifizierung, getrenntes Reporting und einen eigenen Reputations-Identifier, den Empfänger selbst als unabhängig bewertbar dokumentieren. Was sie dir nicht verschafft, ist eine Firewall, und ein reiner Tisch ist sie auch nicht.
Was wirklich getrennt wird
SPF wird nicht vererbt. Jeder SPF-Eintrag sitzt auf genau dem Namen, für den er gilt, news.yourbrand.com wird also von seinem eigenen Eintrag regiert oder von gar keinem.
DKIM ist, was der Signierende wählt. Der Schlüssel wird bei <selector>._domainkey.<the d= domain> abgerufen, die signierende Identität ist also eine bewusste Konfigurationsentscheidung und keine Eigenschaft der Nachricht.
Reporting läuft pro authentifizierter Domain. Googles Domain-Reputationsbericht deckt nur genau die Domain ab, die für die DKIM- oder SPF-Authentifizierung verwendet wurde, und Subdomains lassen sich als eigenständige Properties in die Postmaster Tools aufnehmen. Yahoo sagt unmissverständlich, dass jede IP und jede DKIM-Domain eine Reputation hat, und seine Best Practices fordern Absender auf, Streams nach Funktion zu trennen.
Die Standards empfehlen es namentlich. RFC 5863 rät zu unterschiedlichen d=-Subdomains für unterschiedliche Traffic-Streams und nutzt marketing.example.com und transaction.example.com als Beispiel, gerade damit Empfänger differenzierte Bewertungen vornehmen können. Microsoft geht weiter und empfiehlt eine Subdomain für Massen-E-Mails, mit offen ausgesprochener Begründung: Du willst nicht, dass Probleme mit der Mail dieser Dienste die Reputation der Mail beeinträchtigen, die Nutzer in deiner Hauptdomain senden. Das ist die stärkste von einem Provider dokumentierte Empfehlung, die es gibt, und es lohnt sich zu wissen, dass Googles Absenderrichtlinien das Wort „Subdomain“ überhaupt nicht verwenden.
Was die Grenze ohnehin überschreitet
Sechs Mechanismen ignorieren die Subdomain-Grenze vollständig, und zusammen erklären sie jeden Fall, in dem ein Absender die Trennung korrekt gemacht hat und trotzdem Schaden nahm.
| Mechanismus | Richtung | Was das bedeutet |
|---|---|---|
| Gemeinsam genutzte Sende-IPs | In beide Richtungen | Zwei Subdomains in einem IP-Pool sind bei keinem Empfänger getrennt, der hauptsächlich über die IP filtert |
| Gemeinsam genutzter Click-Tracking-Host | In beide Richtungen | Eine tadellose From:-Domain kann trotzdem über den Link-Host gefiltert werden, weil Blacklists Domains aus dem Body auslesen |
| Domain-Blacklist-Aufnahme | Von oben nach unten | Eine Aufnahme der registrierbaren Domain gibt für jede Subdomain darunter „gelistet“ zurück |
| Googles Compliance-Status | Von unten nach oben | Compliance wird nur für primäre Domains gemeldet, anhand der Daten ihrer Subdomains |
| Googles Schwelle für Massenversender | Von unten nach oben | Die 5.000 Nachrichten pro Tag werden über die gesamte primäre Domain gezählt, und die Einordnung verfällt nie |
Ein From:, das auf der Root geblieben ist | Von unten nach oben | Wenn sich nur der Umschlag bewegt hat, ist die Domain, die Empfänger sehen und gegen die sie sich beschweren, weiterhin deine Root |
Googles eigene Rechnung macht die Schwelle für Massenversender konkret: 2.500 Nachrichten pro Tag von deiner Root plus 2.500 von einer Subdomain machen dich zum Massenversender, dauerhaft. Streams zu trennen trennt diese Zählung nicht. Der vollständige Pflichtenkatalog, der daraus folgt, steht in den Absenderanforderungen von Gmail und Yahoo.
Der Schutz ist asymmetrisch, und er läuft in die nützliche Richtung
Eine Aufnahme von news.yourbrand.com listet yourbrand.com nicht automatisch mit, während eine Aufnahme von yourbrand.com für jede Subdomain darunter „gelistet“ zurückgibt, auch für die, die deine Belege trägt. Spamhaus listet auf Ebene der Hauptdomain, und die Wildcard wirkt nur nach unten.
Für die meisten Absender läuft diese Asymmetrie in die richtige Richtung, denn der Stream, der sich am ehesten eine Aufnahme einbringt, ist der Massen-Stream, und die Mail, die du am wenigsten verlieren willst, ist alles andere. Sie erklärt außerdem, warum „eine Subdomain schützt meine Hauptdomain“ und „Reputationstrennung über Subdomains gibt es nicht“ beide vertretbare Positionen sind: Die erste redet über die Richtung, die funktioniert, die zweite über die, die es nicht tut.
Die Blacklist selbst ist einer von mehreren Mechanismen, und die Domain-Checks, die sie sichtbar machen, laufen auf Abruf und nicht dauerhaft. Von den Domains, die wir testen, tauchen 6 % auf einer IP-Blacklist auf, und einer IP-Aufnahme ist es egal, von welcher deiner Domains die Nachricht kam.
Was niemand dokumentiert, ist genau der Teil, den Absender am liebsten wüssten: wie stark die Reputation einer übergeordneten Domain in der Filterentscheidung selbst auf die einer untergeordneten wirkt. RFC 5863 räumt den Punkt ein, statt ihn zu klären, und merkt an, dass ein Empfänger nur irgendeinen rechten Teil des Identifiers verwenden könnte und dass der Signierende nicht wissen kann, welchen. Behandle jede selbstsichere Zahl dazu als Erfindung.
Was mit deiner Mitarbeitermail passiert, wenn eine Kampagne sauer wird
Alltägliche Mail auf deiner Root-Domain kann wegen eines Marketing-Versands wirklich anfangen, im Spam zu landen, und die Mechanismen sind aufzählbar und nicht mysteriös. Das ist der Fehlerfall, der die ganze Frage überhaupt lohnend macht, und der, den konkurrierende Anleitungen überspringen.
Es gibt vier Wege. Gemeinsam genutzte Sende-IPs, die beiden Streams waren also nie auf der Ebene getrennt, auf die es ankam. Ein Compliance-Verlauf, der auf deiner primären Domain geführt und mit Subdomain-Daten gefüttert wird. Eine Blacklist-Aufnahme, die auf der registrierbaren Domain gelandet ist und per Wildcard nach unten durchgeschlagen hat. Und ein sichtbares From:, das die Root nie verlassen hat, mit weitem Abstand der häufigste der vier.
Das Muster, das Absender berichten, ist immer dasselbe: Ein Benachrichtigungs-Stream mit geringem Volumen sammelt eine Handvoll Beschwerden ein, was bei einem kleinen Nenner ein großer Prozentsatz ist, und die Firmenantworten sitzen danach wochenlang im Spam. Der Alias „Send As“ in Google Workspace macht es schlimmer, weil er Mitarbeitermail und Kampagnenmail auf dieselbe sichtbare Identität legt, ein Muster, das der Mailchimp-Leitfaden zur Zustellbarkeit behandelt.
Die drei Streams, und woher jeder senden sollte
Trenne Firmenmail, Marketing und Transaktionsmail auf drei Sendeidentitäten, halte alle drei sichtbaren From:-Adressen auf deiner Root-Domain, und behandle Cold Outreach als vierten Fall mit einer anderen Antwort.
| Stream | Sichtbares From: | Return-Path | DKIM d= | Warum |
|---|---|---|---|---|
| Mitarbeiter- und persönliche Mail | you@yourbrand.com | Root-Domain | yourbrand.com | Verschiebe das nie. Es ist die Mail, deren erneutes Aufwärmen du dir nicht leisten kannst. |
| Marketing und Newsletter | news@yourbrand.com | bounce@news.yourbrand.com | news.yourbrand.com | Bekommt Alignment unter relaxed DMARC, weil die Organisations-Domains übereinstimmen |
| Transaktionsmail | alerts@yourbrand.com | bounce@txn.yourbrand.com | txn.yourbrand.com | Damit eine schlechte Kampagne nicht die Passwort-Resets mit sich reißt |
| Click-Tracking | nicht zutreffend | nicht zutreffend | nicht zutreffend | links.yourbrand.com, eine andere Subdomain als die zum Senden |
| Cold Outreach | separate Domain | separate Domain | separate Domain | Andere Antwort, andere Gründe, und ein echter Kompromiss |
Belege und Passwort-Resets vom Kampagnenvolumen fernzuhalten ist die Trennung, die sich am zuverlässigsten auszahlt, und sie zählt am meisten für SaaS-Absender, bei denen ein Werbeversand und ein Login-Code standardmäßig durch dasselbe Rohr laufen.
Es gibt einen Haken, der genannt werden muss, weil er den üblichen Ratschlag umdreht. Die Heuristik der Praktiker ist ein Verhältnis und kein absoluter Wert: Isolation fängt an, sich zu lohnen, wenn das Marketing-Volumen ein Mehrfaches deines Transaktionsvolumens beträgt. Das heißt, dass Isolation bei geringem Volumen weniger nützt, also genau das Gegenteil von dem, was Einsteigern üblicherweise erzählt wird.
Bei Cold Outreach wechselt die Antwort zu einer separaten Domain
Für Cold Outreach kippt die Antwort zu einer vollständig separaten registrierten Domain, und der Grund ist mechanisch: Eine eigene Registrierung durchtrennt die Verbindung der Organisations-Domain, auf die DMARC-Alignment, die Blacklist-Aufnahme auf Ebene der Hauptdomain und Googles Nachrichtenzählung pro primärer Domain alle aufsetzen. Eine Subdomain lässt jede einzelne dieser Verbindungen intakt, und das ist der Sinn einer Subdomain und das Problem für kalte Mail.
Dieser Ratschlag kommt mit einem Preis, der selten daneben genannt wird. M3AAWG rät von genau diesem Muster ab, weil eine Domain, die nicht nachweisbar mit deiner Marke verbunden ist, für Empfänger und für Anti-Abuse-Systeme wie Phishing wirkt. Die separate Domain ist also ein Kompromiss, den du wählst, und keine Best Practice, der du folgst. Wenn du kalt sendest, deckt das Playbook für Cold Outreach den Rest des Setups ab.
Wie viele Subdomains sind zu viele
Jede Sende-Subdomain braucht genug konstantes Volumen, um eine eigene Reputation aufzubauen, die Obergrenze des Aufteilens setzt also dein Volumen und nicht die Zahl der Streams, die du benennen kannst. M3AAWG formuliert die Einschränkung direkt: Jedes Segment braucht ausreichenden und relativ konstanten Traffic, um eine eigene Reputation aufzubauen.
Zu wenig Aufteilen scheitert auf eine Weise: Eine schlechte Kampagne nimmt deine Passwort-Resets mit. Zu viel Aufteilen scheitert auf eine schlimmere. Spamhaus beschreibt viele sich schnell ändernde Domains und IP-Adressen als das Snowshoe-Muster, hält fest, dass seriöse Massenversender weit weniger Domains nutzen als Snowshoer, und behandelt Domains, die sich wie Snowshoer verhalten, entsprechend. RFC 5863 macht denselben Punkt von der anderen Seite und warnt, dass eine zu feine Granularität verwandte Streams daran hindert, von einer aggregierten Reputation zu profitieren.
Zwei oder drei Sende-Subdomains, benannt nach dem Traffic, den sie tragen, sind der Punkt, an dem fast alle aufhören sollten.
Was du auf der Subdomain veröffentlichen musst, Eintrag für Eintrag
SPF und DKIM werden nicht von der übergeordneten Domain vererbt und DMARC schon, eine neue Sende-Subdomain braucht also einen eigenen SPF-Eintrag und meistens einen eigenen DKIM-Schlüssel, während der DMARC-Eintrag der übergeordneten Domain sie bereits abdeckt.
SPF gehört dorthin, wo die Bounces hingehen, nicht dorthin, wo das From steht
SPF wird gegen die MAIL-FROM-Domain des Umschlags ausgewertet, nie gegen den From:-Header, veröffentliche den Eintrag also auf dem Namen, an den deine Bounces zurückkommen. Wenn deine Plattform auf bounce.yourbrand.com bounct, ist das der Name, der v=spf1 braucht, und die Subdomain in deinem From:-Header braucht möglicherweise überhaupt keinen SPF-Eintrag.
Eine Subdomain ohne SPF-Eintrag schlägt bei SPF nicht fehl, sie gibt none zurück, ein anderes Ergebnis mit derselben praktischen Wirkung: DKIM muss das Alignment allein tragen. In unseren Benchmark-Daten veröffentlichen 93 % einen gültigen SPF-Eintrag, und es sind die 7 % ohne einen solchen, die hier hängen bleiben, denn eine brandneue Sende-Subdomain gehört in dem Moment zu dieser Gruppe, in dem du sie anlegst.
Hier versteckt sich ein echter technischer Gewinn. Jede Domain bekommt ihr eigenes unabhängiges Budget von zehn Lookups, das include einer Marketing-Plattform aus deinem Root-Eintrag zu nehmen entlastet also die Root, und ein permerror auf der einen berührt die andere nicht. Wenn dein Root-Eintrag am Limit kratzt, ist das der saubersten Ausweg. Die Details stehen im SPF-Leitfaden, und der kostenlose SPF-Check zählt die Lookups auf dem Namen, auf den du ihn richtest.
DKIM zählt auf der Subdomain nur, wenn du als die Subdomain signierst
Der DKIM-Schlüssel wird bei <selector>._domainkey.<the d= domain> abgerufen, und d= ist, was auch immer in der signierenden Plattform konfiguriert ist, eine Subdomain braucht also keinen eigenen Schlüssel, wenn du bewusst mit der Root signierst. Das ist der Schritt, den Leute überspringen: Nur die sichtbare From:-Domain zu ändern reicht nicht, denn die Mail muss von der Subdomain DKIM-signiert sein, damit überhaupt eine Trennung existiert.
Von den Domains, die wir prüfen, signieren 90 % ihre Mail mit einem funktionierenden DKIM-Schlüssel und 10 % ohne einen. Bestätige mit dem DKIM-Check, als welcher Name deine signiert, und lies den DKIM-Leitfaden, wenn du zum ersten Mal einen Selector wählst.
DMARC deckt die Subdomain schon ab
Ein DMARC-Eintrag auf yourbrand.com regiert schon jetzt jede Subdomain ohne eigenen Eintrag und wendet dabei die sp=-Policy an, wenn dieses Tag vorhanden ist, und die p=-Policy, wenn nicht. Alignment ist standardmäßig relaxed, und deshalb besteht From: news@yourbrand.com, signiert von d=news.yourbrand.com, ohne jede besondere Konfiguration. Der strikte Modus (adkim=s, aspf=s) ist das, was du selbst aktivierst, und er macht deine Subdomain-Wahl zu einer harten Bedingung und zu einem verbreiteten selbst verschuldeten Fehlschlag, den der Leitfaden zu DMARC-Fehlern Fall für Fall durchgeht.
Im sp=-Tag wohnen zwei Fallen, und beide sind kontraintuitiv. sp= wird auf jedem Eintrag ignoriert, der auf einer Subdomain veröffentlicht ist, weil die Policy-Ermittlung diesen Eintrag zuerst findet und aufhört zu suchen. Und einen DMARC-Eintrag auf der Subdomain zu veröffentlichen ersetzt den Eintrag der übergeordneten Domain für diesen Namen, Reporting-Adressen inklusive, rua= weglassen macht dich also genau auf dem Stream blind, den du beobachten wolltest. Der DMARC-Leitfaden behandelt die Tags vollständig, und der kostenlose DMARC-Check zeigt, welcher Eintrag für einen gegebenen Namen tatsächlich auflöst.
Der nützliche Schritt, während eine neue Sende-Subdomain aufwärmt, ist p=reject auf der Root und daneben sp=none, was dir die Durchsetzung erhält, während der neue Stream Tritt findet. Ein Preis, den man vorher kennen sollte: sp=none an irgendeiner Stelle der Kette stoppt die BIMI-Verarbeitung, ein Markenlogo wird also nicht angezeigt, solange dieser Eintrag lebt. Von den Domains, die wir testen, veröffentlichen 50 % inzwischen eine DMARC-Policy und 50 % haben weiterhin gar keine, für die Hälfte aller Absender hat diese Frage also noch nicht begonnen.
Eine Anmerkung zu Standards, die für alles zählt, was du zu diesem Thema liest. RFC 9989 hat RFC 7489 im Mai 2026 ersetzt, die Public Suffix List durch einen DNS-Baumdurchlauf getauscht, das pct=-Tag entfernt und p= optional gemacht. Die Übernahme auf Empfängerseite ist eine andere Sache: Microsofts DMARC-Dokumentation wurde im Juli 2026 aktualisiert und zitiert weiterhin RFC 7489 und dokumentiert weiterhin pct=. Geh in der Praxis vom älteren Organisations-Domain-Modell aus, und greife nicht zum neuen psd=n-Tag als Isolationswerkzeug, denn es bricht relaxed Alignment gegen das d= deiner übergeordneten Domain, und niemand hat bestätigt, dass Empfänger es beachten.
Antworten, MX und der Bounce, den niemand sieht
Kein Standard verlangt einen MX-Eintrag auf einer Sende-Subdomain, und genau das ist das Problem. Ohne MX-Eintrag wird eine Antwort an news.yourbrand.com nicht laut abgelehnt; der Mailserver des Absenders versucht die Zustellung an das, worauf der A-Eintrag dieses Namens zeigt, üblicherweise ein Webserver, der nicht auf Mail lauscht, die Antwort sitzt also in einer Retry-Queue und bounct Tage später zu der Person zurück, die sie geschrieben hat, oder wird gleich verschluckt, falls dort etwas sie doch annimmt. In beiden Fällen erreicht sie dich nie.
M3AAWGs Vorgabe ist hier unmissverständlich: Jede Domain, die in Return-Path, From:, Sender oder Reply-To verwendet wird, sollte einen funktionierenden MX-Eintrag haben, und abuse@ und postmaster@ müssen existieren, gelesen werden und nie bouncen. Das ist der praktische Grund, aus dem Klaviyo seinen Kunden sagt, die From:-Adresse auf der Root-Domain zu behalten. Richte den MX-Record-Check auf jede Sende-Subdomain, die du anlegst, und bestätige, dass Mail irgendwo real auflöst.
Braucht eine neue Subdomain ein eigenes Warm-up
Ja, und der Grund ist nicht, dass Empfänger die Subdomain noch nie gesehen haben. Es ist, dass du die Kombination von Signalen geändert hast, die sie bereits bewertet haben, und eine neue Sendedomain gepaart mit deinen bestehenden IP-Adressen ist eine neue Kombination. Iterable fasst es als Kombination, und das ist genau richtig.
Plane zwei bis vier Wochen für eine Subdomain, die zu einem bereits warmen Programm dazukommt, im Einklang mit dem Ramp-up in der Checkliste zur Zustellbarkeit, und näher an den sechs Wochen, die M3AAWG als Durchschnitt nennt, wenn auch Volumen oder Zielgruppe neu sind. M3AAWG behandelt einen Domainwechsel in beide Richtungen als Anlass für einen frischen Ramp-up.
Die schärfste operative Falle hat nichts mit der Dauer zu tun. Manche Plattformen drosseln das Warm-up pro IP statt pro Domain, eine neue Subdomain auf einer schon warmen IP bekommt also gar keinen Ramp, wenn du keinen bewusst baust. Prüfe, was deine tut, bevor du ihren Voreinstellungen traust.
Sei skeptisch gegenüber jeder konkreten Leiter, die dir gegeben wird, unserer eingeschlossen. Kein veröffentlichter Datensatz und keine Provider-Aussage stützt einen bestimmten Tagesvolumen-Plan für eine neue Sendedomain, und die unvereinbaren Zahlen im Umlauf, von zehn pro Tag bis tausend pro Tag in der ersten Woche, sind der Beweis, dass niemand messt. Die Variablen, die tatsächlich entscheiden, sind dein angestrebtes Dauervolumen und wie engagiert deine Liste ist. Der Leitfaden zum Domain-Warm-up behandelt die Mechanik.
Von der Root migrieren: der Preis, den niemand ausweist
Ein etabliertes Root-Domain-Programm auf eine Subdomain zu verschieben kostet dich einen frischen Ramp auf einer neuen Kombination, und es verschafft dir nichts, wenn das Sendeverhalten, das dein Problem verursacht hat, mitkommt.
Drei Dinge vor dem Start zu prüfen. Eine unbekannte Reputation startet laut Spamhaus näher an schlecht als an neutral, der neue Name ist also kein Neuanfang. Eine neue Subdomain einer aktuell gelisteten Domain ist bereits vor ihrem ersten Versand gelistet, prüfe die Root also zuerst mit dem Domain-Blacklist-Check. Und bestätige, dass die Subdomain, die du gewählt hast, keine bestehenden A-, CNAME- oder MX-Einträge aus irgendeinem früheren Projekt trägt.
Deine Plattform kann das auch für dich entscheiden, und zwei Fälle kommen immer wieder vor. Auf HubSpots gemeinsam genutzten IPs bleibt der Return-Path auf hubspotemail.net, SPF kann auf deiner Subdomain also kein Alignment herstellen; nur Kunden mit dedizierter IP können eine eigene Umschlag-Rücksendeadresse konfigurieren, was der HubSpot-Leitfaden zur Zustellbarkeit behandelt. Amazon SES braucht eine eigene MAIL-FROM-Subdomain mit genau einem MX-Eintrag und einem eigenen SPF-Eintrag, bevor der Return-Path überhaupt deiner ist, ausführlich im Amazon-SES-Leitfaden. Ein falsch konfiguriertes eigenes MAIL FROM ist schlechter als ein funktionierendes Standard-Setup.
Wenn du kannst, mach die Migration während eines Plattformwechsels, wenn der Ramp sowieso ansteht und du ihn nur einmal bezahlst. Und um den Fall zu wiederholen, in dem die meisten Leser dieses Abschnitts tatsächlich sind: Wenn du heute von deiner Root-Domain sendest, deine Spam-Rate unter 0,10 % liegt und nichts im Spam landet, migriere nicht.
Was dein ESP mit der Subdomain tatsächlich macht
Die meisten Subdomain-Anforderungen von Plattformen existieren, weil ihr Onboarding CNAME-Delegation oder einen anbieterkontrollierten Return-Path nutzt, und nicht, weil irgendwer einen Zustellbarkeitsgewinn gemessen hätte, und zwei der größten geben direkt entgegengesetzte Anweisungen dazu, wohin das sichtbare From: gehört.
| Plattform | Wohin das sichtbare From: gehört | Was die Subdomain tatsächlich trägt |
|---|---|---|
| Klaviyo | Root-Domain, und sie sagt es dir, weil dich Antworten sonst nicht mehr erreichen | Return-Path und DKIM auf einer send.-Subdomain, plus ein separater Click-Host |
| HubSpot | Muss zur verbundenen Subdomain passen | DKIM und die verbundene Sendedomain, wobei der Return-Path auf gemeinsam genutzten IPs auf hubspotemail.net bleibt |
| Mailchimp | Keine Position in eine der beiden Richtungen | Der Return-Path ist immer eine Mailchimp-Domain, DMARC besteht also allein über DKIM |
| SendGrid | Die Root-Domain ist das, was du bei der Domain Authentication eintippst | Ein automatisch erzeugtes em####.-CNAME, das du nie gewählt hast |
| Amazon SES | Eigene Domain | Eine eigene MAIL-FROM-Subdomain, die einen MX-Eintrag und ein eigenes SPF braucht |
| Customer.io | Root-Domain, unangetastet | Eine kontospezifische Subdomain deiner eigenen Domain für Return-Path, SPF und Signatur, von ihnen benannt und nicht von dir |
| MailerSend | Jede Subdomain einer verifizierten Domain | Standardmäßig nichts: Subdomain-Mail wird mit der übergeordneten Domain signiert |
Bei der MailerSend-Zeile lohnt sich ein Innehalten, denn sie ist der Fall, in dem das Befolgen des Ratschlags buchstäblich nichts bringt: Die Mail wird weiterhin mit der übergeordneten Domain signiert, es existiert also nie eine getrennte Identität. Die Anbieter widersprechen sich auch selbst. Klaviyos eigene Community hat beide Positionen im Abstand von vierzehn Monaten veröffentlicht, eine Support-Antwort sagt, die Reputation hänge an der Root-Domain und nicht an der Subdomain, eine andere sagt, eine Sende-Subdomain isoliere die Marketing-Aktivität, und Mailgun widerspricht sich über zwei seiner eigenen Dokumentationsseiten hinweg. Wenn Anbieter sich selbst widersprechen, ist die Subdomain-Regel eine Einschränkung ihrer Architektur und kein Gesetz der Zustellbarkeit, und die ehrliche Lesart ist, dass beide Antworten teilweise richtig sind: Die Isolation ist real für den DKIM-Reputations-Identifier und für die Blacklist-Richtung, und sie fehlt bei gemeinsam genutzten Sende-IPs und beim Compliance-Verlauf, den Google auf deiner primären Domain führt.
Massen-E-Mails von deiner Root-Domain zu senden schadet deinem SEO nicht
Keine Suchmaschine und kein Mailbox-Provider dokumentiert irgendeine Verbindung zwischen E-Mail-Versand und Suchrankings, in keine der beiden Richtungen, und die Kennzahl, die dabei üblicherweise genannt wird, ist keine, die Google führt. Googles Search-Spam-Richtlinien erwähnen nirgends E-Mail, Mailserver oder Authentifizierungseinträge, und Domain Authority ist ein Score eines Drittanbieters und kein Google-Signal.
Die präzise Fassung der Sorge betrifft Erreichbarkeit und nicht Rankings. Eine Domain-Blacklist-Aufnahme kann auf Resolver-Ebene durchgesetzt werden, für alle, die hinter einer auf diesen Feeds gebauten DNS-Firewall sitzen, was deine Website für diese Nutzer unerreichbar macht, während deine Rankings genau dort bleiben, wo sie waren. Die Nutzungsbedingungen deines Hosters oder deiner Plattform sind ein drittes, davon getrenntes Risiko. Keines davon ist SEO.
Prüfe, von wo du tatsächlich sendest
Führe den Unspam Vier-Domain-Header-Check an der letzten Nachricht durch, die dein Programm zugestellt hat: die sichtbare From:-Domain, die Return-Path-Domain, der d=-Wert von DKIM und der Host in einem getrackten Link. Bei den meisten, die glauben, ihre Streams getrennt zu haben, stellt sich heraus, dass sie nur das Erste verschoben haben.
Prüfe dann die Namen selbst. Schick die Root-Domain und jede Sende-Subdomain getrennt durch den E-Mail-Health-Check, denn eine saubere Root sagt dir nichts über eine Subdomain, die keinen SPF-Eintrag und kein MX hat. Der globale Durchschnitt liegt derzeit bei 89/100, und eine brandneue Sende-Subdomain wird nicht dort starten.
Wenn die Einträge stimmen, schick die Nachricht und nicht die Theorie. Lass die Kampagne, die du gerade senden willst, durch den kostenlosen Unspam Spam-Test laufen und lies das Authentifizierungs-Panel: Wenn Return-Path und d= die Subdomain sind, die du gewählt hast, und das From: weiterhin deine Root ist, dann ist die Trennung echt, und du siehst, wo die Nachricht tatsächlich landet, bevor es ein Abonnent tut.
