Zum Inhalt springen

SPF-Checker:
bleibt Ihr Eintrag innerhalb des 10-Lookup-Limits?

Geben Sie eine Domain ein — wir holen ihre TXT-Einträge, isolieren den v=spf1, lösen jedes include rekursiv auf und zählen die DNS-Lookups gegen das SPF-Budget von 10. Wird es überschritten, liefert SPF stillschweigend permerror — Schutz aus, kein Bounce, keine Warnung.

Jedes include rekursiv aufgelöst Jeder DNS-Lookup gegen das Limit von 10 gezählt Urteil in Sekunden
Erweitert rohes DNS, von unserem Prüfknoten durchlaufen — serverseitig nach RFC 7208 bewertet optionaler IP-Test — pass / softfail / fail für Ihren Absender JSON-API — das letzte Ergebnis je Domain abrufen
Was eine SPF-Prüfung mit »Eintrag gefunden« übersieht

Vier Arten, wie SPF unbemerkt kaputtgeht

Wenn SPF kaputtgeht, wird Mail weiter versendet — die Empfänger prüfen sie nur nicht mehr. Alle vier Fälle sind aus Ihrem Postausgang unsichtbar — und in einer vollständigen Auswertung offensichtlich.

Das 10-Lookup-Limit

Jedes include, a, mx kostet einen DNS-Lookup — verschachtelte includes ebenso. Das Budget beträgt 10. Lookup #11 verschlechtert nichts: Der gesamte Eintrag liefert permerror, und SPF ist aus.

RFC 7208, §4.6.4

Der zweite Eintrag

Zwei TXT-Einträge, die mit v=spf1 beginnen, verschmelzen nicht — beide werden sofort ungültig. Der Klassiker: Ein Plugin oder eine Agentur hat SPF »hinzugefügt«, statt den vorhandenen Eintrag zu bearbeiten.

mehrere = permerror

+all autorisiert jeden Absender

+all bedeutet »und alle anderen kommen ebenfalls durch«. Damit ist das gesamte Internet berechtigt, in Ihrem Namen zu senden — jeder Spammer inklusive. Ein einziges Zeichen trennt es von -all, das genau das Gegenteil bedeutet.

schlimmer als gar kein Eintrag

Das veraltete include

Der Anbieter, den Sie 2023 verlassen haben, steht noch in Ihrem Eintrag. Ist dessen Domain tot, sind das Void-Lookups und permerror. Lebt sie noch, dürfen dessen heutige Kunden weiterhin Mail senden, die als Ihre durchgeht.

jährlich prüfen
Die Urteile

-all, ~all, ?all und die Sonderfälle

Der letzte Mechanismus entscheidet, was mit Mail von einer IP passiert, die Sie nicht gelistet haben. Ein paar Sonderfälle entscheiden den Rest.

-all · hardfail

»Nicht auf meiner Liste? Ablehnen.« Der strenge, richtige Abschluss — sofern die Liste davor vollständig ist und der Eintrag sauber ausgewertet wird. Strenge zählt nur, wenn der Rest stimmt.

→ das Ziel — bei sauberer Auswertung
~all · softfail

»Nicht auf meiner Liste? Annehmen, aber markieren.« Als Zwischenschritt der Einführung gedacht, dann für immer behalten. Mit DMARC darüber scheitert unautorisierte Mail trotzdem — ohne DMARC ist es ein Achselzucken.

→ okay während der Einführung · mit DMARC kombinieren
?all · neutral

»Nicht auf meiner Liste? Keine Meinung.« Wirkt exakt so, als hätten Sie gar kein SPF veröffentlicht — Empfänger erfahren nichts. Meist ein Überbleibsel aus einer kopierten Vorlage.

→ entscheiden Sie sich — mindestens ~all
+all · alle bestehen

»Nicht auf meiner Liste? Die bestehen trotzdem.« Damit ist das gesamte Internet berechtigt, als Ihre Domain zu senden — und Mail, die gefälscht aussehen müsste, besteht stattdessen die SPF-Prüfung.

→ heute noch entfernen — das ist der schlimmste Zustand
ptr · abgekündigt

Abgleich über Reverse-DNS: langsam, unzuverlässig und seit 2014 formal als »SHOULD NOT be used« eingestuft. Er verbraucht einen Lookup, kann still danebenliegen, und manche Empfänger überspringen ihn ganz.

→ durch ip4/ip6 oder include ersetzen
permerror · kein gültiges SPF

