SPF, DKIM und DMARC erklärt: Unterschiede, Zusammenhänge & Praxisbeispiele

E-Mail wurde in den 1980er-Jahren entworfen, ohne dass irgendjemand an Absenderfälschung gedacht hätte – das From:-Feld einer Nachricht lässt sich bis heute technisch frei setzen, so wie ein Blatt Papier keine Herkunftsgarantie für die Unterschrift darüber bietet. Genau diese Lücke nutzen Phishing-Kampagnen und CEO-Fraud-Betrug seit Jahrzehnten aus. SPF, DKIM und DMARC sind die drei DNS-basierten Verfahren, mit denen sich diese Lücke heute weitgehend schließen lässt – aber nur, wenn man versteht, dass sie unterschiedliche Dinge prüfen und erst im Zusammenspiel wirklich schützen. Wer nur SPF einrichtet und DMARC vergisst, hat in der Praxis kaum etwas gewonnen. Dieser Beitrag erklärt jedes Verfahren einzeln, zeigt an konkreten Beispielen, wie sie voneinander abhängen, und begleitet Sie durch einen sicheren Rollout ohne Zustellrisiko.

Das Grundproblem: SMTP vertraut niemandem – und genau das ist der Fehler

Das Simple Mail Transfer Protocol (SMTP) überträgt eine E-Mail in mehreren Schritten, und keiner davon prüft von Haus aus, ob der angegebene Absender tatsächlich berechtigt ist, im Namen einer Domain zu senden. Beim Verbindungsaufbau nennt der sendende Server im MAIL FROM-Kommando eine sogenannte Envelope-From-Adresse (auch Return-Path genannt) – das ist die Adresse, an die Zustellfehler (Bounces) zurückgehen. Im Nachrichtenkopf selbst steht zusätzlich ein für den Empfänger sichtbares From:-Feld, das im Posteingang angezeigt wird. Beide Felder können komplett unterschiedliche Domains enthalten, und ohne zusätzliche Prüfung glaubt der empfangende Mailserver beides anstandslos. Ein Angreifer kann also eine E-Mail verschicken, die im Posteingang als „buchhaltung@ihre-firma.de“ erscheint, obwohl sie technisch von einem völlig fremden Server irgendwo auf der Welt stammt. SPF, DKIM und DMARC setzen an genau dieser Stelle an – jedes an einer anderen.

SPF (Sender Policy Framework): Wer darf im Namen der Domain senden?

SPF beantwortet eine einzige, sehr konkrete Frage: Ist die IP-Adresse, von der diese E-Mail gerade kommt, für den Versand im Namen dieser Domain autorisiert? Dazu veröffentlicht die Domain-Inhaberin einen öffentlich abrufbaren TXT-Record im eigenen DNS, der alle autorisierten Absender-Systeme auflistet. Ein typischer SPF-Record sieht so aus:

ihre-firma.de.  TXT  "v=spf1 mx ip4:203.0.113.10 include:_spf.google.com include:sendgrid.net -all"

Jeder Baustein dieses Records ist ein Mechanism: mx erlaubt allen Servern, die als MX-Record der Domain eingetragen sind; ip4:203.0.113.10 erlaubt explizit eine einzelne IPv4-Adresse, etwa den eigenen Mailserver; include:_spf.google.com bindet den SPF-Record eines Drittanbieters ein – hier Google Workspace – und übernimmt dessen gesamte IP-Liste; include:sendgrid.net tut dasselbe für einen Transaktionsmail-Dienst. Am Ende steht ein Qualifier: -all (Fail) weist empfangende Server an, alle nicht gelisteten IPs strikt abzulehnen, ~all (SoftFail) markiert sie nur als verdächtig, ohne sie zu blockieren, und ?all (Neutral) trifft praktisch keine Aussage – für produktive Domains ist -all nach einer sauberen Testphase das Ziel. Wichtig für die Praxis: SPF erlaubt maximal 10 DNS-Lookups pro Prüfung (jedes include, a, mx und ptr zählt), wird dieses Limit überschritten, gilt die gesamte Prüfung als permerror und damit faktisch als fehlgeschlagen – ein Grund, warum SPF-Records mit vielen verschachtelten Includes (z. B. Marketing-Tool, CRM, Helpdesk, Rechnungssoftware, jeweils mit eigenem Include) schnell an ihre Grenze stoßen und regelmäßig mit einem SPF-Flattening-Tool geprüft werden sollten.

