SPF- und DMARC-Generator: Records für die Domain erstellen und prüfen

Wer eine Firmendomain betreut, kommt an SPF und DMARC nicht vorbei: Große Postfachanbieter lehnen Mails ohne saubere Absenderauthentifizierung zunehmend ab, und gefälschte Rechnungen im Namen der eigenen Domain sind für KMU ein echtes Risiko. Der SPF- und DMARC-Generator auf s-edv.com erstellt beide TXT-Records per Formular und prüft vorhandene Records auf Syntaxfehler und das Lookup-Limit. Die Anleitung richtet sich an Admins, die einen Record neu anlegen oder aufräumen wollen, und zeigt Bedienung, DNS-Eintrag und Gegenprobe mit dig.

Voraussetzungen

Für die Arbeit mit dem Tool brauchen Sie nur einen aktuellen Browser. Für den produktiven Einsatz kommen hinzu:

• Zugriff auf die DNS-Verwaltung Ihrer Domain (Registrar, Hoster oder eigener DNS-Server), auf der Sie TXT-Records anlegen dürfen.
• Eine Liste aller Systeme, die Mails mit Ihrer Domain versenden: Mailserver oder Microsoft 365 bzw. Google Workspace, Newsletter-Dienst, Webshop, Ticketsystem, Warenwirtschaft, Multifunktionsdrucker mit Scan-to-Mail.
• Ein Postfach für DMARC-Sammelberichte, zum Beispiel dmarc-berichte@ihre-domain.de, oder einen Report-Dienst.
• Ein Terminal mit dig (Linux, macOS) oder nslookup (Windows) für die Gegenprobe.
• Grundwissen zu DNS-Records. Wer TXT- und MX-Records noch nicht sicher auseinanderhält, liest vorher DNS-Records erklärt: A, AAAA, CNAME, MX und TXT.

Schritt 1: Grundlagen klären und das Tool öffnen

SPF (RFC 7208) ist ein TXT-Record direkt an der Domain. Er beginnt mit v=spf1 und listet Mechanismen auf, die von links nach rechts ausgewertet werden; der erste Treffer entscheidet. Geprüft wird die Domain des Umschlag-Absenders (MAIL FROM, im Header als Return-Path sichtbar). DMARC (RFC 7489) liegt als TXT-Record unter _dmarc.ihre-domain.de und verlangt, dass SPF oder DKIM besteht und die geprüfte Domain zur sichtbaren From-Adresse passt. Dieser Abgleich heißt „Alignment“.

Besonders wichtig ist das Lookup-Limit: Ein Empfänger darf bei der SPF-Auswertung höchstens 10 DNS-Abfragen auslösen. Mechanismen wie a, mx, include, exists, ptr und der Modifier redirect zählen jeweils, ip4, ip6 und all nicht. Bei mehr als 10 Abfragen lautet das Ergebnis permerror, und SPF gilt als fehlerhaft.

Öffnen Sie den SPF- und DMARC-Generator. Oben wählen Sie über zwei Umschalter den Record-Typ („SPF“ oder „DMARC“) und den Modus („Erstellen“ oder „Prüfen“). Darunter stehen immer die Felder „Domain“ (Zusatz „für DNS-Name und Prüfungen“) und „TTL“ mit den Vorschlägen „3600 s (1 Stunde)“, „300 s (während einer Umstellung)“ und „86400 s (1 Tag)“. Tragen Sie Ihre Domain ohne https:// ein, etwa firma-beispiel.de.

Die Seite gibt an, komplett im Browser zu laufen und keine Daten an einen Server zu senden. Im Test kamen nach dem Laden der Seite beim Ausfüllen und Prüfen keine weiteren Netzwerkanfragen hinzu.

Verifizieren: Rechts erscheint sofort die Karte „SPF-Record“ mit „Name (Host)“ gleich Ihrer Domain und der Zeile „Zonendatei“, die mit firma-beispiel.de. 3600 IN TXT beginnt. Lassen Sie das Feld „Domain“ leer, setzt das Tool still example.com ein; das sollten Sie nicht übersehen.

Schritt 2: SPF-Record erstellen

Im Modus „Erstellen“ für SPF stehen folgende Optionen bereit:

