SPF, DKIM, DMARC & BIMI: Die Checkliste für Cold-Email-Domains

Wer für adressierten B2B-Outreach mehrere Sending-Domains und Subdomains betreibt, kennt das Problem: SPF, DKIM und DMARC waren beim Setup vor einem Jahr korrekt — und heute weiß niemand mehr, ob der SPF-Lookup-Limit überschritten ist oder der DKIM-Key noch aktiv rotiert wird. Dieser Artikel geht über die Erstinstallation hinaus und zeigt, wie Sie SPF, DKIM, DMARC, ARC und BIMI dauerhaft überwachen — mit Tools wie MXToolbox statt Bauchgefühl. Der Fokus liegt bewusst nicht auf der Ersteinrichtung, sondern auf dem, was danach passiert und in den meisten Anleitungen fehlt.

Warum die einmalige Einrichtung nicht reicht

Bei den meisten Anleitungen zu SPF, DKIM und DMARC endet die Geschichte mit dem Moment, in dem die TXT-Records im DNS stehen und ein erster Test grün anzeigt. Für eine einzelne Firmen-Domain mit einem Mailserver mag das reichen. Für adressierten B2B-Outreach, bei dem Sie über Wochen mehrere Absender-Postfächer, oft mehrere Subdomains und mindestens ein bis zwei externe Versand- oder Tracking-Tools gleichzeitig betreiben, ist der Tag der Einrichtung nur der Startpunkt.

Jedes neue Tool, das in Ihrem Namen E-Mails verschickt oder DKIM signiert — ein neues CRM, ein Tracking-Dienst, ein zusätzliches Postfach bei einem anderen Anbieter — verändert die Ausgangslage. Ohne feste Prüfroutine bemerken Sie einen kaputten SPF-Eintrag oft erst daran, dass die Zustellrate über Wochen leise sinkt, nicht an einer klaren Fehlermeldung. Und weil Kaltakquise-Kampagnen naturgemäß in Wellen laufen — mal drei Postfächer aktiv, mal sieben, mal eine neue Subdomain im Aufbau —, ist die Ausgangslage bei jeder neuen Kampagne technisch eine leicht andere als bei der letzten.

Die Konsequenz daraus ist nicht, dass Sie täglich in den DNS schauen müssen. Es reicht, den Prüfaufwand an die Ereignisse zu koppeln, die die Konfiguration tatsächlich verändern, ergänzt um einen groben Grundrhythmus, der auch schleichende Probleme fängt, die niemand aktiv verursacht hat, etwa weil ein Drittanbieter seinen SPF-Include ohne Ankündigung erweitert.

Ein Beispiel aus der Praxis: Eine Musterfirma GmbH betreibt für ihre Kaltakquise drei Subdomains parallel, jede mit einem eigenen Set an Postfächern. Als ein neues Tracking-Tool hinzukam, fügte es automatisch einen eigenen SPF-Include hinzu — technisch korrekt, aber niemand hatte geprüft, ob die Gesamtzahl der Lookups dadurch das Limit überschreitet. Erst ein routinemäßiger MXToolbox-Check drei Wochen später deckte auf, dass zwei der drei Subdomains inzwischen permanent SPF-Fails produzierten.

Die Checkliste jenseits des Basis-Setups

Gehen wir davon aus, dass SPF, DKIM und DMARC grundsätzlich stehen. Was fortgeschrittene Teams zusätzlich prüfen, lässt sich in wenigen, aber wichtigen Punkten zusammenfassen — und genau die werden bei einer einmaligen Einrichtung fast immer übersehen, weil sie erst mit der Zeit und mit wachsender Infrastruktur relevant werden.

Keiner dieser Punkte ist beim ersten Setup zwingend falsch eingestellt. Sie werden mit der Zeit falsch, wenn niemand sie nachpflegt — meist schleichend, ohne dass ein einzelnes Ereignis den Fehler auslöst. Genau das macht sie gefährlicher als offensichtliche Konfigurationsfehler: Ein fehlendes DKIM-Signatur-Tag fällt sofort auf, ein langsam wachsender SPF-Include-Baum nicht.