Die entscheidende Schwäche von SPF: Es prüft ausschließlich die unsichtbare Envelope-From-Adresse, nicht das im Posteingang angezeigte From:-Feld. Außerdem bricht SPF fast immer bei klassischen E-Mail-Weiterleitungen, weil der weiterleitende Server die Nachricht unverändert mit der ursprünglichen Envelope-From-Adresse an den nächsten Empfänger sendet – dessen Server sieht dann eine fremde IP, die nicht im SPF-Record der Ursprungsdomain steht, und wertet das als Fail, obwohl die Mail völlig legitim ist. Genau diese beiden Lücken sind der Grund, warum SPF allein niemals ausreicht.

DKIM (DomainKeys Identified Mail): Ist die Nachricht unterwegs verändert worden?

DKIM beantwortet eine andere Frage: Wurde diese Nachricht wirklich von einem autorisierten System dieser Domain versendet, und ist sie seither unverändert? Dazu wird jede ausgehende E-Mail mit einem privaten kryptografischen Schlüssel digital signiert. Der zugehörige öffentliche Schlüssel liegt als TXT-Record unter einem sogenannten Selector im DNS, zum Beispiel:

mail2026._domainkey.ihre-firma.de.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7v..."

Der Selector (hier mail2026) erlaubt es, mehrere Schlüssel parallel zu betreiben – etwa einen für den eigenen Mailserver und einen weiteren für einen Newsletter-Dienstleister – und Schlüssel unabhängig voneinander zu rotieren, ohne den Mailversand zu unterbrechen. Wer die eigene Domain bei einem DNS-Hoster mit REST-API verwaltet – etwa bei unserem eigenen Dienst N24DNS –, kann diese Selector-Rotation sogar per Skript automatisieren, statt jeden neuen Schlüssel manuell im Webinterface des Registrars einzutragen. Beim Versand berechnet der sendende Server einen kryptografischen Hash über ausgewählte Header (z. B. From, Subject, Date) sowie den Nachrichtenkörper, verschlüsselt diesen Hash mit dem privaten Schlüssel und hängt das Ergebnis als DKIM-Signature-Header an die Mail an. Der empfangende Server holt sich den öffentlichen Schlüssel über den im Header genannten Selector aus dem DNS, entschlüsselt die Signatur und vergleicht sie mit einem selbst berechneten Hash der empfangenen Nachricht – stimmen beide überein, ist bewiesen, dass Absender-Domain und Inhalt seit der Signierung unverändert sind. Weil diese Prüfung unabhängig von der sendenden IP-Adresse funktioniert, übersteht DKIM die meisten E-Mail-Weiterleitungen – solange der weiterleitende Server die signierten Header und den Body nicht verändert (manche Mailinglisten-Software hängt Fußzeilen an und bricht dadurch selbst die DKIM-Signatur, das ist ein bekanntes Nebenproblem). Genau diese Robustheit macht DKIM zur wichtigeren der beiden Bausteine, wenn man sich für nur einen entscheiden müsste – was, wie der nächste Abschnitt zeigt, trotzdem nicht die empfohlene Lösung ist.

DMARC: Der Baustein, der SPF und DKIM erst zusammenführt

Hier schließt sich der Kreis: DMARC (Domain-based Message Authentication, Reporting and Conformance) prüft weder Absender-IPs noch Signaturen selbst – es definiert Regeln, wie SPF- und DKIM-Ergebnisse gegen das sichtbare From:-Feld ausgewertet werden, und was bei einem Fehlschlag passieren soll. Auch DMARC ist ein TXT-Record, allerdings unter einem festen Unterdomain-Namen:

_dmarc.ihre-firma.de.  TXT  "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@ihre-firma.de; adkim=s; aspf=r"

Der zentrale Begriff dabei ist Alignment: Damit eine E-Mail DMARC besteht, muss mindestens eines der beiden Verfahren nicht nur technisch erfolgreich sein, sondern seine geprüfte Domain muss auch zur sichtbaren From-Domain passen. Bei SPF-Alignment vergleicht DMARC die Envelope-From-Domain mit der From:-Header-Domain; bei DKIM-Alignment die im d=-Tag der DKIM-Signatur genannte Domain mit derselben From:-Header-Domain. Beide Alignment-Arten kennen zwei Modi: relaxed (r, Standard) akzeptiert auch Subdomains – newsletter.ihre-firma.de aligned dann mit ihre-firma.de –, während strict (s) eine exakte Domain-Übereinstimmung verlangt. Entscheidend für das Verständnis der Abhängigkeiten: Es müssen nicht beide Verfahren gleichzeitig bestehen. Es genügt, wenn SPF oder DKIM erfolgreich prüft und aligned ist – DMARC verknüpft die beiden also mit einem logischen ODER, nicht mit einem UND. Das ist zugleich die praktische Stärke von DMARC: Fällt SPF bei einer Weiterleitung aus, rettet eine aligned DKIM-Signatur die Zustellung trotzdem.

