Wenn die Zustellung plötzlich schwankt, Support-Tickets wegen “keine Mail angekommen“ steigen oder Kampagnen auffällig oft im Spam landen, liegt die Ursache häufig nicht im Inhalt, sondern in fehlender oder inkonsistenter Authentifizierung. Moderne Mailanbieter bewerten Absender deutlich strenger als noch vor ein paar Jahren. In diesem Artikel bekommen Sie einen praxisnahen Ablauf, wie Sie Absenderquellen sauber erfassen, DNS-Records richtig setzen, Ergebnisse testen und anschließend Schritt für Schritt auf eine stabile Policy hinarbeiten.
Warum E-Mail-Authentifizierung wichtig ist
E-Mails sind für Angreifer ein leichtes Ziel, weil der sichtbare Absender ohne technische Gegenmaßnahmen relativ einfach gefälscht werden kann. E-Mail-Spoofing verhindern ist deshalb nicht nur ein Security-Thema, sondern wirkt direkt auf Zustellbarkeit, Reputation und Markenvertrauen.
Fehlt die Authentifizierung, passieren in der Praxis drei Dinge besonders häufig. Erstens sinkt die Inbox-Quote, weil Provider vorsichtiger filtern. Zweitens steigt das Risiko, dass Dritte Ihre Domain für Phishing missbrauchen. Drittens werden Fehler schwerer zu debuggen, weil es keine klaren Signale gibt, welcher Versandweg sauber arbeitet und welcher nicht.
Bereit für 2026: Neue Absenderanforderungen großer Mailanbieter
Die Richtung ist klar: Die Anforderungen an Absender werden strenger, besonders bei höheren Versandvolumina und bei Domains, die aus Sicht eines Providers “neu“ oder “auffällig“ wirken. Das bedeutet im Alltag weniger Spielraum für halb fertige Setups und mehr Bedarf an sauberem Reporting.
Was praktisch wichtig wird:
- Konsistente Authentifizierung über alle Versandwege hinweg, nicht nur für Newsletter
- Klarer Überblick über jede Quelle, die im Namen Ihrer Domain sendet
- Ein stufenweiser Rollout statt harter Policies am ersten Tag
- SPF und DKIM als Mindestbasis, bevor Sie schärfer steuern
Was ist SPF (Sender Policy Framework)?
SPF definiert, welche Server berechtigt sind, E-Mails im Namen Ihrer Domain zu versenden. Technisch ist das ein DNS-TXT-Eintrag, den empfangende Systeme abfragen, um den Versandweg zu bewerten. Wenn eine Mail von einer nicht autorisierten Quelle kommt, steigt das Risiko für Spam-Einstufung oder Ablehnung deutlich.
Der wichtigste Punkt dabei ist nicht “SPF existiert“, sondern “SPF ist vollständig und eindeutig“. SPF im DNS muss so gepflegt sein, dass jede legitime Versandquelle erfasst ist und es keine widersprüchlichen Einträge gibt.
Was ist DKIM (DomainKeys Identified Mail)?
DKIM signiert E-Mails kryptografisch. Das sendende System erzeugt eine Signatur mit einem privaten Schlüssel, während der öffentliche Schlüssel im DNS veröffentlicht wird. Beim Empfang kann der Provider prüfen, ob die Signatur gültig ist und ob Inhalte unterwegs verändert wurden.
Viele Teams erkennen den Eintrag im DNS daran, dass er unter einem Selector liegt und als DKIM-Record auftaucht. In der Praxis ist DKIM besonders wertvoll, weil es auch bei manchen Weiterleitungs-Szenarien stabilere Signale liefern kann als reine IP-basierte Prüfungen.
Was ist DMARC (Domain-based Message Authentication, Reporting and Conformance)?
DMARC ist der Steuerhebel. Es baut auf SPF und DKIM auf, bewertet deren Ergebnisse und verlangt zusätzlich Alignment, also dass die geprüften Domains zur sichtbaren Absenderdomain passen. DMARC liefert außerdem Reports, mit denen Sie sehen, wer tatsächlich in Ihrem Namen sendet.
Für den Einstieg gilt: DMARC einrichten sollte als Prozess verstanden werden, nicht als Einmalaktion. Sie starten mit Beobachtung, werten Reports aus und verschärfen erst dann schrittweise.
Wie greifen SPF, DKIM und DMARC zusammen?
DMARC entscheidet nicht nur, ob SPF oder DKIM irgendwo “Pass“ melden, sondern ob die Ergebnisse zur Absenderdomain passen. Genau hier kommt Alignment ins Spiel, das viele Stolpersteine erklärt, etwa bei mehreren Subdomains, externen Versanddiensten oder umgebauten Return-Path-Konfigurationen.
In der Praxis sind DMARC und DKIM oft der Bereich, in dem ein Setup “fast richtig” aussieht, aber trotzdem instabil bleibt, weil zwar signiert wird, jedoch nicht mit der Domain, die für DMARC relevant ist. Wer hier sauber arbeitet, bekommt deutlich reproduzierbarere Ergebnisse.
Vorteile für Zustellbarkeit und Markenschutz
Gute Authentifizierung zahlt sich doppelt aus. Einerseits verbessern sich Inbox-Chancen, andererseits sinkt der Spielraum für Missbrauch. Das merkt man nicht immer am ersten Tag, aber über Wochen sehr deutlich.
Ein realistischer Vorher-Nachher-Vergleich aus der Praxis arbeitet mit Indikatoren statt Versprechen:
- Spam-Rate: sinkt oft, wenn legitime Quellen konsistent bestehen
- Bounce-Rate: stabilisiert sich, wenn Policies und Versandwege sauber sind
- Supportaufwand: weniger Fälle von “Mail fehlt” und weniger Blocklisten-Überraschungen
Ein einfaches Beispiel: Wenn eine Domain bei Kampagnen anfangs 8 Prozent Spam-Rate sieht und nach Stabilisierung auf 3 Prozent fällt, ist das ein spürbarer Effekt, ohne dass Inhalte oder Zielgruppen geändert wurden. Außerdem reduziert sich das Risiko, dass Betrüger Ihre Domain als Absender missbrauchen.
DKIM und DMARC sind dabei häufig der Schritt, der aus “ein bisschen besser” ein wirklich kontrollierbares System macht, weil Signatur und Policy zusammen deutlich weniger Interpretationsspielraum lassen.
Einschränkungen und typische Stolpersteine von SPF und DKIM
SPF und DKIM lösen nicht jedes Problem automatisch. SPF ist empfindlich bei Weiterleitungen, weil die sendende IP sich ändern kann. DKIM scheitert oft nicht an Kryptografie, sondern an kleinen Konfigurationsdetails wie falschen Selectors oder daran, dass eine Quelle schlicht nicht signiert ist.
Weitere typische Stolpersteine:
- mehrere Versandquellen, aber nur eine im Record erfasst
- DNS-Änderungen wurden gesetzt, aber nie getestet
- zu viele SPF-Lookups durch unkontrollierte Include-Ketten
- DKIM-Signatur fehlt in bestimmten Versandwegen, etwa Website-Formularen oder Support-Tools
Vorbereitung vor der Einrichtung
Bevor Sie Records setzen, brauchen Sie eine vollständige Liste aller Quellen, die im Namen Ihrer Domain senden. Ohne diese Inventarliste ist jede Policy später riskant.
Sammeln Sie mindestens:
- Mailserver oder Hosting-Mail
- Newsletter-Versand
- CRM oder Sales-Automation
- Support-System und Ticketing
- Website-Formulare und transaktionale Mails
- Monitoring, Alerts, interne Systeme
- Integrationen, die im Hintergrund verschicken
Wenn die Liste steht, können Sie den nächsten Schritt sauber planen. SPF-Record erstellen ist dann nicht mehr Rätselraten, sondern eine nachvollziehbare Abbildung Ihrer realen Versandlandschaft.
SPF einrichten: Absenderquellen bündeln und SPF-Record erstellen
SPF ist am stärksten, wenn er vollständig, eindeutig und verständlich bleibt. Ein guter Ablauf ist:
- Quellen zuordnen
Jede Quelle bekommt einen Owner im Team. Das klingt banal, verhindert aber, dass später “irgendwer” etwas ändert und niemand weiß, warum. - Struktur bauen
Ein SPF-Eintrag beginnt typischerweise mit v=spf1. Danach folgen Mechanismen wie ip4, ip6, mx und häufig include für externe Dienstleister. Am Ende steht ein Qualifier wie ~all oder -all, je nachdem, wie strikt Sie sein wollen. - Erst testen, dann härter werden
Für den Start ist ein sanfterer Ansatz oft sinnvoll, solange Sie noch Quellen finden und korrigieren. Zu harte Einstellungen am ersten Tag führen schnell zu legitimen Bounces. - Klassische Fehler vermeiden
Doppelte SPF-Einträge im DNS, vergessene Quellen und zu viele DNS-Lookups sind die häufigsten Ursachen für unerwartete Ergebnisse.
Als kurze Faustregel: Wenn Ihr SPF-Eintrag ständig wächst, ist das ein Signal, dass Sie zu viele Quellen parallel nutzen oder dass ein Dienstleister zu viele verschachtelte Includes mitbringt.
SPF einrichten gelingt am zuverlässigsten, wenn Sie nach jeder Änderung eine Testmail aus genau dem Versandweg senden, den Sie gerade abgesichert haben.
DKIM einrichten: DKIM-Eintrag erstellen und Signatur aktivieren
DKIM wird in vielen Systemen direkt im Versandtool oder im Control Panel aktiviert. Danach erhalten Sie den Selector und den öffentlichen Key, der als TXT in DNS veröffentlicht wird.
Ein stabiler Ablauf:
- DKIM im jeweiligen Versandweg einschalten
Bei Newsletter, Support, CRM und Transaktionsmails separat prüfen. Viele Teams aktivieren DKIM im Hauptsystem, vergessen aber Website-Formulare oder eine alte CRM-Integration. - Selector sauber dokumentieren
Der Selector ist im Alltag wichtig, weil er es erlaubt, Keys zu rotieren oder mehrere Quellen parallel zu betreiben. - DNS-Eintrag exakt setzen
Copy-Paste-Fehler sind hier Klassiker. Achten Sie auf abgeschnittene Strings, unerwartete Leerzeichen oder Zeilenumbrüche aus UIs. - Testmail senden und Header prüfen
Suchen Sie in den Headern nach Authentication-Results und nach der DKIM-Signatur.
DKIM einrichten heißt operativ vor allem: jede echte Versandquelle muss wirklich signieren, nicht nur “theoretisch aktiviert“ sein.
Wenn Sie an dieser Stelle zum ersten Mal arbeiten, hilft eine klare Mikro-Aufgabe. DKIM-Eintrag erstellen gehört dann zu den wenigen Änderungen, die Sie bewusst einzeln setzen, testen und erst danach zusammenführen.
DMARC einrichten: Policy starten, Reports lesen und schrittweise verschärfen
DMARC sollte man in Stufen einführen, damit legitime Quellen nicht aus Versehen ausgesperrt werden. Ein bewährtes Vorgehen:
- Start mit p=none
Sie sammeln Reports, ohne dass Mails abgewiesen werden. Das ist die Phase, in der Sie versteckte Versandwege entdecken. - Reports lesen und Quellen bereinigen
Sie sehen, welche Systeme bestehen und welche nicht. Unbekannte Quellen sind oft alte Tools, vergessene Integrationen oder Drittanbieter, die nie dokumentiert wurden. - Umstieg auf p=quarantine
Wenn die wichtigsten Quellen sauber bestehen, verschieben Sie nicht bestandene Mails eher in den Spam. Das ist ein realistischer Zwischenschritt. - Später p=reject
Erst wenn Reports stabil sind und legitime Quellen zuverlässig bestehen, wird p=reject sinnvoll. Dann sind Spoofing-Versuche deutlich schwerer.
Für einen realistischen Zeitplan rechnen viele Teams mit zwei bis sechs Wochen von p=none bis zu einer strengeren Policy, abhängig davon, wie viele Versandwege existieren und wie schnell Fachbereiche reagieren.
SPF, DKIM und DMARC prüfen und testen
Nach DNS-Änderungen gilt: erst die Propagation abwarten, dann testen. Arbeiten Sie dabei systematisch:
- Testmails aus jedem Versandweg senden, nicht nur aus einem
- Header öffnen und Authentication-Results prüfen
- bei Problemen zuerst DNS-Einträge verifizieren, dann Alignment und Signatur prüfen
- Änderungen einzeln durchführen, damit Ursache und Effekt nachvollziehbar bleiben
Als Beispiele für Checks eignen sich Tools wie MXToolbox, mail-tester und Google Postmaster Tools. Nutzen Sie sie als Kontrollinstrument, nicht als Ersatz für saubere Inventarisierung Ihrer Quellen.
Typische Fehler bei der Einrichtung und wie man sie vermeidet
Die häufigsten Fehler lassen sich auf wenige Muster reduzieren:
- nicht alle Quellen erfasst, besonders Formulare und Support-Systeme
- SPF mehrfach im DNS gesetzt oder zu viele Lookups produziert
- DKIM aktiviert, aber Signatur fehlt in bestimmten Versandwegen
- DMARC zu früh zu hart, bevor Reports verstanden sind
- Reporting nicht ausgewertet, dadurch bleiben Lücken unsichtbar
- Alignment nie geprüft, obwohl SPF oder DKIM scheinbar “Pass” melden
Ein guter Schutz ist einfache Disziplin: Änderung, Testmail, Header-Check, Dokumentation. Danach erst der nächste Schritt.
Checkliste: Sind SPF, DKIM und DMARC korrekt aktiv
- SPF ist vorhanden und es gibt genau einen gültigen Eintrag
- alle legitimen Versandquellen sind abgedeckt
- keine unkontrollierten Include-Ketten, Lookups bleiben im Rahmen
- DKIM-Signatur ist im Header sichtbar
- Selector passt, Key ist vollständig und korrekt
- DMARC-Record ist vorhanden und syntaktisch sauber
- Reporting läuft und wird tatsächlich gelesen
- Alignment ist geprüft, mindestens für die wichtigsten Versandwege
- Testmails bestehen zuverlässig aus allen Quellen
- Änderungen sind dokumentiert, inklusive Owner pro Versandweg
Wichtig: Reihenfolge beachten
Erst SPF stabilisieren, dann DKIM für alle Quellen aktivieren, danach DMARC mit p=none starten und Reports auswerten. Erst wenn die Ergebnisse stabil sind, schrittweise verschärfen. Wer die Reihenfolge umdreht, produziert unnötige Bounces, Supportaufwand und nervöse Fachbereiche.
BIMI als ergänzender Standard
BIMI ist kein Startpunkt. Es wird meist erst interessant, wenn DMARC stabil und ausreichend strikt ist. Dann kann BIMI helfen, die Markenwahrnehmung im Postfach zu verbessern. Technisch lohnt sich BIMI aber erst, wenn die Authentifizierungsbasis zuverlässig läuft.
DNS-Einstellungen sind nicht Ihr Ding
Wenn DNS-Änderungen Unsicherheit auslösen, holen Sie sich Unterstützung. Eine falsche Zeile kann im Worst Case den legitimen Versand unterbrechen. Dokumentieren Sie Versandquellen, testen Sie Änderungen mit echten Mails und arbeiten Sie mit klaren Verantwortlichkeiten. Das spart am Ende Zeit, auch wenn es am Anfang nach “mehr Prozess“ aussieht.
Ihre nächsten Schritte
Sammeln Sie Versandquellen, stabilisieren Sie SPF, aktivieren Sie DKIM in jedem Versandweg und starten Sie DMARC mit Reporting. Prüfen Sie Reports regelmäßig, schließen Sie Lücken und erhöhen Sie die Policy erst, wenn die wichtigsten Quellen zuverlässig bestehen. So wird Zustellbarkeit planbar und Ihre Domain deutlich besser gegen Missbrauch geschützt.
Häufig gestellte Fragen
Reichen SPF und DKIM ohne DMARC aus?
Als Basis helfen beide, aber ohne DMARC fehlen die steuerbare Policy und das strukturierte Reporting. Damit bleibt Missbrauch schwerer kontrollierbar und Fehleranalyse dauert länger. In der Praxis ist DMARC der Teil, der aus einzelnen Prüfungen ein System macht.
Was passiert bei DMARC, wenn SPF oder DKIM fehlschlagen?
Das hängt von der Policy ab. Bei p=none wird meist nur berichtet. Bei p=quarantine steigt die Wahrscheinlichkeit, dass die Mail im Spam landet. Bei p=reject wird sie abgewiesen. Deshalb ist ein stufenweiser Rollout sinnvoll.
Wo sehe ich, ob SPF, DKIM und DMARC bestanden wurden?
Öffnen Sie den Mail-Header einer Testmail und suchen Sie nach Authentication-Results. Dort sehen Sie typischerweise Pass oder Fail und oft auch Hinweise auf Alignment. Danach korrigieren Sie den DNS, die Signatur oder die Absenderkonfiguration des jeweiligen Versandwegs.
Warum landen E-Mails trotz korrektem SPF im Spam?
Häufig gibt es mehrere Versandwege, die nicht alle abgesichert sind, oder die Domain-Reputation ist schwach. Auch Inhalte, ungewöhnliche Versandspitzen oder fehlendes Alignment können eine Rolle spielen. Starten Sie mit der Header-Analyse, prüfen Sie dann die Quelle, die Signatur und die tatsächliche Absenderdomain.
Wann sollte ich von p=none auf p=quarantine oder p=reject wechseln?
Wenn Reports zeigen, dass legitime Quellen zuverlässig bestehen und keine unbekannten Absender mehr auftauchen, ist der Schritt zur Quarantäne sinnvoll. Reject kommt erst, wenn Sie sicher sind, dass keine wichtigen Mails durch Konfigurationslücken betroffen sind. In vielen Teams ist das eher ein kontrollierter Prozess über Wochen als eine Änderung an einem Nachmittag.