• „Diese Domain versendet keine E-Mails“: erzeugt v=spf1 -all. Ideal für reine Webdomains und Tippfehler-Domains, die sonst zum Fälschen einladen.
• „Eigene Mailserver aus dem MX-Record“ (mx, standardmäßig aktiv) und „Server der Domain selbst“ (a).
• „Dienste einbinden (include)“ mit einem Eintrag pro Zeile. Die Schaltflächen „Microsoft 365“ und „Google Workspace“ fügen spf.protection.outlook.com bzw. _spf.google.com ein. Für Newsletter-Dienste oder Ticketsysteme übernehmen Sie den include-Wert aus der Doku des Anbieters.
• „Eigene IP-Adressen und Netze“: IPv4 oder IPv6, optional mit Präfix, eine Adresse pro Zeile. Das Tool macht daraus ip4: bzw. ip6:.
• „Alle übrigen Absender“: -all, ~all oder ?all.

Praxisbeispiel: Eine Steuerkanzlei nutzt Microsoft 365, versendet Rundschreiben über einen Server mit der IP 203.0.113.10 und hat ein IPv6-Netz 2001:db8::/48. Mit aktivem mx, der Schaltfläche „Microsoft 365“, den beiden Adressen und -all erzeugt das Tool:

v=spf1 mx ip4:203.0.113.10 ip6:2001:db8::/48 include:spf.protection.outlook.com -all

Unter dem Ergebnis zeigt das Tool „DNS-Lookups“ mit dem Zusatz „direkt im Record“ und die „Länge“ in Zeichen. Bei v=spf1 mx include:spf.protection.outlook.com ~all waren das im Test 2 von 10 Lookups und 49 Zeichen; mit zusätzlich a und Google Workspace 4 von 10 und 75 Zeichen. Beide Werte stimmen mit einer Nachzählung per Python überein.

-all (Fail) ist die strenge Wahl, sobald alle Absender erfasst sind; ~all (SoftFail) eignet sich als Zwischenschritt, ?all schützt praktisch nicht.

Verifizieren: Die Liste „Hinweise“ enthält keine Meldung „Der Eintrag wurde nicht übernommen“, „DNS-Lookups“ liegt deutlich unter 10, und der Wert beginnt mit v=spf1 und endet mit Ihrem all-Eintrag.

Schritt 3: Lookups eingebundener Records nachzählen

Das Tool zählt nur, was direkt im Record steht, und weist selbst darauf hin: Eingebundene Records haben eigene Einträge, die ebenfalls in die Grenze zählen. Prüfen Sie deshalb jeden eingebundenen Record im Terminal:

dig +short TXT spf.protection.outlook.com
dig +short TXT _spf.google.com

Zum Testzeitpunkt bestanden beide Records nur aus ip4- und ip6-Netzen mit abschließendem all. Sie verursachen also jeweils genau einen Lookup, den das Tool bereits mitgezählt hat. Steht in der Antwort dagegen wieder include:, a oder mx, rechnen Sie diese Einträge zum Wert aus dem Tool hinzu und wiederholen die Abfrage für jeden weiteren include. Der mx-Mechanismus hat ein zusätzliches Limit: Er darf höchstens 10 Mailserver-Namen auflösen.

Verifizieren: Die Summe aus „DNS-Lookups“ im Tool und den Lookups in allen eingebundenen Records ist höchstens 10. Liegt sie darüber, ersetzen Sie einzelne includes durch feste ip4/ip6-Einträge oder streichen nicht mehr genutzte Dienste.

Schritt 4: SPF-Record im DNS eintragen

Die Ergebniskarte enthält vier Bausteine mit Kopierschaltflächen („Record kopieren“, „Name (Host) kopieren“, „Zonendatei kopieren“): den „Wert des TXT-Records“, den „Name (Host)“, den Typ „TXT“ und die TTL. Viele DNS-Oberflächen erwarten als Host für die Domain selbst @ oder ein leeres Feld; das Tool weist mit „In vielen DNS-Oberflächen als @ oder leer eingetragen“ darauf hin.

Wichtig: Pro Name darf es nur einen TXT-Record mit v=spf1 geben. Existiert schon einer, ersetzen Sie ihn, statt einen zweiten anzulegen. Planen Sie eine Umstellung, wählen Sie vorher die TTL „300 s (während einer Umstellung)“, damit Korrekturen schnell greifen, und setzen Sie sie danach wieder auf 3600 Sekunden.

dig +short TXT firma-beispiel.de | grep spf1
dig +short TXT firma-beispiel.de @1.1.1.1 | grep -c spf1

Verifizieren: Die erste Abfrage liefert genau Ihren neuen Wert, die zweite gibt 1 aus. Eine 2 bedeutet zwei SPF-Records und damit permerror bei den Empfängern.

Schritt 5: Vorhandenen SPF-Record prüfen

