SPF, DKIM und DMARC: E-Mail-Spoofing Schritt für Schritt verhindern

Kurz gesagt: SPF listet die Server auf, die für Ihre Domain E-Mails versenden dürfen, DKIM signiert jede Nachricht, und DMARC prüft, ob eines von beiden für die Domain in der sichtbaren Absenderadresse (From) besteht. Außerdem legt DMARC fest, was Empfänger mit durchgefallenen Mails tun sollen. Seit Februar 2024 verlangen Gmail und Yahoo von jedem Absender SPF oder DKIM und von Massenversendern SPF, DKIM und DMARC. Gmail setzt die Regeln seit November 2025 noch strenger durch. Veröffentlichen Sie genau einen SPF-Eintrag, aktivieren Sie DKIM bei jedem Dienst, der für Sie sendet, starten Sie DMARC mit p=none und Berichten und wechseln Sie zu p=quarantine oder p=reject, sobald Ihre legitimen Mails bestehen.

E-Mail wurde ohne jeden Nachweis des Absenders konzipiert. Jeder kann billing@yourcompany.com in die From-Zeile schreiben, und ohne Authentifizierungseinträge kann der empfangende Server nicht erkennen, dass die Adresse gefälscht ist. So funktionieren Rechnungsbetrug und Phishing in Ihrem Namen, und deshalb können auch Ihre echten Mails für Gmail verdächtig aussehen.

SPF, DKIM und DMARC lösen das Problem mit drei DNS-Einträgen. Dieser Leitfaden erklärt, wie sie zusammenspielen, was die großen Mailbox-Anbieter verlangen, wie unser kostenloser SPF- und DMARC-Checker Ihre Domain liest und wie Sie von „keine Einträge“ zu einer durchgesetzten Richtlinie kommen, ohne Ihre eigenen Mails zu blockieren.

Wie SPF, DKIM und DMARC zusammenarbeiten

Die Schwachstelle von SPF und DKIM allein ist die Zeile „Welche Domain geprüft wird“. Laut RFC 7208 prüft SPF die Identitäten MAIL FROM und HELO, die der Empfänger nie sieht. Ein Spoofer kann SPF für seine eigene Domain bestehen und trotzdem Ihre Domain im From anzeigen. DMARC schließt diese Lücke mit dem Alignment: Eine Nachricht besteht DMARC nur, wenn SPF oder DKIM für eine Domain besteht, die zur From-Domain passt (beim relaxed Alignment sind Subdomains derselben Organisation erlaubt).

SPF in einem Eintrag

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

Jedes include autorisiert die Server eines Anbieters; -all am Ende bedeutet, dass alles andere durchfällt. RFC 7208 definiert die Qualifier: - ist Fail, ~ ist Softfail („wahrscheinlich nicht autorisiert“), ? ist Neutral und + ist Pass. +all autorisiert das gesamte Internet und macht den Eintrag sinnlos.

DKIM in einem Eintrag

Ihr Mailanbieter signiert ausgehende Nachrichten mit einem privaten Schlüssel und gibt Ihnen einen öffentlichen Schlüssel, den Sie unter einem Selector veröffentlichen, zum Beispiel google._domainkey.example.com. Jeder sendende Dienst nutzt seinen eigenen Selector, sodass mehrere DKIM-Schlüssel gleichzeitig existieren können (RFC 6376).

DMARC in einem Eintrag

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

p ist die Richtlinie für die Domain, sp für Subdomains, und rua erhält tägliche Aggregatberichte der Empfänger. Sie zeigen, welche Server Mails als Ihre Domain gesendet haben und ob diese bestanden haben.

Der DMARC-Standard wurde 2026 aktualisiert

Im Mai 2026 veröffentlichte die IETF RFC 9989, das die ursprüngliche DMARC-Spezifikation RFC 7489 ablöst und DMARC auf den Standards Track hebt. Bestehende Einträge funktionieren weiter; der Versions-Tag bleibt v=DMARC1. Die wichtigsten Änderungen:

• pct entfällt. Laut RFC „wurde es meist nicht korrekt angewendet“. Ein neuer Tag t („testing“) ersetzt es: t=y bittet Empfänger, die Richtlinie nicht anzuwenden, ungefähr wie das frühere pct=0.
• np kommt hinzu, eine Richtlinie für nicht existierende Subdomains.
• rf und ri entfallen, und ein DNS-„Tree Walk“ ersetzt die Public Suffix List, um die Organisationsdomain zu finden.

