SPF- und DMARC-Einträge im Browser erzeugen und prüfen – ohne DNS-Abfrage.
CIDR eingeben und Netz-, Broadcast-Adresse, nutzbare Hosts und Masken für IPv4 und IPv6 erhalten.
Öffnen →Rufen Sie RDAP-Registrierungsdaten und Reverse-DNS für eine IPv4-/IPv6-Adresse, Domain oder URL ab.
Öffnen →Zeigt Ihre öffentliche IP, Netzwerkdetails und ungefähren Standort an, mit WebRTC-Leak-Prüfung.
Öffnen →Noch keine Kommentare. Schreiben Sie den ersten!
Der SPF- und DMARC-Generator erstellt und prüft E-Mail-Authentifizierungseinträge nach RFC 7208 (SPF) und RFC 9989 (DMARC). Bei SPF wählen Sie die Includes gängiger Versanddienste, fügen IPs hinzu, legen die Abschlussregel fest und schätzen die Zahl der DNS-Abfragen (Limit 10); bei DMARC stellen Sie Richtlinien p/sp/np, Berichtspostfächer, Fehlerbericht-Optionen und Alignment-Modi ein. Ein vorhandener Eintrag lässt sich zur Offline-Syntaxprüfung einfügen. Das Tool verarbeitet nur Text, fragt nie DNS ab und kann nicht belegen, dass DNS korrekt eingerichtet ist.
Nein. Es erstellt und prüft nur den Eintrags-TEXT in Ihrem Browser und fragt nie DNS ab; es kann daher nicht belegen, dass ein Eintrag veröffentlicht oder aktiv ist. Prüfen Sie nach der Veröffentlichung mit einem DNS-Abfragetool und kontrollieren Sie die Authentifizierungsergebnisse mit einer echten Testnachricht.
Nach RFC 7208 darf eine SPF-Auswertung höchstens 10 Terme enthalten, die DNS-Abfragen auslösen (include, a, mx, ptr, exists und redirect); auch in einem include verschachtelte Terme zählen mit. ip4, ip6 und all zählen nicht. Darüber liefern Empfänger permerror, SPF schlägt also fehl.
Für die eingebauten gängigen Versanddienste nutzt das Tool die am 2026-10-20 im öffentlichen DNS gemessene Zahl verschachtelter Abfragen; bei einem selbst eingegebenen include ist sie unbekannt und wird mit einem Hinweis als 1 gezählt. Anbieter können Einträge jederzeit ändern – prüfen Sie vor der Veröffentlichung noch einmal mit einem DNS-basierten SPF-Checker.
~all (Soft Fail) besagt, dass nicht aufgeführte Quellen wahrscheinlich nicht autorisiert sind, aber angenommen und markiert werden sollen – sinnvoll zu Beginn, solange noch nicht alle Absender bestätigt sind. -all (Hard Fail) weist sie ausdrücklich zurück. Googles Hinweise empfehlen ~all, Microsoft empfiehlt -all, sobald auch DKIM und DMARC eingerichtet sind. Verwenden Sie nie +all: Damit kann jeder als Ihre Domain senden.
RFC 9989 (DMARCbis) definiert v, p, sp, np, adkim, aspf, fo, rua, ruf, psd und t. Die Tags pct, rf und ri aus RFC 7489 wurden entfernt; t (Test-Flag, t=y entspricht etwa dem üblichen pct=0) übernimmt den häufigen Anwendungsfall. Dieses Tool schreibt pct standardmäßig nicht; es wird nur ergänzt, wenn Sie es unter „Erweiterte und Kompatibilitätsoptionen“ ausdrücklich einschalten.
Beginnen Sie mit p=none und einer rua-Adresse und sammeln Sie mindestens einen Monat lang Aggregatberichte, um alle legitimen Absender zu finden. Richten Sie SPF oder DKIM jedes Absenders auf Ihre From-Domain aus, wechseln Sie dann zu p=quarantine und beobachten Sie erneut (bei Unsicherheit zuerst t=y). Erst wenn legitime Mails nicht mehr betroffen sind, folgt p=reject. Das kann Mailinglisten und Weiterleitungen stören – lesen Sie vorher die Berichte.
Liegt ein rua- oder ruf-Postfach außerhalb Ihrer Domain, muss die andere Domain unter „ihre-domain._report._dmarc.andere-domain“ einen TXT-Eintrag mit dem Wert v=DMARC1; veröffentlichen, sonst senden die meisten Empfänger keine Berichte; das Tool zeigt den genauen Hostnamen. Laut Postmark-Dokumentation müssen Sie Postmark nicht in Ihren SPF aufnehmen, daher steht es nicht in den Vorgaben; die include-Werte aller aufgeführten Dienste stammen aus deren offizieller Dokumentation.
v=spf1 include:_spf.google.com ~all
| Typ | DNS-Hostname | Wert |
|---|---|---|
| TXT | @ | v=spf1 include:_spf.google.com ~all |