Schalten Sie auf „Prüfen“ und fügen Sie den Record in das Feld „Vorhandener SPF-Record“ ein. Laut Feldbeschreibung geht das „auch mit Anführungszeichen aus der Zonendatei“; im Test erkannte das Tool sogar eine komplette Zonendatei-Zeile korrekt. Drei Beispiele lassen sich per Schaltfläche laden: „Beispiel: Microsoft 365“, „Beispiel mit Fehlern“ und „Zu viele Lookups“.

Das Ergebnis zeigt einen Status („Syntax in Ordnung“, „Gültig, mit Hinweisen“ oder die Zahl der Fehler), die Kacheln „DNS-Lookups“, „Länge“ und „Fremde Server“ (zum Beispiel „Fail“ bei -all) sowie eine Tabelle mit Spalten „Eintrag“, „Bedeutung“ und „Lookups“. Einträge hinter einem all markiert die Tabelle als „(wirkungslos)“.

Praxisbeispiel aus einem Altbestand: v=spf1 ip4:203.0.113.10 include:_spf.google.com ptr ~all mx. Das Tool meldet, dass ptr nicht mehr veröffentlicht werden soll, und dass mx hinter ~all wirkungslos ist. Der korrigierte Record lautet v=spf1 mx ip4:203.0.113.10 include:_spf.google.com ~all.

Verifizieren: Kopieren Sie den Live-Record mit dig +short TXT ihre-domain.de in das Prüffeld. Der Status lautet „Syntax in Ordnung“, „Fremde Server“ zeigt das gewünschte Ergebnis, und keine Zeile ist als „Ungültig“ oder „(wirkungslos)“ markiert.

Schritt 6: DMARC-Record erstellen

Wechseln Sie auf „DMARC“ und „Erstellen“. Die Hauptfelder sind „Richtlinie p=“ mit „none“, „quarantine“ und „reject“ sowie „Sammelberichte an (rua)“ mit einer Adresse pro Zeile. Unter „Erweiterte Einstellungen“ finden Sie „Subdomains sp=“ (Standard „wie p (nicht angeben)“), „Anteil pct=“ (0 bis 100), die Ausrichtung für DKIM und SPF jeweils „entspannt (r)“ oder „streng (s)“, „Fehlerberichte an (ruf)“ und „Fehlerberichte auslösen fo=“ mit dem Zusatz „nur mit ruf wirksam“.

Für den Einstieg reicht die Richtlinie none mit einer Berichtsadresse. Das Tool erzeugt dann:

_dmarc.firma-beispiel.de. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-berichte@firma-beispiel.de"

Das Präfix mailto: ergänzt das Tool selbst; mehrere Adressen verbindet es mit Komma. Als Host zeigt es _dmarc.firma-beispiel.de mit dem Hinweis, in vielen DNS-Oberflächen nur „_dmarc“ einzutragen. Ohne rua-Adresse warnt das Tool, dass Sie dann keine Sammelberichte erhalten.

Liegt die rua-Adresse bei einem externen Report-Dienst, nennt das Tool den nötigen Freigabe-Record beim Empfänger, etwa firma-beispiel.de._report._dmarc.dmarc-anbieter.example mit dem Inhalt v=DMARC1. Bei pct unter 100 erinnert das Tool daran, dass DMARCbis pct nicht mehr vorsieht.

Verifizieren: Nach dem Eintragen liefert dig +short TXT _dmarc.firma-beispiel.de genau einen Record, der mit v=DMARC1; p= beginnt. Nach ein bis zwei Tagen treffen die ersten Sammelberichte im rua-Postfach ein.

Schritt 7: DMARC prüfen und schrittweise verschärfen

Im Modus „Prüfen“ fügen Sie den Inhalt des TXT-Records in „Vorhandener DMARC-Record“ ein oder laden „Beispiel: quarantine“, „Externer Empfänger“ oder „Beispiel mit Fehlern“. Die Auswertung zeigt die Kacheln „Richtlinie“, „Berichte“ und „Anteil“ sowie eine Tabelle, die jeden Tag in Klartext übersetzt, etwa „DKIM-Ausrichtung entspannt: gleiche Organisationsdomain genügt“.

Bewährt hat sich ein Vorgehen in drei Stufen. Mit p=none sammeln Sie zwei bis vier Wochen Berichte und finden vergessene Absender wie Newsletter-Tool oder Webshop. Bestehen alle legitimen Quellen, folgen p=quarantine und p=reject. Wie Sie die XML-Berichte lesen, beschreibt DMARC-Reports verstehen und auswerten: von p=none sicher zu p=reject. Richten Sie zusätzlich DKIM ein, denn bei Weiterleitungen scheitert SPF häufig, während eine unveränderte DKIM-Signatur erhalten bleibt.

