BrowserTools
Startseite / Generatoren / SPF- und DMARC-Generator

SPF- und DMARC-Generator

Erstellen Sie die DNS-Einträge, die verhindern, dass andere in Ihrem Namen E-Mails verschicken, oder prüfen Sie einen vorhandenen Eintrag.

SPF- und DMARC-Generator wird geladen… Wenn nichts passiert, aktiviere JavaScript.

Jeder kann Ihre Adresse in die Absenderzeile einer E-Mail schreiben. SPF und DMARC sind die beiden DNS-Einträge, mit denen empfangende Mailserver echte Nachrichten von Fälschungen unterscheiden. SPF (Sender Policy Framework) ist ein TXT-Eintrag auf Ihrer Domain, der die Server auflistet, die für sie senden dürfen: Ihren E-Mail-Anbieter, Ihren Newsletter-Dienst, Ihren eigenen Server. DMARC baut darauf auf, liegt unter _dmarc.ihredomain und legt fest, was Empfänger mit Mails tun sollen, die die Prüfungen nicht bestehen (zustellen, in den Spam verschieben oder abweisen), und wohin Berichte darüber gehen. Gmail, Yahoo und Microsoft verlangen inzwischen beides von Massenversendern, und ohne diese Einträge landet Ihre echte Post eher im Spam, während gefälschte durchkommt.

Häufig gestellte Fragen

Wo trage ich diese Einträge ein?
In den DNS-Einstellungen des Unternehmens, das das DNS Ihrer Domain verwaltet, meist Ihr Registrar oder ein Dienst wie Cloudflare. Legen Sie einen TXT-Eintrag an. Für SPF ist der Host die Domain selbst, oft als @ geschrieben. Für DMARC ist der Host _dmarc, den manche Oberflächen als _dmarc.example.com und andere nur als _dmarc erwarten, weil sie die Domain selbst ergänzen. Änderungen wirken je nach TTL meist nach einigen Minuten bis wenigen Stunden.
Was ist der Unterschied zwischen ~all und -all?
Beide schließen die Liste der erlaubten Absender ab. Bei ~all (Softfail) werden Mails von nicht aufgeführten Servern angenommen, aber als verdächtig behandelt, was meist den Spam-Ordner bedeutet. Bei -all (Hardfail) dürfen Empfänger sie direkt abweisen. ~all ist der sicherere Start, solange Sie noch alle Dienste ermitteln, die für Sie senden. Sobald DKIM und DMARC eingerichtet sind, ist -all eine gute Wahl, und Microsoft empfiehlt es für Microsoft-365-Domains. ?all schützt gar nicht und +all erlaubt dem gesamten Internet das Senden, vermeiden Sie also beides.
Warum ist SPF auf 10 DNS-Abfragen begrenzt?
Die Prüfung eines SPF-Eintrags kann den Empfänger zu immer neuen DNS-Abfragen zwingen. Deshalb begrenzt RFC 7208 die Mechanismen, die eine Abfrage brauchen (include, a, mx, ptr, exists und redirect), auf 10 pro Prüfung, einschließlich allem in verschachtelten includes. Wer darüber liegt, erzeugt einen permanenten Fehler, und SPF schlägt für Ihre gesamte Post fehl. Dieses Tool zählt die Abfragen, die direkt in Ihrem Eintrag stehen. In die eingebundenen Einträge kann es ohne echte DNS-Abfragen nicht hineinsehen, und manche verbrauchen allein mehrere Abfragen, planen Sie also Reserve ein. Wird es eng, verlegen Sie einen Dienst auf eine Subdomain oder ersetzen Sie ein include durch dessen veröffentlichte IP-Bereiche.
Darf ich zwei SPF-Einträge haben?
Nein. Eine Domain oder Subdomain darf genau einen TXT-Eintrag veröffentlichen, der mit v=spf1 beginnt. Gibt es zwei, melden Empfänger einen permanenten Fehler und SPF schlägt für alles fehl, ein häufiger Fehler nach dem Hinzufügen eines neuen Dienstes. Führen Sie sie zusammen: ein einziges v=spf1 am Anfang, alle ip4-, ip6- und include-Angaben in der Mitte und ein einziges all am Ende.
Und was ist mit DKIM?
DKIM versieht jede ausgehende Nachricht mit einer kryptografischen Signatur, und der passende öffentliche Schlüssel wird im DNS unter einem Selektor veröffentlicht, etwa selector1._domainkey.example.com. Das Schlüsselpaar erzeugt derjenige, der Ihre Mails signiert. Einen brauchbaren DKIM-Eintrag können Sie also nicht selbst generieren: Aktivieren Sie DKIM in der Verwaltungskonsole Ihres Anbieters (Google Workspace, Microsoft 365, SendGrid und andere) und veröffentlichen Sie die TXT- oder CNAME-Einträge, die er Ihnen nennt. DKIM ist wichtig, weil es Weiterleitungen übersteht, an denen SPF meist scheitert, und DMARC besteht, sobald eines der beiden zur Absenderdomain passt.
Mit welcher DMARC-Richtlinie sollte ich beginnen?
Beginnen Sie mit p=none und einer rua-Adresse. Für Ihre Mails ändert sich nichts, aber Empfänger schicken nun tägliche Sammelberichte, die jeden Server auflisten, der im Namen Ihrer Domain sendet, und ob er die Prüfung bestanden hat. Korrigieren Sie nach zwei bis vier Wochen SPF oder DKIM für alle legitimen Absender, die durchfallen, wechseln Sie dann zu p=quarantine und später zu p=reject. Dauerhaft bei p=none zu bleiben schützt nicht: Es wird nur beobachtet.
Was hat sich mit RFC 9989 geändert?
Im Mai 2026 veröffentlichte die IETF RFC 9989, das RFC 7489 als DMARC-Standard ablöst, zusammen mit RFC 9990 und 9991 für die Berichte. Es streicht die Tags pct, ri und rf, führt t=y als einfachen Testmodus und np für nicht existierende Subdomains ein und übernimmt das psd-Tag, das Betreiber öffentlicher Suffixe verwenden. Bestehende Einträge funktionieren weiter, und viele Empfänger berücksichtigen pct noch, deshalb bietet dieses Tool pct und ri als optionale Altlasten-Einstellungen an.
Warum brauchen Berichte an eine andere Domain einen zusätzlichen Eintrag?
Damit niemand DMARC-Berichte an ein fremdes Postfach umleiten kann, prüfen Empfänger, ob das Ziel dem Empfang zustimmt. Schickt Ihr Eintrag für example.com Berichte an reports@dmarc-service.net, muss dieser Dienst unter example.com._report._dmarc.dmarc-service.net einen TXT-Eintrag mit v=DMARC1 veröffentlichen. Berichtsdienste richten das ein, wenn Sie Ihre Domain hinzufügen, doch auch ein Postfach auf einer anderen eigenen Domain braucht ihn.
Fragt dieses Tool meine Domain ab?
Nein. Die Einträge werden vollständig in Ihrem Browser erstellt und geprüft, und nichts von Ihren Eingaben wird verschickt. Das bedeutet auch, dass das Tool weder sieht, was aktuell veröffentlicht ist, noch verschachtelte includes auflösen kann. Nutzen Sie das Tool DNS Lookup, um die aktuellen TXT-Einträge Ihrer Domain und von _dmarc.ihredomain abzurufen, und fügen Sie sie dann in die Prüfung ein.