Empfänger werden unterschiedlich schnell auf die neuen Regeln umsteigen, und Googles eigene Einrichtungsanleitung empfiehlt beim Rollout weiterhin pct. Die Verwendung von pct richtet keinen Schaden an, verlassen Sie sich aber nicht darauf als exakten Prozentwert.

Was Gmail und Yahoo verlangen

Beide Anbieter setzen ihre Absenderanforderungen seit Februar 2024 durch.

Quellen: Googles Richtlinien für Absender und Yahoos Best Practices für Absender. Google warnt, dass nicht authentifizierte Nachrichten „als Spam markiert oder mit einem 5.7.26-Fehler abgelehnt werden könnten“, und in den FAQ heißt es: „Ab November 2025 verschärft Gmail die Durchsetzung bei nicht konformem Traffic“, mit vorübergehenden und dauerhaften Ablehnungen. Dieselben FAQ empfehlen, DMARC sowohl mit SPF als auch mit DKIM abzustimmen, und weisen darauf hin, dass dieses Alignment später wahrscheinlich Pflicht wird.

Auch wenn Sie weit weniger als 5.000 Nachrichten pro Tag versenden, entscheiden diese Einträge darüber, ob Ihre Rechnungen, Passwort-Resets und Antworten im Posteingang ankommen und ob jemand anderes überzeugende Mails in Ihrem Namen versenden kann.

So funktioniert der SPF- und DMARC-Checker von Searvia

Der kostenlose SPF- und DMARC-Checker ist Teil unseres Website-SEO-Checkers und zeigt die E-Mail-Authentifizierung als Erstes an. Geben Sie eine Domain ein (ein vorangestelltes www. wird entfernt), und das Tool:

1. Ruft die TXT-Einträge der Domain ab und nimmt die, die mit v=spf1 beginnen. Mehr als einer wird markiert, weil SPF dann fehlschlägt.
2. Zählt die DNS-Abfragen, die der SPF-Eintrag benötigt (include, a, mx, ptr, exists und redirect, wobei jedes Include eine Ebene tief verfolgt wird), und markiert mehr als 10.
3. Ruft die TXT-Einträge von _dmarc. plus Domain ab und nimmt den, der mit v=DMARC1 beginnt.
4. Liest die p=-Richtlinie aus dem DMARC-Eintrag und prüft, ob eine rua-Berichtsadresse vorhanden ist.
5. Zeigt beide Einträge vollständig mit Häkchen oder Kreuz an, dazu eine DKIM-Zeile mit dem Vermerk „Not checked“.

Im gesamten Audit hat diese Prüfung mittlere Priorität. Beachten Sie, wie streng sie bei DMARC ist: p=none erfüllt das Minimum von Gmail, zeigt aber trotzdem eine Warnung, weil es Spoofing nicht verhindert.

Was die kostenlose Prüfung nicht abdeckt:

• DKIM. DKIM-Schlüssel liegen unter Selectors, die jeder Maildienst selbst wählt, und über DNS lassen sie sich nicht auflisten. Deshalb markiert der Bericht DKIM als nicht geprüft. Prüfen Sie DKIM im Admin-Bereich Ihres Mailanbieters oder in den Headern einer gesendeten Nachricht (achten Sie auf dkim=pass).
• Alle SPF-Regeln. Das Tool markiert doppelte Einträge und mehr als 10 Abfragen, prüft aber nicht, ob der Eintrag mit -all oder ~all endet. Includes werden nur eine Ebene tief verfolgt, daher kann ein tief verschachtelter Eintrag mehr Abfragen benötigen, als die Zählung zeigt.
• DMARC-Details. Es liest p= und prüft auf rua, aber nicht sp= oder die Alignment-Einstellungen.

So lesen Sie Ihr Ergebnis

• Fehler: Ihre Domain ist für Spoofing offen, und Ihre Mails verfehlen Anforderungen von Gmail und Yahoo. Beginnen Sie mit Schritt 1 unten.
• „DMARC is missing“ oder „SPF is missing“: halb erledigt. Ergänzen Sie den fehlenden Eintrag.
• „DMARC is set to none“: das häufigste Ergebnis. Sie sammeln Berichte (sofern rua gesetzt ist), was die richtige erste Phase ist. Planen Sie den Wechsel zur Durchsetzung.
• Bestanden: gut. Prüfen Sie, was das kostenlose Tool nicht sieht: DKIM für jeden Absender, tief verschachtelte SPF-Includes und die sp-Richtlinie für Subdomains.