Verifizieren: Der Status lautet „Syntax in Ordnung“, die Kachel „Berichte“ zeigt „ja“, und in den Sammelberichten erscheinen nur noch Ihre eigenen Systeme mit bestandenem SPF oder DKIM, bevor Sie die Richtlinie verschärfen.

Typische Fehler

• Tippfehler im Mechanismus: ipv4:203.0.113.5 meldet das Tool mit als ungültigen SPF-Eintrag und schlägt ip4 vor. Ein solcher Syntaxfehler macht den ganzen Record ungültig.
• Ungültige Adressen im Formular: Bei 203.0.113.300 oder foo erscheint „ist keine gültige IPv4- oder IPv6-Adresse. Der Eintrag wurde nicht übernommen“, bei 10.0.0.0/33 eine ungültige Präfixlänge. Die Zeile fehlt dann im Record, also Hinweise immer lesen.
• URL statt Hostname: https://mail.example im include-Feld quittiert das Tool mit „Unzulässige Zeichen“ und übernimmt den Eintrag nicht.
• Zwei SPF-Records: Das Tool meldet „Es wurden 2 SPF-Records eingegeben“ und prüft nur den ersten. Im DNS führt das zu permerror.
• Zu viele Lookups: Ab 11 meldet das Tool einen Fehler mit Verweis auf RFC 7208, Abschnitt 4.6.4.
• Fehlendes v=spf1, fehlendes all oder +all: Ohne Kennung ist es kein SPF, ohne all gilt „neutral“, bei +all darf laut Tool jeder Server der Welt in Ihrem Namen senden.
• DMARC-Reihenfolge und Format: v=DMARC1 muss der erste Eintrag sein, rua braucht mailto:, v=dmarc1 in Kleinbuchstaben ist ungültig, ebenso adkim=x oder fo=9.

Häufige Fragen

Fragt das Tool meine echten DNS-Einträge ab?

Nein. Es arbeitet nur mit Ihren Eingaben, löst keine includes auf und prüft nicht, ob Ihr MX existiert. Den Live-Stand holen Sie mit dig und fügen ihn in den Prüfmodus ein.

Gilt der SPF-Record auch für Subdomains?

Nein, SPF gilt nur für den exakten Namen. Versendet etwa newsletter.firma-beispiel.de, braucht diese Subdomain einen eigenen Record; tragen Sie sie dafür im Feld „Domain“ ein. DMARC wirkt dagegen über sp= auch auf Subdomains.

Warum zeigt das Tool nur 2 Lookups, obwohl mein Record länger ist?

ip4, ip6 und all kosten keinen Lookup. Ein Record mit 19 festen IPv4-Adressen ergab im Test 0 Lookups, aber 344 Zeichen; das Tool weist dann auf die 255-Zeichen-Grenze pro Zeichenkette hin.

Testumfang

Getestet wurde das Tool am 1. Oktober 2026 im Browser mit allen Optionen in beiden Bereichen, mit den mitgelieferten Beispielen und mit absichtlich fehlerhaften Eingaben. Die erzeugten Längen und Lookup-Zahlen haben wir per Python nachgezählt, die Adressprüfung mit dem Python-Modul ipaddress verglichen und die Records von Microsoft 365 und Google Workspace per dig abgefragt. Alle geprüften Werte stimmten.

Fazit

Der SPF- und DMARC-Generator nimmt die fehleranfällige Tipparbeit ab und erklärt jede Meldung verständlich. Die eigentliche Arbeit bleibt organisatorisch: alle Absender erfassen, Lookups eingebundener Records nachzählen und DMARC anhand echter Berichte verschärfen. Wer Microsoft 365 nutzt, findet die Schritte für DKIM in Exchange Online: SPF, DKIM und DMARC für die eigene Domäne, für eigene Mailserver hilft OpenDKIM mit Postfix einrichten.

Weiterführende Anleitungen und Quellen

• DMARC-Reports verstehen und auswerten: von p=none sicher zu p=reject
• Exchange Online: SPF, DKIM und DMARC für die eigene Domäne
• OpenDKIM mit Postfix einrichten: DKIM-Signatur korrekt konfigurieren
• DNS-Records erklärt: A, AAAA, CNAME, MX und TXT
• RFC 7208: Sender Policy Framework (SPF)
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• Microsoft Learn: SPF für Microsoft 365 einrichten
• Google Workspace-Hilfe: SPF einrichten
• man-page dig(1)