Die p=-Direktive legt die Policy fest, die empfangende Mailserver bei einem DMARC-Fail anwenden sollen: p=none stellt die Mail normal zu und dient nur der Beobachtung, p=quarantine bittet den Empfänger, die Mail in den Spam-/Junk-Ordner zu verschieben, und p=reject weist den Empfänger an, die Zustellung komplett zu verweigern. Der optionale pct=-Wert erlaubt eine graduelle Einführung – pct=25 wendet die Policy nur auf ein Viertel der fehlschlagenden Mails an, der Rest wird vorerst weiter normal behandelt. Über rua= (aggregate reports) erhält die Domain-Inhaberin täglich maschinenlesbare XML-Zusammenfassungen aller SPF-/DKIM-/DMARC-Ergebnisse über alle beobachteten Versandquellen hinweg – die wichtigste Datenquelle für einen sicheren Rollout, dazu mehr im nächsten Abschnitt. Der seltener genutzte ruf=-Parameter (forensic reports) liefert Kopien einzelner fehlgeschlagener Nachrichten, wird aus Datenschutzgründen von vielen großen Providern inzwischen aber gar nicht mehr verschickt.

Praxisbeispiel 1: Eigener Mailserver plus externer Newsletter-Versender

Ein mittelständisches Unternehmen versendet Rechnungen über den eigenen Mailserver und den monatlichen Newsletter über einen Drittanbieter wie Brevo oder Mailchimp – beide Male mit der Absenderadresse info@ihre-firma.de. Ohne SPF-Include für den Newsletter-Dienst würde SPF bei jeder Newsletter-Mail fehlschlagen, weil sie von einer fremden IP kommt. Die Lösung ist ein zusätzlicher include:-Mechanism im SPF-Record für den Dienstanbieter (die genaue Include-Domain liefert jeder seriöse Anbieter in der eigenen Dokumentation). Noch robuster: Die meisten Newsletter-Dienste bieten Custom-DKIM-Signing an – dabei wird ein eigener Selector und Schlüssel für den Dienst im DNS der Kundendomain hinterlegt, sodass die Newsletter-Mail mit d=ihre-firma.de statt mit der Domain des Versanddienstes signiert wird. Damit aligned die DKIM-Prüfung korrekt, selbst wenn der SPF-Include aus irgendeinem Grund einmal fehlschlägt – ein gutes Beispiel dafür, warum DMARC mit seinem ODER-Prinzip aus zwei potenziell brüchigen Einzelprüfungen ein robustes Gesamtergebnis macht.

Praxisbeispiel 2: E-Mail-Weiterleitung an ein privates Postfach

Eine Mitarbeiterin leitet ihre geschäftliche E-Mail automatisch an ein privates Gmail-Konto weiter. Eine an mitarbeiterin@ihre-firma.de gesendete, korrekt signierte Rechnung wird vom Firmen-Mailserver unverändert an Gmail weitergereicht. Gmail sieht dabei die IP des weiterleitenden Firmenservers – nicht die des ursprünglichen Absenders –, wodurch die SPF-Prüfung für die ursprüngliche Absenderdomain fast zwangsläufig fehlschlägt. Die DKIM-Signatur des ursprünglichen Absenders bleibt dabei aber in aller Regel intakt, weil der Firmen-Mailserver Header und Body nicht verändert hat – Gmail kann die Signatur weiterhin gegen den öffentlichen Schlüssel im DNS des Originalabsenders prüfen und die Mail über die aligned DKIM-Signatur trotz SPF-Fail als authentisch einstufen. Große Empfänger wie Gmail und Microsoft 365 unterstützen inzwischen zusätzlich ARC (Authenticated Received Chain), das die ursprünglichen Authentifizierungsergebnisse kryptografisch signiert an nachgelagerte Weiterleitungen weiterreicht – ein Detail, das die grundsätzliche Lehre aus diesem Beispiel aber nicht verändert: Bei Weiterleitungen ist DKIM der verlässlichere der beiden Mechanismen.

Schritt-für-Schritt: Sicherer Rollout ohne Zustellrisiko