Zu viele Lookups, zwei Einträge, ein Syntaxfehler, ein totes include — das Ergebnis ist immer dasselbe: Empfänger behandeln Ihre Domain, als hätte sie kein gültiges SPF. Mail fließt weiter. Niemand sagt Ihnen Bescheid.

→ finden Sie den verursachenden Mechanismus — wir zeigen die Auswertung
So funktioniert das Lookup-Budget

So funktioniert das Budget von 10 Lookups

RFC 7208 begrenzt die DNS-Lookups, die ein Empfänger für die Auswertung Ihres Eintrags aufwendet. Diese Grenze ist alles — und den größten Teil Ihres Budgets verbrauchen die Einträge anderer Leute:

  • Was Budget verbraucht: include, a, mx, ptr, exists, redirect — je einen, verschachtelte eingeschlossen.
  • Was kostenlos ist: ip4, ip6 und all — feste Werte, kein DNS nötig. Genau deshalb funktioniert das »Flattening«.
  • Ein include ist selten ein Lookup: Mailgun braucht 5, Salesforce 2. Ein Eintrag, der »nur fünf includes« hat, kann bei 11 stehen, ohne dass jemand ihn angefasst hätte.
  • Zwei Lookups dürfen leer zurückkommen — das Void-Lookup-Limit. Tote includes und Tippfehler verbrauchen es schnell, und das Ergebnis ist derselbe permerror.

Wohin das Budget geht

je Anbieter · erneut geprüft Juli 2026
Mailgun · 5include:mailgun.org verschachtelt einen US- und einen EU-Block — und der US-Block verschachtelt zwei weitere. Ihr halbes Budget für einen einzigen Anbieter.
Salesforce · 2Ein include, das ein exists:-Makro je Absender umschließt — jedes Mal zwei Lookups, die sich durch Flattening nicht einsparen lassen.
Microsoft 365 · 1Flach — nur feste Bereiche hinter einem einzigen include. So sieht der Eintrag eines gut erzogenen Anbieters aus.
Google Workspace · 1Google verschachtelte früher drei Netzblock-includes — inzwischen ist _spf.google.com auf feste ip4/ip6-Bereiche aufgelöst. Ein Anbieter dieser Größe gibt keine Lookups aus, die er vermeiden kann.
a + mx, die Sie nicht brauchen · 2Wenn Ihr Webserver und Ihre MX-Hosts nie ausgehende Mail versenden, sind das zwei Lookups, die Ihnen nichts bringen — und sie stehen in jeder Vorlage.
ptr · 1 verschwendetAbgekündigt, unzuverlässig und kostet trotzdem einen Lookup. Die billigste Korrektur auf dieser Liste.
Faustregel: bei 8 Lookups prüfen, bei 9 einen streichen. Neue Tools kommen dazu, ohne dass jemand das Budget nachzählt.
Für Terminal-Nutzer

Was Sie selbst prüfen können

Ein dig liefert Ihren Eintrag. Der langsame Teil ist, jedes verschachtelte include von Hand aufzulösen.

Alle TXT-Einträge der Domain ansehendig +short TXT example.com
Den SPF-Eintrag isolieren (es sollte genau einer sein)dig +short TXT example.com | grep -c spf1
Ein include von Hand öffnendig +short TXT mailgun.org
…und die includes, die darin steckendig +short TXT _spf.mailgun.org
Den ganzen Baum rekursiv durchlaufen, jeden Lookup zählen, die Bereiche summieren# dafür gibt es keinen Einzeiler — das Budget versteckt sich in der Verschachtelung. ↑ genau das ist dieses Tool
FAQ

Häufige Fragen zu SPF

Geben Sie oben Ihre Domain ein. Wir holen ihre TXT-Einträge, bestätigen, dass genau einer mit v=spf1 beginnt (zwei sind ein sofortiger Fehlschlag — sie verschmelzen nicht, sie sterben beide), und werten dann jeden Mechanismus nach RFC 7208 aus: Jedes include wird rekursiv zu einem Baum aufgelöst, jeder DNS-Lookup gegen das Budget von 10 gezählt, die abschließende all-Richtlinie bewertet und jeder IP-Bereich, den Ihr Eintrag autorisiert, zu einer Liste summiert. Kostenlos, ohne Registrierung.

Empfänger, die SPF auswerten, führen pro Prüfung höchstens 10 DNS-abfragende Mechanismen aus (RFC 7208 §4.6.4). include, a, mx, ptr, exists und redirect zählen alle mit, auch die, die in den includes Ihrer Anbieter stecken. Bei Lookup #11 bricht die Auswertung mit permerror ab. Auf Ihrer Seite kommt keine Fehlermeldung an; DMARC behandelt Ihre Domain schlicht so, als hätte sie gar kein SPF veröffentlicht. Der Bruch kommt schleichend, eine Anmeldung nach der anderen — und kündigt sich nie an.