• SPF-Lookup-Limit: Jeder include, a, mx, ptr oder exists-Mechanismus zählt gegen das Limit von zehn DNS-Lookups. Bei drei bis vier verketteten Includes für Versandtool, CRM, Tracking und Backup-MX ist das Limit schneller erreicht, als der Eintrag lang aussieht — eine Überschreitung führt zu einem permanenten SPF-Fail, unabhängig davon, wie korrekt der Rest aussieht.
• DKIM-Key-Rotation: Ein DKIM-Schlüssel, der seit der Einrichtung nie gewechselt wurde, ist ein Risiko, kein Komfort. Rotieren Sie Selektoren regelmäßig und entfernen Sie alte, ungenutzte Selektor-Records aus dem DNS, statt sie liegen zu lassen.
• DMARC-Alignment-Modus: strict (s) verlangt exakte Domain-Übereinstimmung zwischen der From-Adresse und dem SPF- beziehungsweise DKIM-Domain-Tag, relaxed (r) erlaubt Subdomains. Für Setups mit mehreren Sending-Subdomains ist relaxed meist praktikabler — das sollte aber eine bewusste Entscheidung sein, keine zufällige Voreinstellung.
• Mehrere DMARC- oder SPF-Records auf derselben Domain: Ein zweiter, versehentlich stehen gebliebener Record macht den gesamten Eintrag ungültig — Mail-Provider ignorieren dann DMARC beziehungsweise SPF komplett, ohne Sie darüber zu informieren.
• Subdomain-Policy (sp-Tag): Ohne explizite Subdomain-Policy erben neue Subdomains oft unbeabsichtigt eine laxere Regel als die Hauptdomain, was gerade bei rotierenden Kaltakquise-Subdomains zu Lücken führt.

ARC: wann Sie es wirklich brauchen

ARC (Authenticated Received Chain) bewahrt die ursprüngliche Authentifizierungskette, wenn eine E-Mail über einen Zwischenschritt läuft, der Header verändert — klassischerweise eine Mailingliste oder ein Weiterleitungsdienst. Ohne ARC verliert eine weitergeleitete Mail häufig ihre SPF-Gültigkeit, weil der weiterleitende Server nicht in Ihrem SPF-Eintrag steht, und DMARC schlägt fehl, obwohl die Mail ursprünglich sauber war. Der weiterleitende Server signiert dabei mit einem eigenen ARC-Set, das dem nächsten Empfänger zeigt, dass die ursprüngliche Authentifizierung bestanden hat, auch wenn SPF an dieser Stelle formal nicht mehr aligned ist.

Für direkten, adressierten B2B-Versand an einzelne Ansprechpartner ist ARC in der Praxis selten der entscheidende Hebel — Sie versenden ja nicht über Mailinglisten. Relevant wird es, wenn Empfänger Ihre Mails über Firmen-Gateways mit eigener Weiterleitungslogik empfangen, was bei größeren Zielunternehmen mit zentralem E-Mail-Filter oder Konzern-Weiterleitung durchaus vorkommt. Prüfen Sie ARC-Header daher eher reaktiv: Wenn ein bestimmter Empfängertyp — etwa Konzerne mit zentralem Postfach-Routing — auffällig oft nicht zustellbar ist, lohnt sich ein Blick, ob dessen Mailserver ARC auswertet und ob Ihre eigene Infrastruktur ARC-Sets überhaupt korrekt durchreicht.

Für die meisten Cold-Outreach-Setups reicht es, ARC im Hinterkopf zu behalten, ohne aktiv etwas dafür konfigurieren zu müssen — es ist in erster Linie ein Mechanismus, den empfangende Server auswerten, nicht etwas, das Sie als Absender selbst einrichten müssen, solange Ihre eigene Versandkette keine Weiterleitungen enthält.

Eine Ausnahme: Betreiben Sie selbst einen Relay- oder Warmup-Dienst, über den Mails vor dem eigentlichen Versand geleitet werden, sollten Sie prüfen, ob dieser Dienst ARC-Sets korrekt weiterreicht. Andernfalls tragen Sie das Risiko doppelt — einmal durch den Relay-Schritt selbst, der SPF-Alignment brechen kann, und einmal durch fehlende ARC-Absicherung, die diesen Bruch für den Empfänger nachvollziehbar machen würde.

BIMI: Logo im Posteingang — lohnt es sich für Kaltakquise-Domains?

BIMI (Brand Indicators for Message Identification) zeigt Ihr Firmenlogo neben der E-Mail im Posteingang unterstützter Clients an, sofern DMARC im Enforcement-Modus läuft, also mindestens auf p=quarantine mit ausreichendem pct-Wert steht, und ein SVG-Logo im vorgeschriebenen Format hinterlegt ist. Für viele Regionen und Provider ist zusätzlich ein Verified Mark Certificate (VMC) nötig — ein kostenpflichtiges Zertifikat, das Ihre Markenrechte am Logo bestätigt und in der Regel jährlich erneuert werden muss.