So beheben Sie es, Schritt für Schritt

Schritt 1: Alles auflisten, was Mails als Ihre Domain versendet

Ihr Mailbox-Anbieter (Google Workspace, Microsoft 365), Newsletter-Tool, CRM, Helpdesk, Rechnungssoftware, E-Commerce-Plattform, das Kontaktformular Ihrer Website und jeder Server, der Benachrichtigungen verschickt. Ein hier vergessener Absender ist der Hauptgrund, warum die DMARC-Durchsetzung später schiefgeht.

Schritt 2: Einen SPF-Eintrag veröffentlichen

1. Sammeln Sie den include:-Wert, den jeder Anbieter dokumentiert.
2. Fassen Sie sie in einem Eintrag zusammen. RFC 7208 ist eindeutig: Existiert mehr als ein SPF-Eintrag, lautet das Ergebnis „permerror“.
3. Enden Sie während des Testens mit ~all, danach mit -all.
4. Zählen Sie die Abfragen. include, a, mx, ptr, exists und redirect kosten jeweils eine DNS-Abfrage, und das Limit liegt bei 10, einschließlich der Abfragen in verschachtelten Includes. Mehr als 10 ergibt einen permerror. Entfernen Sie nicht mehr genutzte Dienste und verzichten Sie auf ptr, das laut RFC „NICHT veröffentlicht werden SOLLTE“.

Wenn ein Anbieter mit einer eigenen Envelope-Domain sendet (üblich bei Newsletter-Tools), muss er gar nicht in Ihrem SPF stehen; für ein bestandenes DMARC braucht er DKIM mit Ihrer Domain.

Schritt 3: DKIM für jeden Absender aktivieren

Suchen Sie in jedem Dienst die Einstellung für Domain-Authentifizierung oder DKIM, veröffentlichen Sie den angegebenen Eintrag (ein TXT oder CNAME unter einem Selector) und aktivieren Sie das Signieren. Google empfiehlt, nach der Einrichtung von SPF und DKIM 48 Stunden zu warten, bevor Sie DMARC hinzufügen. Senden Sie dann eine Testnachricht an eine Gmail-Adresse und prüfen Sie „Original anzeigen“: Sie wollen SPF: PASS, DKIM: PASS und DMARC: PASS sehen.

Schritt 4: DMARC mit p=none und Berichten veröffentlichen

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Google empfiehlt, mit p=none zu beginnen und immer rua anzugeben. Aggregatberichte sind XML-Dateien; ein DMARC-Berichtsdienst oder ein Parser macht sie lesbar. Liegt die Berichtsadresse auf einer anderen Domain, muss diese Domain sie per DNS-Eintrag autorisieren.

Schritt 5: Berichte lesen und Fehler beheben

Suchen Sie zwei bis vier Wochen lang nach legitimen Diensten, die beim SPF- oder DKIM-Alignment durchfallen. Jeder braucht DKIM-Signierung mit Ihrer Domain oder ein SPF-Include. Weitergeleitete Mails und Mailinglisten können aus legitimen Gründen durchfallen; RFC 9989 empfiehlt Domains, deren Nutzer an Mailinglisten schreiben, mindestens einen Monat bei p=none und einen ähnlichen Zeitraum bei p=quarantine zu bleiben, bevor sie auf p=reject wechseln.

Schritt 6: Zu quarantine wechseln, dann zu reject

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"
_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Ändern Sie immer nur eine Stufe und beobachten Sie weiter die Berichte. Mit p=quarantine besteht unser Checker. p=reject ist das Ziel: Empfänger weisen durchgefallene Mails zurück.

Schritt 7: Domains absichern, die keine Mails versenden

Geparkte Domains und reine Weiterleitungsdomains sind für Spoofer attraktiv, weil sie niemand beobachtet. Die Empfehlung der britischen Regierung lautet:

example.net.               TXT  "v=spf1 -all"
_dmarc.example.net.        TXT  "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s"
*._domainkey.example.net.  TXT  "v=DKIM1; p="
example.net.               MX   0 .

Die Einträge selbst prüfen

Der Checker liest SPF und DMARC; alle drei Einträge sehen Sie mit gängigen DNS-Tools. Unter macOS oder Linux:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT google._domainkey.example.com