Über SPF- und DMARC-Generator

Im SPF-Generator kreuzen Sie die Dienste an, die Sie nutzen (Google Workspace, Microsoft 365, Zoho Mail, Amazon SES, SendGrid, Mailgun und Mailchimp Transactional, mit den include-Werten aus der Dokumentation des jeweiligen Anbieters), ergänzen eigene IPv4- und IPv6-Adressen und wählen, wie streng das abschließende all sein soll. Er zählt dabei die DNS-Abfragen mit, denn oberhalb von 10 funktioniert SPF nicht mehr, und teilt den Wert in Zeichenketten zu 255 Zeichen auf, wenn ein langer Eintrag das erfordert. Die Prüfung nimmt einen bestehenden Eintrag und erklärt jeden Bestandteil in verständlicher Sprache. Sie meldet Syntaxfehler wie include= statt include:, ein Leerzeichen nach dem Doppelpunkt oder ipv4: statt ip4:, und warnt vor einem zweiten SPF-Eintrag auf derselben Domain, dem veralteten ptr-Mechanismus, dem gefährlichen +all, Angaben hinter all und Einträgen, die für UDP zu lang werden.

Der DMARC-Generator folgt der schrittweisen Einführung, bei der keine Mails verloren gehen: Beginnen Sie mit p=none und einer Berichtsadresse, lesen Sie einige Wochen lang die Berichte, um alle Dienste zu finden, die in Ihrem Namen senden, wechseln Sie dann zu quarantine und schließlich zu reject. Er deckt Richtlinien für Subdomains und nicht existierende Subdomains ab, strenges oder lockeres Alignment, Optionen für Fehlerberichte und den Testmodus aus RFC 9989, dem im Mai 2026 veröffentlichten überarbeiteten DMARC-Standard, und bietet die älteren Tags pct und ri für Empfänger, die sie noch auswerten. Beide Reiter zeigen den genauen Hostnamen und den TXT-Wert mit Kopierknöpfen. Alles wird in Ihrem Browser berechnet, es werden keine DNS-Abfragen gestellt. Um mit dem zu vergleichen, was eine Domain aktuell veröffentlicht, rufen Sie ihre TXT-Einträge mit dem Tool DNS Lookup ab und fügen Sie sie in die Prüfung ein.

SPF entstand gegen zurückgeschickten Spam

Anfang der 2000er-Jahre fälschten Spammer routinemäßig den Umschlagabsender ihrer Nachrichten, und die Rückläufer von Millionen unzustellbarer Spam-Mails landeten in den Postfächern unbeteiligter Domaininhaber. Mehrere Vorschläge versuchten das zu lösen, darunter Reverse MX und das Designated Mailers Protocol, und 2003 fasste Meng Weng Wong ihre Ideen in Sender Permitted From zusammen, das bald in Sender Policy Framework umbenannt wurde. Microsoft setzte auf einen Konkurrenten namens Sender ID, und beide wurden 2006 nebeneinander als Experimente veröffentlicht. SPF setzte sich durch: 2014 wurde es mit RFC 7208 zum vorgeschlagenen Standard, während Sender ID und seine spf2.0-Einträge in Vergessenheit gerieten.

Allein hatte SPF eine Lücke, denn es prüft die verborgene Umschlagadresse und nicht die Absenderzeile, die Menschen tatsächlich sehen. 2012 veröffentlichte eine Gruppe um PayPal, Google, Microsoft und Yahoo DMARC, das die Ergebnisse von SPF und DKIM an die sichtbare Absenderdomain koppelt und Berichte ergänzt. PayPal hatte gute Gründe: Die Marke gehörte zu den am häufigsten für Phishing missbrauchten im Netz. DMARC blieb jahrelang ein informatives Dokument, RFC 7489, bis RFC 9989 es 2026 auf den Standardisierungspfad der IETF brachte.

Unterstützen