Für die Haupt-Markendomain eines Unternehmens kann BIMI ein sinnvoller Vertrauensanker sein: Empfänger sehen ein verifiziertes Logo statt eines generischen Avatars, was besonders bei Antwort-Kommunikation und wiederkehrendem Kontakt Vertrauen aufbaut. Für rotierende Sending-Subdomains im Kaltakquise-Versand ist der Aufwand meist unverhältnismäßig — Sie würden für jede Subdomain, die Sie aus Zustellbarkeitsgründen ohnehin gelegentlich wechseln, erneut DMARC-Enforcement und im Zweifel ein eigenes Zertifikat pflegen, für eine Domain, die möglicherweise nach wenigen Monaten wieder ausgetauscht wird.

Setzen Sie BIMI, wenn überhaupt, auf der Hauptdomain ein, über die Antworten laufen und mit der Empfänger langfristig in Kontakt bleiben — nicht auf der Wegwerf-Subdomain für den Erstkontakt. Die Reihenfolge ist dabei wichtig: Ohne stabile DMARC-Policy im Enforcement-Modus lohnt sich der BIMI-Aufwand ohnehin nicht, sodass BIMI immer ein späterer Schritt ist, nie der erste.

Monitoring-Tools: MXToolbox und Co. im festen Rhythmus einsetzen

Ein SPF-DKIM-DMARC-Checker wie MXToolbox prüft in Sekunden, ob Ihre Records syntaktisch korrekt sind, ob das Lookup-Limit eingehalten wird und ob DMARC- und SPF-Records eindeutig sind. Der Wert solcher Tools liegt aber nicht im einmaligen grünen Haken, sondern darin, sie in eine wiederkehrende Prüfroutine einzubauen — gerade weil sich Ihre Sending-Infrastruktur bei laufendem Outreach ständig verändert und ein Fehler, der heute entsteht, oft erst Wochen später an sinkenden Zustellraten sichtbar wird.

In der Praxis hat sich für Teams mit mehreren aktiven Sending-Domains ein einfacher Rhythmus bewährt: ein SPF-DKIM-DMARC-Test unmittelbar nach jeder Änderung an der Mail-Infrastruktur (neues Tool, neues Postfach, neue Subdomain), plus ein routinemäßiger Check unabhängig von Änderungen, um schleichende Probleme wie ein überschrittenes Lookup-Limit oder einen vergessenen Doppel-Record zu fangen. Ein solcher Test kostet wenige Minuten, verhindert aber genau die Art von stillem Zustellbarkeitsverlust, die im Nachhinein am schwersten zu diagnostizieren ist, weil auf den ersten Blick alles wie gewohnt aussieht.

Praktische Checkliste für den Prüfrhythmus

Fassen wir die Praxis in eine Routine, die sich unabhängig von der Anzahl Ihrer Sending-Domains einhalten lässt. Sie muss nicht aufwendig sein — entscheidend ist, dass sie überhaupt stattfindet und nicht von der Erinnerung eines Einzelnen abhängt.

Wer diese Punkte in einen wiederkehrenden Kalendereintrag oder eine Checkliste vor jedem Kampagnenstart überführt, verhindert die meisten der oben beschriebenen Probleme, bevor sie überhaupt Zustellbarkeit kosten.

• Nach jeder Infrastruktur-Änderung: SPF-, DKIM- und DMARC-Test über einen Checker wie MXToolbox, insbesondere Lookup-Zahl und Record-Eindeutigkeit.
• Monatlich: Stichprobe der DMARC-Aggregatberichte auf neue, unbekannte sendende IPs oder fehlgeschlagene Alignments.
• Bei jedem neuen Versandtool: SPF-Include und DKIM-Selektor sofort dokumentieren, nicht erst bei Problemen suchen.
• Halbjährlich: DKIM-Key-Rotation für aktiv genutzte Selektoren, alte Selektoren aus dem DNS entfernen.
• Vor jedem größeren BIMI- oder Enforcement-Schritt: Prüfen, ob die betroffene Domain wirklich langfristig genutzt wird oder eine Wegwerf-Subdomain ist.

Häufige Fragen