Unter Windows erledigt nslookup -type=TXT _dmarc.example.com dasselbe. Für DKIM brauchen Sie den Selector, den Ihr Anbieter in seinen DKIM-Einstellungen anzeigt und der als s= im DKIM-Signature-Header jeder gesendeten Nachricht steht; google ist der Standard bei Google Workspace. Manche Anbieter veröffentlichen den Schlüssel als CNAME, der auf ihr eigenes DNS zeigt, was in Ordnung ist.

Der zuverlässigste End-to-End-Test ist eine echte Nachricht. Senden Sie von jedem Dienst eine an eine Gmail-Adresse und öffnen Sie „Original anzeigen“: Dort stehen das SPF-, DKIM- und DMARC-Ergebnis und die Domain, für die jedes bestanden hat. Ein DKIM-Pass für die Domain des Anbieters statt Ihrer eigenen bedeutet, dass das DMARC-Alignment weiterhin fehlschlägt. Suchen Sie also im Ergebnis nach Ihrer eigenen Domain.

Häufige Fehler

Praxisbeispiel (hypothetisch)

Das folgende Beispiel ist hypothetisch und enthält keine echten Daten. Pinecrest Dental, eine erfundene Zahnarztpraxis, erfährt von Patienten, dass sie eine gefälschte Zahlungsaufforderung „von“ der Praxis erhalten haben. Der SPF- und DMARC-Checker zeigt:

• SPF: v=spf1 include:_spf.google.com ~all
• DMARC: fehlt. Ergebnis: Warnung, „DMARC is missing.“

Schritt 1 findet drei Absender: Google Workspace, das Buchungssystem, das Terminerinnerungen verschickt, und ein Newsletter-Tool. Das Buchungssystem braucht ein SPF-Include; das Newsletter-Tool nutzt eine eigene Envelope-Domain und bekommt daher stattdessen DKIM mit der Domain der Praxis. Die Praxis veröffentlicht DMARC mit p=none und einer Berichtsadresse. Zwei Wochen Berichte zeigen, dass das Buchungssystem SPF und der Newsletter DKIM besteht, dazu einige hundert Nachrichten von unbekannten Servern in anderen Ländern, die beides nicht bestehen: das Spoofing. Die Praxis wechselt zu p=quarantine, womit der Checker besteht, und einen Monat später zu p=reject. Gefälschte Nachrichten in ihrem Namen werden nun von Empfängern abgewiesen, die DMARC anwenden.

Eine Checkliste, die Sie diese Woche abschließen können

1. Führen Sie den SPF- und DMARC-Checker für jede Domain aus, die Sie besitzen, auch für geparkte.
2. Listen Sie alle Dienste auf, die Mails als Ihre Domain versenden.
3. Führen Sie SPF in einem Eintrag zusammen, unter 10 Abfragen, endend auf ~all oder -all.
4. Aktivieren Sie DKIM in jedem Dienst und testen Sie mit „Original anzeigen“ in Gmail.
5. Veröffentlichen Sie DMARC mit p=none und rua und lesen Sie die Berichte.
6. Wechseln Sie zu p=quarantine, dann zu p=reject.
7. Veröffentlichen Sie v=spf1 -all und p=reject für Domains, die nichts versenden.

Wie Searvia Ihre E-Mail-Authentifizierung überwacht

Der kostenlose SPF- und DMARC-Checker liest Ihre Einträge in Sekunden, ohne Anmeldung, als Teil eines Audits mit 38 Prüfungen, das auch das Suchbild, die Geschwindigkeit und die Sicherheit Ihrer Website abdeckt.

Ein kostenloses Searvia-Konto ergänzt einen wöchentlichen Security-Scan, der bei E-Mails weiter geht: Er markiert einen fehlenden oder zu offenen SPF-Eintrag (+all, ?all oder gar kein all), eine fehlende oder noch auf p=none stehende DMARC-Richtlinie sowie einen fehlenden CAA-Eintrag, jeweils mit der zugrunde liegenden DNS-Abfrage und einem Eintrag zum Kopieren. Der Scan wiederholt sich jeden Donnerstag, sodass eine DNS-Änderung, die Ihre Einträge beschädigt, innerhalb einer Woche auffällt. Zur Sicherheit der Website selbst lesen Sie unseren Leitfaden zu Security-Headern.