Die häufigste Ursache für gescheiterte DMARC-Einführungen ist Eile: Wer direkt mit p=reject startet, riskiert, dass legitime, bislang unentdeckte Versandquellen – ein CRM, ein Ticketsystem, eine Buchhaltungssoftware – plötzlich komplett blockiert werden. Der folgende Ablauf minimiert dieses Risiko:

1. SPF-Record erfassen und veröffentlichen: Alle tatsächlich genutzten Versandquellen identifizieren (eigener Mailserver, Newsletter-Tool, CRM, Buchhaltung, Support-System) und als ip4- oder include-Mechanism im SPF-Record eintragen, zunächst mit ~all statt -all, um Fehlkonfigurationen nicht sofort hart abzulehnen.
2. DKIM je Versandquelle aktivieren: Für den eigenen Mailserver einen 2048-Bit-RSA-Schlüsselsatz generieren und den öffentlichen Schlüssel unter einem eindeutigen Selector im DNS veröffentlichen; für jeden Drittanbieter dessen Custom-DKIM-Signing-Funktion aktivieren, damit alle Mails mit d=ihre-firma.de signieren, nicht mit der Anbieter-Domain.
3. DMARC auf p=none starten: Einen DMARC-Record mit p=none und einer funktionierenden rua=-Adresse veröffentlichen. In dieser Phase passiert zustellseitig nichts, aber jeder teilnehmende Empfänger-Mailserver sendet tägliche Aggregatberichte.
4. Berichte mindestens zwei bis drei Wochen auswerten: Die rohen XML-Reports sind für Menschen kaum lesbar – ein DMARC-Report-Analyzer (z. B. dmarcian, Postmark DMARC Monitor oder ein selbstgehostetes Tool wie parsedmarc) fasst sie in eine Übersicht nach sendender IP, Volumen sowie SPF-/DKIM-Ergebnis zusammen. Ziel ist, jede legitime IP zu identifizieren, die noch nicht im SPF-Record steht oder nicht aligned signiert.
5. Lücken schließen, dann schrittweise verschärfen: Fehlende Quellen ergänzen, anschließend DMARC stufenweise über p=quarantine; pct=25, dann pct=100, dann p=reject anheben – mit jeweils erneuter Beobachtungsphase von einigen Tagen zwischen den Stufen.
6. Dauerhaft überwachen: Auch nach Erreichen von p=reject laufen die Aggregatberichte weiter – sie sind der früheste Indikator, wenn jemand versucht, die Domain für Phishing zu missbrauchen, oder wenn eine neue interne Anwendung ungeplant eigene E-Mails versendet.

Vergleichstabelle: SPF, DKIM und DMARC im direkten Vergleich

Tools zur Prüfung: Records selbst kontrollieren

Alle drei Records lassen sich ohne Zusatzsoftware direkt per Kommandozeile abfragen:

dig TXT ihre-firma.de +short
dig TXT mail2026._domainkey.ihre-firma.de +short
dig TXT _dmarc.ihre-firma.de +short

Für eine schnelle Gesamteinschätzung ohne eigene DNS-Kommandozeile bieten sich Web-Tools wie MXToolbox (SPF-, DKIM- und DMARC-Lookup mit Klartext-Erklärung jedes Mechanisms) und mail-tester.com an – Letzteres verschickt eine Test-Mail an eine generierte Adresse und bewertet Zustellbarkeit, SPF/DKIM/DMARC-Status sowie weitere Spam-Faktoren in einem einzigen Bericht. Für laufendes Monitoring über die einmalige Prüfung hinaus lohnen sich die kostenlosen Google Postmaster Tools (zeigen Zustellraten und Spam-Rate speziell für Gmail-Empfänger) sowie ein dedizierter DMARC-Report-Analyzer, der die täglichen rua-Berichte automatisch auswertet, statt sie manuell als XML-Anhang zu öffnen. Wenn schon der SPF-, DKIM- und DMARC-Rollout ansteht, lohnt sich außerdem ein Blick auf das DNS-Hosting selbst: Bietet der aktuelle Registrar keine komfortable TXT-Verwaltung oder gar API, lassen sich alle drei Record-Typen bei einem dedizierten DNS-Hoster oft deutlich schneller und mit besserer Versionierung pflegen – dazu mehr im Überblick zu unserem eigenen DNS-Hosting-Dienst N24DNS.

Häufige Stolperfallen in der Praxis