-all ist das Ziel: ablehnen, was nicht Ihnen gehört. ~all ist der Weg dorthin: »markieren, nicht zurückweisen«. Es ist die richtige Einstellung, solange Sie noch Absender entdecken — etwa das Rechnungstool, von dem niemand erzählt hat. Es ist außerdem die sichere Wahl, wenn eine verlorene legitime E-Mail Sie mehr kostet als eine gefälschte. Zwei Einschränkungen: Mit DMARC schrumpft der praktische Unterschied, weil DMARC unautorisierte Mail in beiden Fällen scheitern lässt. Und -all am Ende eines Eintrags, der über dem Lookup-Limit liegt, ist Strenge an einem längst toten Eintrag — der permerror gewinnt.

Nein — und der Fehlermodus ist bösartig. RFC 7208 sagt: Mehrere v=spf1-Einträge führen dazu, dass die Prüfung permerror liefert: nicht »der erste gewinnt«, nicht »sie verschmelzen« — beide werden ungültig. Meist passiert es ganz harmlos: ein Website-Plugin, ein Assistent des Mailanbieters oder ein zweiter Administrator »fügt SPF hinzu«, ohne den vorhandenen Eintrag zu bemerken. Die Korrektur ist eine Minute Arbeit: alle Mechanismen in einen einzigen Eintrag zusammenführen, den Rest löschen. Genau deshalb zählt dieses Tool zuerst Ihre Einträge, noch vor allem anderen.

Es beendet Ihren Eintrag mit »…und alle anderen kommen ebenfalls durch«. Jede IP im Internet wird damit zum autorisierten Absender Ihrer Domain: Ein Spammer, der Ihre Adresse fälscht, bekommt ein SPF-pass, und wenn Ihre DMARC-Richtlinie auf SPF-Ausrichtung setzt, kann diese gefälschte Mail auch DMARC bestehen — Ihre Authentifizierung bürgt jetzt für den Angreifer. Das ist tatsächlich schlimmer, als gar kein SPF zu veröffentlichen: »kein Eintrag« macht Empfänger misstrauisch, »+all« macht sie zuversichtlich. In freier Wildbahn taucht es als vermeintliche »Korrektur« für die Zustellbarkeit auf. Wenn dieses Tool eines findet, wird es nicht zimperlich sein.

Allein nicht. SPF prüft den Envelope-Absender (die Adresse aus der SMTP-Konversation), nicht das From:, das Ihr Leser sieht. Ein Fälscher kann SPF auf seiner eigenen Domain bestehen und trotzdem Ihre anzeigen. Diese Lücke zu schließen ist Aufgabe von DMARC: Es verlangt, dass das sichtbare From zu dem passt, was SPF oder DKIM geprüft hat. Und es sagt Empfängern, was zu tun ist, wenn das nicht der Fall ist. Der vollständige Stapel ist SPF + DKIM + DMARC, und dieses Tool stellt sicher, dass das SPF-Standbein steht — denn ein permerror hier nimmt den anderen beiden still die Grundlage.

Nach steigendem Aufwand: entfernen, was nichts sendeta und mx lassen sich bedenkenlos streichen, wenn Ihr Webserver und Ihre MX-Hosts nie ausgehende Mail versenden. ptr lässt sich immer entfernen. Tote Anbieter streichen — jedes include sollte zu einem Dienst gehören, den Sie noch bezahlen. Nach Subdomain trennen — lassen Sie Newsletter als news.yourdomain.com mit eigenem Eintrag und eigenem Budget senden. Als letztes Mittel Flattening: includes durch ihre festen ip4/ip6-Bereiche zu ersetzen kostet null Lookups. Aber es friert eine Kopie der Netze Ihrer Anbieter ein — wenn die umnummerieren, verrottet Ihr Eintrag stillschweigend. Flattening nur mit Werkzeugen oder einer Überwachung, die das nachprüfen.

Gratis-Tools sind erst der Anfang.
Uptimia hält Ihre Websites am Laufen.

Verfügbarkeit, SSL, Domain-Ablauf, Ladezeit, Transaktionen – aus 171+ Standorten weltweit überwacht. 30 Tage kostenlos.

30 Tage gratis keine Kreditkarte jederzeit kündbar kostenloser Plan nach dem Test
100.000+ überwachte Websites · DSGVO-konform