Ein Newsletter, der nie ankommt, ist kein Marketingkanal – er ist ein Leck. In B2B-Setups kommt dazu, dass Empfänger streng filtern, Unternehmen mit mehreren Gateways arbeiten und E-Mail-Ketten oft über mehrere Systeme laufen. Genau hier entscheidet sich, ob Ihre Nachrichten Vertrauen aufbauen oder still im Spam-Ordner verschwinden.
Ich habe in Projekten erlebt, wie „Deliverability“ auf einmal kein Bauchgefühl mehr war, sondern eine messbare Pipeline: Domain-Authentifizierung, Signaturen, Richtlinien und Auswertung. Sobald SPF, DKIM und DMARC korrekt gesetzt waren, stieg nicht nur die Zustellrate, sondern auch die Relevanz der Ergebnisse im Funnel. Denn wenn die Hälfte der Mail nie zugestellt wird, ist jedes Tracking nur Theater.
In diesem Artikel zeige ich Ihnen, wie Sie B2B-Newsletter-Deliverability – SPF, DKIM und DMARC einrichten so planen und umsetzen, dass es nicht nur formal „aktiviert“, sondern robust betrieben ist. Sie bekommen konkrete Schritte, sinnvolle Testmethoden und Beispiele aus der Praxis, damit Sie die Kontrolle behalten – auch wenn sich Systeme, Versanddienste oder Subdomains ändern.
Deliverability im B2B: Warum Authentifizierung mehr ist als Technik
Im B2B zählt nicht die Reichweite auf dem Papier, sondern die Zustellung im richtigen Postfach. Deliverability ist die Schnittstelle zwischen Ihrer technischen Infrastruktur und dem Risiko-Management der Empfänger-Seite. Große Domains schauen nicht nur auf Inhalte, sondern auf Signale, die die Herkunft einer Nachricht plausibilisieren.
SPF, DKIM und DMARC sind dabei keine „Nice-to-have“-Add-ons, sondern die Grundlage für Vertrauen. SPF prüft, ob ein Server überhaupt berechtigt ist, im Namen Ihrer Domain zu senden. DKIM liefert eine kryptografische Signatur, die bestätigt, dass die Nachricht auf dem Weg nicht in eine unerkannte Richtung manipuliert wurde. DMARC verbindet beides und legt fest, was passieren soll, wenn Prüfungen fehlschlagen.
Was viele unterschätzen: Diese Signale sind im Alltag nicht statisch. Newsletter laufen über Versanddienstleister, CRM-Plattformen, Marketing-Automation oder eigene SMTP-Relays. In jeder dieser Schichten kann sich der Absenderpfad ändern. Wenn Sie SPF und DKIM nicht sauber an diese Realität anpassen, erzeugen Sie aus Versehen die Gründe, warum Filter zuschlagen.
In einem Projekt, das ich begleitet habe, war die Situation klassisch: Die Kampagnen „funktionierten“ scheinbar, weil einzelne Empfängerlisten gut reagierten. Erst als wir die Mail-Header systematisch auswerteten, sahen wir, dass Subdomains unterschiedlich behandelt wurden und DMARC zu streng eingestellt war. Die Folge waren Zustellprobleme, die sich erst nach einigen Wochen zeigten, weil die Filter jedes Volumen anders bewerten.
Die drei Bausteine im Überblick: SPF, DKIM, DMARC
SPF steht für „Sender Policy Framework“. Es ist im Kern eine DNS-Regel, die beschreibt, welche IP-Adressen oder Hosts eine Domain zum Versand verwenden dürfen. Der Empfänger schaut in den SPF-Record, vergleicht die sendende IP und entscheidet, ob die Herkunft plausibel ist.
DKIM („DomainKeys Identified Mail“) arbeitet anders. Die Domain, die signiert, wird im DKIM-Header festgehalten, und die Signatur wird so erzeugt, dass der Empfänger prüfen kann, ob die Nachricht seit dem Signieren verändert wurde. Wichtig ist: DKIM ist nicht einfach „an oder aus“, sondern hängt von korrekten Signaturparametern, Canonicalization und dem Zusammenspiel mit Mailingplattformen ab.
DMARC („Domain-based Message Authentication, Reporting and Conformance“) ist die politische Instanz. DMARC fordert, dass SPF- oder DKIM-Ergebnisse nicht nur bestanden haben, sondern auch „konform“ zur sichtbaren Absenderdomäne sind. Dazu kommen Richtlinien, wie mit Fehlern umgegangen werden soll – etwa Quarantäne oder Ablehnung – sowie Report-Optionen.
Für die Praxis heißt das: SPF und DKIM liefern die technischen Prüfergebnisse. DMARC entscheidet, was die Ergebnisse bedeuten. Wenn eine Stufe unklar oder inkonsistent ist, verlieren Sie Kontrolle über die Zustellung. Und genau diese Kontrolle ist im B2B der Unterschied zwischen „wir senden“ und „wir verkaufen“.
Bevor Sie konfigurieren: Inventur Ihrer Versandwege
Bevor Sie DNS-Records anpassen, lohnt sich eine klare Inventur. Schreiben Sie auf, welche Systeme für den Versand zuständig sind: Marketing-Automation, Newsletter-Tool, Transaktionsversand, CRM, interner SMTP-Relay, externe Dienste und ob es unterschiedliche Versandkanäle für verschiedene Abteilungen gibt.
Notieren Sie außerdem, welche Absenderdomänen tatsächlich im Header auftauchen. In der Praxis sind es selten „nur eine“. Häufig gibt es eine Hauptdomain, eine Subdomain für Newsletter (z. B. news. oder mail.) und separate Domains für Transaktionsmails. Jede Kombination hat Folgen für SPF, DKIM und DMARC.
Ein häufiger Fehler: Teams definieren im UI einen „From“-Namen und eine „Absenderadresse“, aber der Versanddienstleister nutzt intern andere Werte wie Return-Path oder signiert mit einer anderen Domain. Das ist nicht falsch, solange es konsistent konfiguriert ist. Es ist nur fatal, wenn SPF und DKIM nicht zur sichtbaren Absenderdomäne passen.
Wenn Sie Marketing in einem Funnel-Setup betreiben, sollten Sie diese Inventur auch mit den Zahlen verbinden. Schätzen Sie, welche Segmente in welchem Volumen senden, ob Sie „Batch-and-Blast“ oder triggerbasierte Journeys nutzen und ob die Zustellqualität über Zeit variiert. Lieferprobleme werden manchmal zuerst in bestimmten Journeys sichtbar, weil dort andere Mail-Routen verwendet werden.
SPF einrichten: Richtlinien, die nicht ausufern
SPF wird als TXT-Record in der DNS-Zone Ihrer Domain hinterlegt. Der Record enthält Mechanismen wie ip4, include, a und weitere Elemente. Empfänger werten SPF anhand eines bestimmten Algorithmus aus und stoppen in der Regel bei einem Treffer oder spätestens am Ende der Auswertung.
Der erste Schritt ist die Ermittlung der sendenden IPs und Services. Wenn Sie einen Versanddienst nutzen, liefert dieser typischerweise einen fertigen SPF-„include“-Wert. Der Vorteil: Sie übernehmen nicht die IP-Listen selbst. Der Nachteil: Wenn der Dienst später umstellt, müssen Sie die Konfiguration nicht manuell pflegen, aber Sie sollten die Abhängigkeit im Blick behalten.
Für viele Unternehmen ist eine Struktur sinnvoll, die klar zwischen „eigene Systeme“ und „externe Versanddienste“ unterscheidet. Ein SPF-Record, der jede IP einzeln auflistet, wird mit der Zeit schwer wartbar. Deshalb ist es üblich, include-Blöcke zu verwenden und eigene Server gezielt einzutragen.
Gleichzeitig gilt: SPF hat Grenzen. Lange Records erhöhen die Komplexität, können Auswertungsgrenzen erreichen und im Ergebnis bei manchen Empfängern schlechter abschneiden. In einem Setup, das ich betreut habe, war der SPF-Record über Jahre gewachsen, weil jeder neue Dienst „einfach hinzugefügt“ wurde. Das Monitoring zeigte später schwankende SPF-Pass-Raten, bis wir den Record bereinigt und reduziert haben.
Typisches SPF-Record-Pattern für Newsletter
Ein praktisches Ziel ist ein SPF-Record, der die tatsächlichen Versandquellen abbildet, ohne unnötige Erweiterungen. Im Newsletter-Kontext wird häufig eine Subdomain genutzt, die ausschließlich für Mailing verwendet wird. Dann isolieren Sie den SPF-Umfang und reduzieren Kollisionen mit anderen Mailflows.
| Baustein | Zweck | Hinweis |
|---|---|---|
| v=spf1 | SPF-Version | Standardkonform |
| include: | Dienstberechtigung | Von Versandplattformen bereitgestellt |
| ip4: | Eigene Server | Nur wenn Sie wirklich über diese IPs senden |
| -all / ~all | Default-Aktion | -all ist hart, ~all ist weich |
Wenn Sie gerade erst in die harte Aussteuerung gehen, ist ein zweistufiges Vorgehen üblich: zunächst eine „weiche“ Ablehnung mit ~all, danach Umstellung auf -all, nachdem Sie Logs, Reports und Tests geprüft haben. Das minimiert das Risiko, dass versehentlich legitime Quellen fehlschlagen.
Softfail vs. Fail: Wie Sie Risiko einkalkulieren
Bei SPF ist die letzte Mechanik entscheidend: ~all bedeutet „Softfail“ und signalisiert, dass Absender nicht passen, aber der Empfänger kann dennoch zustellen. -all steht für „Fail“ und fordert strengere Ablehnung.
Im B2B ist „Fail“ oft erst sinnvoll, wenn Ihre Versandquellen vollständig bekannt und stabil sind. Gerade bei Unternehmen mit historisch gewachsenen Setups kann es versteckte Versandpfade geben – zum Beispiel für Umzüge, Testumgebungen oder ältere Automationsflüsse. Mit DMARC können Sie zudem Abstufungen steuern, aber beginnen Sie trotzdem mit einer sauberen SPF-Basis.
Wichtig ist auch die saubere Ausrichtung: SPF wird auf Basis der „präfekten“ Domain ausgewertet, die der Empfänger nutzt. Wenn Sie DMARC später konsequent ausrollen, muss die SPF-Konformität (Alignment) passen. Das ist der Punkt, an dem SPF und DMARC zusammenwirken.
DKIM einrichten: Signatur, die zu Ihrer Domain passt
DKIM ist eine Signatur, die in Ihrem DNS als Public Key bereitgestellt wird. Der Versanddienst signiert die ausgehende Nachricht mit einem privaten Schlüssel. Der Empfänger kann dann mit Ihrem Public Key prüfen, ob die Signatur gültig ist.
Wie Sie DKIM einrichten, hängt stark vom Versanddienst ab. Einige Plattformen erzeugen Ihnen eine DKIM-Konfiguration inklusive Key-Paar und Detaileinstellungen. Andere erfordern, dass Sie im DNS einen DKIM-TXT-Record anlegen und die Versandplattform so konfigurieren, dass sie mit dem passenden Selector signiert.
Der Selector ist dabei nicht nur ein technisches Detail. In der Praxis verwalten Unternehmen mehrere DKIM-Selectoren, etwa für unterschiedliche Abteilungen, Systeme oder zeitlich versetzte Schlüsselrotationen. Wichtig ist, dass Sie nachvollziehen können, welcher Selector in welchen Flows verwendet wird, sonst fehlt Ihnen die klare Kausalität, wenn ein bestimmter Journey plötzlich sinkt.
DKIM-Alignment und die From-Domäne
DKIM prüft nicht allein, ob die Signatur gültig ist. Für DMARC zählt zusätzlich das Alignment zwischen der Domain, die im DKIM-Signaturkopf steht, und der sichtbaren Absenderdomäne. Das bedeutet: Wenn Sie DKIM auf einer anderen Subdomain signieren als die, die im From-Feld erscheint, kann DMARC scheitern.
Ein typischer Stolperstein: Marketingteams wechseln von einer Mailing-Subdomain zur Hauptdomain, während die Signaturdomäne in der Versandplattform unverändert bleibt. Dann ist DKIM zwar „gültig“, aber nicht „konform“. Das ist genau der Moment, in dem Empfänger-Policies greifen und Zustellungen abnehmen.
In meinen früheren Projekten war es hilfreich, vor der Umsetzung eine kleine Matrix zu erstellen: Welche Absenderadresse erscheint im From-Feld, welche Return-Path-Domain wird genutzt und mit welcher DKIM-Domain wird signiert. Diese Matrix verhindert Diskussionen im Nachhinein und macht die Umsetzung kontrollierbar.
DMARC einrichten: Von Berichten zu klaren Entscheidungen
DMARC ist die Schicht, die aus technischen Prüfungen eine konsequente Regel macht. Sie entscheiden damit, was passiert, wenn SPF oder DKIM nicht besteht – aber auch, wie streng die Konformität bewertet wird.
Im DMARC-Record definieren Sie mehrere Kernwerte. Dazu gehören die Policy (p), also ob Fehler zu keiner Aktion, Quarantäne oder Ablehnung führen. Außerdem gibt es Subdomain-Optionen (sp), die entscheiden, wie Subdomains behandelt werden. Dazu kommen Ausrichtungsregeln, die festlegen, ob die Übereinstimmung zwischen SPF-Domain und From-Domain oder zwischen DKIM-Domain und From-Domain streng oder relaxed sein soll.
Im B2B-Kontext ist DMARC besonders wertvoll, weil sich Empfänger auf diese klare Leitlinie verlassen können. Wenn Sie DMARC sauber einführen, reduzieren Sie nicht nur Fehlentscheidungen, sondern bekommen auch Daten darüber, wie andere Systeme Ihrer Domain Mails senden, ob Sie ungewollte Spoofing-Versuche sehen und wie Ihre eigenen Flows abschneiden.
Monitoring: Warum Reports in der Praxis mehr bringen als Theorie
DMARC Reports liefern Ihnen Einblicke, welche IPs und Domains bei Empfängern SPF/DKIM/Alignment-Probleme verursachen. Dabei gibt es verschiedene Report-Formate. Klassisch waren XML-basierte Aggregate Reports, moderne Setups nutzen oft auch strukturierte Report-Mechanismen.
Der Nutzen liegt auf der Hand: Sie sehen nicht nur, was in Ihrem DNS steht, sondern was tatsächlich bei Empfängern ankommt. Und das ist die entscheidende Ebene für Zustellbarkeit, weil Empfänger-Logik und Versandpfade manchmal abweichen.
Wenn Sie Deliverability als Teil eines Vertriebsprozesses verstehen, ist das Monitoring wie ein Frühwarnsystem. Sie erkennen Trends, bevor Kampagnen-Performance kippt. Das ist keine „Messerei“, sondern ein Hebel für planbare Ergebnisse.
Policy-Schritte: p=none, p=quarantine, p=reject
Viele Teams starten mit p=none. Das ist der sanfte Einstieg, bei dem Empfänger zwar das Ergebnis auswerten, aber keine harte Aktion ausführen. In dieser Phase sammeln Sie Daten und vergleichen, welche Ihrer echten Versandquellen als passend erkannt werden.
Danach folgt p=quarantine, um fehlerhafte Mails in Quarantäne zu bewegen. Wenn Sie auch hier Stabilität sehen und die Reports keine Überraschungen zeigen, kann p=reject die letzte Stufe sein. Dabei sollten Sie beachten, dass „reject“ je nach Empfängersystem nicht identisch wirkt, aber im Regelfall deutlich strenger ist.
Der richtige Zeitpunkt hängt von Ihrer Organisation ab. Wenn Ihre Versandpfade häufig wechseln oder Sie neue Systeme einführen, ist eine längere Beobachtungsphase sinnvoll. Wenn Sie dagegen ein sehr stabiles Setup haben, kann die Umstellung schneller gehen.
Subdomains, Absenderdomänen und Alignment: Der Teil, der oft weh tut
Im Alltag nutzen Unternehmen manchmal mehrere Absenderdomänen: eine Domain für B2B-Newsletter, eine andere für Transaktionsmails, gelegentlich zusätzlich eine Subdomain für Partner-Kommunikation. Das ist nicht per se schlecht. Problematisch wird es, wenn die Authentifizierung über Subdomains uneinheitlich konfiguriert ist.
DMARC-Alignment kann entweder „relaxed“ oder „strict“ sein. Bei relaxed genügt meist eine Übereinstimmung auf der Domain-Ebene, bei strict wird stärker geprüft. Welche Variante passt, hängt davon ab, wie Sie signieren und welche From-Domains Sie verwenden.
Wenn Sie beispielsweise für Newsletter eine Subdomain nutzen (z. B. campaigns.ihredomain.de) und diese Subdomain signieren, aber die From-Adresse zeigt auf eine Hauptdomain, kann DMARC strict scheitern. Dann entscheiden Sie entweder, ob Sie die signierende Domain anpassen oder ob Sie DMARC so setzen, dass es zu Ihrem Modell passt.
In einem Unternehmen, das ich kenne, gab es ein starkes Wachstum in Regionen. Jede Region hatte eigene Mail-Templates und unterschiedliche Absenderprofile. Technisch wurden dieselben Versandsysteme genutzt, aber die Absenderdomänen unterschieden sich. Erst als wir konsistente DKIM-Signaturdomänen und ein DMARC-Setup für die relevanten Subdomains definiert hatten, verschwand die „Regionen-Zustellungsrate“-Dramatik.
Ein praktischer Plan: Konsistenz herstellen statt Komplexität erhöhen
Wenn Sie heute mehrere Absenderdomänen haben, müssen Sie nicht alles sofort vereinheitlichen. Doch Sie sollten eine klare Regel definieren: Welche Domäne steht im From-Feld, welche Domäne wird für DKIM verwendet und welche Domäne wird bei SPF in der Policy geprüft.
Es hilft, eine „Master-Domain“ für Marketing zu wählen. Von dort aus definieren Sie entweder Subdomains für Subchannels oder bleiben bei einer Domain, aber dann konsequent mit passenden Records. Je weniger Ausnahmen, desto einfacher ist die Zustellbarkeit – und desto schneller können Sie Fehler finden, wenn sich etwas ändert.
Konfiguration für reale B2B-Newsletter: ein Ablauf, der funktioniert
Damit die Einrichtung nicht in DNS-Fragmenten endet, empfehle ich eine Umsetzung in Stufen. Diese Reihenfolge reduziert Überraschungen und macht die Ergebnisse nachvollziehbar.
Schritt 1: Versandquellen und Header dokumentieren
Erfassen Sie für einen typischen Newsletter die Header-Felder: Return-Path, From, DKIM-Signature, SPF-Resultate und die IP des sendenden Systems. Nutzen Sie dafür mindestens zwei Empfänger, idealerweise von unterschiedlichen Mailprovidern.
Diese Dokumentation ist später Gold wert. Wenn SPF oder DKIM fehlschlagen, sehen Sie sofort, ob es um eine Absenderdomäne, eine andere signierte Domain oder einen veränderten Versandpfad geht.
Schritt 2: SPF-Record aufsetzen und bereinigen
Erstellen Sie einen SPF-Record, der die tatsächlichen Versandquellen abbildet. Starten Sie mit einer vorsichtigen Policy wie ~all, wenn Sie noch nicht sicher sind, welche Quellen in allen Journeys genutzt werden.
Setzen Sie außerdem einen Plan zur Wartung auf. Wenn ein neuer Versanddienst hinzukommt, braucht er auch ein Update. Viele Deliverability-Probleme entstehen nicht durch falsche Records, sondern durch vergessene Updates.
Schritt 3: DKIM mit passenden Selector-Strategien etablieren
Richten Sie DKIM so ein, dass die signierende Domain zu Ihrer From-Domäne passt. Dabei hilft es, Selectoren sauber zu benennen und Rotationstermine intern festzuhalten. Wenn Ihr Versanddienst DKIM-Rotation automatisiert, prüfen Sie zumindest einmal die korrekte Abbildung im DNS.
Testen Sie nach der Einrichtung mit E-Mails aus einer kontrollierten Umgebung. Idealerweise prüfen Sie, ob die DKIM-Signatur bei Empfängern als pass erkannt wird und ob DMARC später keine Alignment-Probleme bekommt.
Schritt 4: DMARC zunächst beobachten, dann strenger machen
Starten Sie DMARC mit p=none oder einer moderaten Stufe, je nachdem, wie stabil Ihr Umfeld ist. Achten Sie besonders auf Berichte: Welche Ihrer echten Absender werden als „pass“ erkannt, welche bekommen „fail“ und warum?
Erst wenn Sie die Ursachen verstehen, erhöhen Sie die Strenge. So vermeiden Sie den Klassiker, bei dem nach dem Umstellen auf reject plötzlich echte Newsletter blockiert werden, weil eine selten genutzte Journey noch nicht sauber konfiguriert ist.
Testing-Strategie: Nicht raten, sondern belegen
Eine gute Deliverability-Strategie basiert auf Tests, die Aussagen ermöglichen. Dazu gehört, dass Sie Ihre Ergebnisse in einem wiederholbaren Schema dokumentieren. Ein einzelner Test reicht selten, weil Empfänger ihre Filterentscheidungen dynamisch anpassen.
Nutzen Sie Tools, die SPF/DKIM/DMARC-Validierung prüfen können, aber verlassen Sie sich nicht ausschließlich darauf. Prüfen Sie auch reale Zustellung: Inbox vs. Spam, Timing, Bounce-Logik und ob Empfänger-Clients unterschiedliche Ergebnisse zeigen.
Ich arbeite gern mit einer kleinen Checkliste pro Kampagnenstart. Darin stehen: Records-Versionen (DNS-Änderungszeitpunkt), getestete Empfänger-domains, erwartete Outcomes (z. B. DKIM pass, SPF pass) und die Beobachtungsdauer. Damit reduziert man in Teams die „Warum ist das jetzt anders?“-Diskussionen.
Was Sie in den Ergebnissen konkret sehen sollten
Für SPF erwarten Sie, dass der Empfänger das Ergebnis als pass oder zumindest consistent bewertet. „Pass“ ist gut, aber entscheidend ist das Zusammenspiel mit DMARC-Alignment. Für DKIM erwarten Sie eine gültige Signatur und eine passende signierende Domain.
DMARC sollten Sie über Reports und Message-Header nachvollziehen. Wenn DMARC-Fehler auftauchen, müssen Sie die Ursache auflösen: falsche DKIM-Domain, SPF-Mechanik, Alignment-Regeln, oder ein Versandpfad, der nicht im SPF abgedeckt ist.
Ein sauberer Test zeigt also nicht nur, dass „irgendetwas“ funktioniert, sondern dass alle Teile in der Kette konsistent sind. Genau dann wird Deliverability zuverlässig.
Häufige Fehlerbilder bei SPF, DKIM und DMARC
Ein typisches Fehlerbild ist ein SPF-Record, der nur den Versanddienst abdeckt, aber nicht den internen SMTP-Relay oder alternative Pfade. Das führt dazu, dass bestimmte Journeys fehlschlagen, obwohl andere funktionieren. In B2B-Umgebungen fällt das oft erst auf, wenn neue Segmentierungen live gehen.
Bei DKIM kommt häufig „gültige Signatur, falsches Alignment“ vor. Dann ist die Signatur technisch korrekt, aber DMARC bewertet sie als nicht konform. Ursachen sind meist Unterschiede zwischen signierender Domain und From-Domäne.
DMARC wird außerdem oft zu schnell verschärft. Teams sehen eine gute Zustellung in frühen Tests und schalten auf reject, bevor alle Versandvarianten geprüft sind. Das Ergebnis sind Zustellungen, die plötzlich drastisch abfallen – besonders in Bereichen, in denen seltener gesendet wird.
Ein weiteres Fehlerbild: Record-Pflege ohne Governance. Wenn jemand die DNS-Records ändert, aber niemand im Team nachvollzieht, warum, wird die nächste Anpassung zum Blindflug. Deliverability ist dann nicht wiederholbar, und genau das wollen Sie im Vertrieb nicht.
Mathematische Perspektive: Deliverability in den Funnel übersetzen
Wenn Sie B2B-Marketing nach messbaren Ergebnissen ausrichten, lohnt sich eine einfache Modellierung. Stellen Sie sich vor, Sie starten eine Kampagne mit einer Zielanzahl Empfänger. Jede Zustellungsebene beeinflusst Conversion, und jede Fehlzustellung kostet Umsatz.
Sie können das als Produkt von Wahrscheinlichkeiten verstehen. Zum Beispiel: Zustellwahrscheinlichkeit nach Authentifizierung, Wahrscheinlichkeit für Inbox-Landung, Wahrscheinlichkeit für Öffnung, Klick und dann Conversion. Wenn die Authentifizierung schwankt, wird die gesamte Kette unruhig.
Damit Sie harte Verkäufe unterstützen, brauchen Sie Stabilität. SPF/DKIM/DMARC bauen genau diese Stabilität auf, weil sie die Wahrscheinlichkeit erhöhen, dass Empfänger nicht in Abwehrmodus schalten.
Ein Beispiel für Entscheidungslogik
Angenommen, Sie sehen bei einer Kampagne Open Rates, die noch okay wirken, aber die Pipeline-Anzahl ist niedriger als erwartet. Ein Teil davon kann schlechte Inbox-Landung sein. Wenn Sie DMARC-Reports zeigen, dass bestimmte IPs oder Absenderdomains bei Empfängern fehlschlagen, wissen Sie, dass Authentifizierung ein Haupttreiber ist.
So entsteht ein pragmatischer Ablauf: erst Deliverability verbessern, dann die Funnel-Kennzahlen beurteilen. Ohne diese Reihenfolge optimieren Teams manchmal Inhalte, während die Ursache in DNS-Regeln liegt.
Diese Logik ist nicht theoretisch. Sie hilft mir immer wieder, Diskussionen zu beenden: „Der Text ist nicht relevant genug“ ist eine bequeme Erklärung, bis Sie feststellen, dass ein großer Teil der Mails nie im Postfach landet.
Operativer Betrieb: Wenn sich Systeme ändern
Ein SPF-, DKIM- und DMARC-Setup ist nicht „für immer“. Versanddienste ändern sich, IP-Bereiche wechseln, Subdomains werden neu genutzt, und neue Journeys kommen hinzu. Im B2B passieren solche Dinge oft im Hintergrund, weil IT- oder Marketing-Teams parallel arbeiten.
Darum braucht es Betriebsregeln. Legen Sie fest, wer Records ändert, wer testet und wie Sie Änderungen dokumentieren. Besonders wichtig sind DNS-Änderungsfenster und ein Kommunikationsprozess, damit Kampagnen nicht „zufällig“ mit veränderten Einstellungen starten.
Ein weiterer Punkt ist Key-Management bei DKIM. Manche Organisationen rotieren Schlüssel. Wenn das passiert, müssen Selector und DNS-Records abgestimmt sein. Lassen Sie diese Prozesse nicht nur im Tool „passieren“, sondern prüfen Sie zumindest nach der Umstellung stichprobenartig die Zustellqualität.
Monitoring ohne Overhead
Sie brauchen nicht zwangsläufig fünf neue Monitoring-Tools. Oft reichen ein Report-Workflow, ein gelegentlicher Header-Check und ein Zustell-Tracking über Ihre Versandplattform. Entscheidend ist die Regelmäßigkeit: Einmal im Monat oder nach jeder größeren Systemänderung ist deutlich besser als „wenn es knallt“.
Wenn Sie DMARC Reports nutzen, bauen Sie daraus eine einfache Übersicht. Welche Absenderquellen sind „expected“, welche „unexpected“, und welche fehlschlagen immer wieder? Mit dieser Einordnung können Sie schneller entscheiden, ob ein Problem wirklich relevant ist oder nur einzelne Resteffekte betrifft.
So bleibt Deliverability in Ihrer Organisation handhabbar. Und genau das ist in B2B-Teams wichtig, weil Ressourcen knapp sind und man nicht monatelang in Detailfragen versinken will.
Konkrete Umsetzungsvorlage für die Planung
Damit Sie intern schnell Struktur schaffen, hilft eine Vorlage, in der Sie Records, Ziele und Tests festhalten. Die Tabelle ist bewusst generisch, weil Versanddienste sich unterscheiden, aber die Logik gleich bleibt.
| Bereich | Was Sie festlegen | Beobachtung | Zeithorizont |
|---|---|---|---|
| SPF | Welche Hosts/Includes, welche Policy am Ende | SPF pass in Headern, keine unerwarteten Failures | vor DMARC-Policy-Verschärfung |
| DKIM | Selector, signierende Domain, passende Konfiguration im Versanddienst | DKIM pass und DMARC-Alignment erfüllt | nach SPF-Test |
| DMARC | p-Policy, Alignment, Subdomain-Regeln, Report-Ziele | Report-Daten stabil, keine legitimen Journeys betroffen | mehrstufig über mehrere Wochen |
Wenn Sie diese Schritte sauber dokumentieren, vermeiden Sie das „Wir haben etwas geändert, aber niemand weiß was“ – ein Problem, das ich in Marketing-Operations leider häufig sehe. DNS ist kein Ort für Gedächtnisspiele.
Wie sich das auf Verkauf und Pipeline auswirkt
Stellen Sie sich die Arbeit von Vertrieb und Marketing wie zwei Zahnräder vor. Marketing erzeugt Nachfrage, Vertrieb konvertiert sie. Wenn Deliverability schwankt, fehlt dem Vertrieb oft die richtige Menge an Leads zur richtigen Zeit – und die Ursache wird nicht erkannt, weil sie technisch und unsichtbar ist.
Ein robustes Authentifizierungssetup stabilisiert die Zustellung. Stabil heißt: weniger unerklärliche Variationen bei Öffnungen, Klicks und Antworten. Und es heißt auch: Ihr Reporting wird vertrauenswürdiger, weil die Messwerte nicht mehr hauptsächlich Zustellprobleme widerspiegeln.
Aus meiner Sicht ist genau das der Punkt, an dem Marketing nicht „nur Reichweite“ liefert, sondern harte Ergebnisse unterstützt. Man kann Funnels optimieren, aber ohne Deliverability optimieren Sie im Blindflug.
Feintuning: Wann Sie relaxed statt strict wählen
Die Wahl zwischen strict und relaxed Alignment in DMARC ist keine Glaubensfrage, sondern eine Designentscheidung. Sie richtet sich danach, wie Sie Ihre Header und Signaturen konfigurieren und wie stark Sie von Subdomains abweichen.
Wenn Sie konsequent eine einzelne From-Domäne verwenden und Ihre DKIM-Signatur domänentreu ausrichten, kann strict sinnvoll sein. Das gibt Ihnen eine klare, robuste Policy. Wenn Sie dagegen historische Gründe haben, die unterschiedliche Subdomains erzeugen, kann relaxed die Umstellung vereinfachen.
Wichtig ist: Sobald Sie strict wählen, müssen Ihre Quellen sauber passen. Das heißt nicht, dass relaxed „schlechter“ ist, aber es bedeutet, dass Sie Regeln lockerer interpretieren. Deshalb ist es sinnvoll, zunächst die Daten aus Reports zu nutzen, um die Entscheidung zu untermauern.
Rollout-Plan in der Praxis: Von der ersten Änderung bis zum stabilen Betrieb
Der beste Zeitpunkt für die Einführung neuer Policies ist selten „am Montagmorgen, direkt nach dem DNS-Update“. Planen Sie einen Rollout so, dass Sie am selben Tag testen können und innerhalb weniger Tage Beobachtungen an mehreren Empfänger-domains haben.
Ein typisches Vorgehen: Erst SPF setzen und validieren, dann DKIM. Danach DMARC mit p=none und Reports starten. Nach stabilen Ergebnissen erhöhen Sie schrittweise die Strenge. Dabei bleiben Sie mit Blick auf die kritischen Journeys – etwa Onboarding, Lead Nurturing und Re-Engagement – besonders wachsam.
Wenn Sie ein B2B-Newsletter-Programm mit mehreren Segmenten haben, legen Sie außerdem eine Priorisierung fest. Manche Segmente sind wichtiger für Pipeline als andere. Diese Segmente zuerst zu schützen reduziert Risiko während der Umstellung.
So wird aus einer „technischen Aufgabe“ ein Prozess, der zum Unternehmen passt. Und das ist am Ende der Unterschied zwischen einmaligem Setup und nachhaltiger Deliverability.
Dokumentation und Verantwortlichkeiten: Die unterschätzte Stellschraube
Viele Deliverability-Probleme sind keine Konfigurationsfehler, sondern Organisationsfehler. Wenn niemand Eigentümer der DNS-Records ist, werden Änderungen langsam, riskant oder unvollständig. In B2B-Umfeldern mit mehreren Stakeholdern ist klare Verantwortung daher wichtiger als jedes Tool.
Definieren Sie, wer die Records betreut, wer Tests abnimmt und wer die Reportdaten interpretiert. Diese Rollen müssen nicht kompliziert sein, aber sie müssen eindeutig sein. Ein kleiner „Owner“-Prozess verhindert, dass sich Änderungen gegenseitig überlagern.
Ich habe Teams gesehen, die ein einziges Dokument genutzt haben: „Mail Auth Setup“. Darin standen SPF/DKIM/DMARC-Details, erwartete Absenderdomänen, Selector-Listen, letzte Änderung und Ansprechpartner. Genau diese Klarheit macht Deliverability langfristig zuverlässig.
Abschließend bereit für harte Tests: Was Sie jetzt konkret tun können
Wenn Sie heute mit SPF, DKIM und DMARC starten oder etwas korrigieren, sollten Sie Ihre nächsten Schritte so wählen, dass sie direkt messbar sind. Beginnen Sie mit der Inventur der Versandwege, setzen Sie SPF korrekt, konfigurieren Sie DKIM mit passendem Selector und sorgen Sie dann für DMARC-Alignment über Reports und schrittweise Policies.
Wichtig ist, dass Sie nach jeder wesentlichen Änderung eine Testphase einplanen. Nicht, weil Sie Angst vor Fehlern haben müssen, sondern weil Sie die Wirkung belegen wollen. In einem B2B-Funnel zählt die Kausalität. Sie wollen wissen, warum sich Zustellung und Performance verbessern.
Sobald Sie dieses Setup stabil betreiben, werden Newsletter im Alltag leichter steuerbar. Ihre Messdaten sind weniger vom Zufall abhängig, und Ihre Vertriebsprozesse bekommen die Grundlage, die sie brauchen. Genau dort setzt eine zuverlässige B2B-Newsletter-Deliverability – SPF, DKIM und DMARC einrichten-Strategie an: nicht nur am DNS-Record, sondern am Ergebnis im Postfach und am Ende in der Pipeline.