Ein wiederkehrender Fehler ist ein doppelter SPF-Record: Jede Domain darf laut Spezifikation nur einen einzigen v=spf1-TXT-Record besitzen – werden versehentlich zwei veröffentlicht (etwa weil ein neues Tool seinen eigenen Record statt eines zusätzlichen Include-Eintrags vorschlägt), werten viele Mailserver das Ergebnis als ungültig (permerror). Ebenso häufig ist das bereits erwähnte Überschreiten des 10-Lookup-Limits durch zu viele verschachtelte Includes – regelmäßig mit einem SPF-Flattening-Check kontrollieren. Bei DKIM ist die häufigste Falle eine zu kurze Schlüssellänge: 1024-Bit-Schlüssel gelten inzwischen als unsicher und werden von manchen Empfängern schwächer gewichtet, Standard sollte 2048 Bit sein. Bei DMARC schließlich unterschätzen viele Unternehmen, wie viele Schatten-IT-Versandquellen tatsächlich im Namen der Hauptdomain senden – von der Umfrage-Software über das Event-Tool bis zum Bewerbermanagementsystem – und stufen zu früh auf p=reject hoch, ohne die Aggregatberichte vollständig ausgewertet zu haben. Genau dafür existiert die mehrwöchige p=none-Beobachtungsphase im oben beschriebenen Rollout.

SPF sagt, wer senden darf. DKIM beweist, dass die Nachricht unverändert ist. DMARC entscheidet, was passiert, wenn beides nicht zusammenpasst – und genau das macht aus drei Einzelverfahren einen echten Schutz gegen Absenderfälschung.

Fazit & Checkliste

SPF, DKIM und DMARC lösen zusammen ein Problem, das keines der drei allein lösen kann: SPF ohne DMARC lässt sich über eine gefälschte sichtbare Absenderadresse umgehen, DKIM ohne DMARC wird von vielen Mailclients gar nicht sichtbar ausgewertet, und DMARC ohne SPF oder DKIM hat schlicht nichts, worauf es sein Alignment aufbauen könnte. Erst im Zusammenspiel – mit einem vollständigen SPF-Record, DKIM-Signierung für jede Versandquelle und einem schrittweise verschärften DMARC-Rollout – entsteht ein belastbarer Schutz, der sowohl Phishing im Namen der eigenen Domain verhindert als auch die eigene Zustellbarkeit bei Gmail, Microsoft 365 und anderen großen Providern spürbar verbessert, die DMARC-konforme Domains inzwischen bevorzugt behandeln. Die folgende Checkliste fasst den Rollout als Quick-Reference zusammen:

FAQ

Reicht SPF allein, um Absenderfälschung zu verhindern?
Nein. SPF prüft nur den unsichtbaren Envelope-From (Return-Path), nicht die im Postfach angezeigte From-Adresse. Ein Angreifer kann eine völlig SPF-konforme Mail mit gefälschter Absenderanzeige verschicken, solange DMARC mit strikter From-Alignment nicht aktiv ist.

Muss eine E-Mail SPF und DKIM gleichzeitig bestehen, damit DMARC sie akzeptiert?
Nein, es genügt, dass eines der beiden Verfahren besteht und zusätzlich zur sichtbaren From-Domain aligned ist. Beide zusammen zu haben erhöht aber die Zustellsicherheit erheblich, weil DKIM auch Weiterleitungen übersteht, bei denen SPF fast immer bricht.

Warum bricht SPF bei E-Mail-Weiterleitungen?
Weil der weiterleitende Server die Mail unverändert mit der ursprünglichen Envelope-From-Adresse an den nächsten Empfänger sendet, dessen IP aber nicht im SPF-Record der Ursprungsdomain steht. DKIM übersteht das meist, weil die Signatur über Header und Body berechnet wird und nicht von der sendenden IP abhängt.

Was bedeutet p=none in einem DMARC-Record?
p=none ist die Monitoring-Stufe: E-Mails werden trotz fehlgeschlagener Prüfung normal zugestellt, aber empfangende Mailserver senden aggregierte Berichte (rua) an die angegebene Adresse. Sie dient dazu, alle legitimen Versandquellen zu identifizieren, bevor auf quarantine oder reject umgestellt wird.

Wie lange dauert ein sicherer DMARC-Rollout auf p=reject?
Realistisch vier bis acht Wochen: mindestens zwei bis drei Wochen Beobachtung auf p=none, um seltene monatliche Versandquellen zu erfassen, danach ein schrittweiser Übergang über quarantine mit steigendem pct-Wert, bevor reject für die volle Domain aktiv wird.