Was ist der SPF-ptr-Mechanismus – und warum steht er noch in 950.631 Einträgen? (2026)

Q: Was sollte ich stattdessen verwenden?

ip4:/ip6:-Blöcke für Server, die Sie kontrollieren, oder das dokumentierte include: Ihres Anbieters. Beide sind deterministisch, schnell und zuverlässig – alles, was ptr nicht ist.

Q: Zählt ptr auf das SPF-Limit von 10 Lookups?

Ja – jedes ptr kostet mindestens einen der zehn DNS-Lookups, die ein Empfänger durchführt, bevor er mit einem PermError aufgibt. Bei Einträgen, die bereits mit include:-Mechanismen vollgepackt sind, kann der tote Mechanismus derjenige sein, der Sie über die Grenze schiebt.

Veröffentlicht 2026-07-03

Zahlen mit Stand 2026-06-29 · Methodik v7. Aggregierter Zensus über 261 Millionen benotete Domains. Alle Zahlen sind aggregiert – niemals der Eintrag eines einzelnen Unternehmens. Siehe wie wir benoten.

ptr ist ein SPF-Mechanismus, der Absender per Reverse-DNS-Lookup autorisiert – und der SPF-Standard selbst sagt seit 2014 “nicht verwenden”. 12 Jahre später veröffentlichen ihn noch immer 950.631 Domains. Das ist grob 1 von 146 der 139 Millionen SPF-Einträge im Internet, die einen Mechanismus tragen, den die Spezifikation abkündigte, noch bevor manche dieser Domains überhaupt registriert waren.

Was ptr eigentlich leisten sollte

ptr sagt: “Akzeptiere Mail von jedem Server, dessen Reverse-DNS auf meine Domain zurückführt.” Das klingt elegant – keine IP-Listen zu pflegen. In der Praxis erfordert es, dass der Empfänger einen Reverse-Lookup auf die verbindende IP durchführt und dann jeden zurückgelieferten Hostnamen per Forward-Lookup bestätigt. RFC 7208 (§5.5) kündigte ihn mit klaren Worten ab: Der Mechanismus sei “langsam, in Fällen von DNS-Fehlern nicht so zuverlässig wie andere Mechanismen und stellt eine große Ressourcenanforderung an die .arpa-Nameserver” – und weist an, dass er “NICHT verwendet werden SOLLTE.”

Warum er 2026 immer noch eine Falle ist

Drei Gründe, warum ein vor 12 Jahren abgekündigter Mechanismus noch immer eine Rolle spielt:

Er verbrennt Ihr Lookup-Budget. Jedes ptr zählt gegen die harte Obergrenze von SPF von 10 DNS-Lookups pro Prüfung – das Limit, das, einmal überschritten, den gesamten Eintrag mit einem PermError ungültig macht. Ein Mechanismus, der nichts Zuverlässiges leistet, kostet Sie trotzdem das Budget, das Ihre echten include:-Mechanismen brauchen.
Er versagt unvorhersehbar. Reverse-DNS ist die am wenigsten gepflegte Ecke der meisten Netzwerke. Wenn der ptr-Lookup abläuft oder die Forward-Bestätigung fehlschlägt, verliert Ihre legitime Mail den SPF-Pass, auf den sie sich verlassen hat.
Manche Empfänger überspringen ihn ganz. Weil der Standard ihn abkündigt, ignorieren manche Implementierungen ptr einfach – die Absender, die er autorisieren sollte, waren also von vornherein nie geschützt.

Woher er kommt

Fast niemand wählt ptr heute bewusst. Er kommt durch Vererbung: eine 2009 geschriebene Einrichtungsanleitung, eine aus einer alten Serverkonfiguration kopierte Vorlage, ein “funktionierender” Eintrag, der durch drei Hosting-Umzüge unverändert mitgeschleppt wurde. Das ist das Muster, das unser Zensus über jeden abgekündigten-aber-vorhandenen Mechanismus hinweg sieht: alter Rat stirbt nicht, er wird per Copy-Paste weitergereicht. Die Domains, die ptr tragen, sind nicht nachlässig – sie folgen Anweisungen, die vor 12 Jahren ausgemustert wurden.

Wie man es behebt – kostenlos, fünf Minuten

Finden Sie Ihren SPF-Eintrag (dig TXT ihredomain.com oder kostenlos prüfen).
Wenn er ptr enthält, ermitteln Sie, welche Server sich darauf verlassen haben.
Ersetzen Sie das ptr durch die präzise Form: einen ip4:/ip6:-Block für Server, die Sie kontrollieren, oder das include:, das Ihr Anbieter dokumentiert.
Wenn Sie schon dabei sind, prüfen Sie, dass der Eintrag mit einem echten Qualifier endet – siehe ~all vs. -all.

Häufig gestellte Fragen

Was bedeutet ptr in einem SPF-Eintrag? Es autorisiert jeden Server, dessen Reverse-DNS auf Ihre Domain zurückführt. RFC 7208 §5.5 kündigte es 2014 als langsam und unzuverlässig ab und sagt, es SOLLTE NICHT verwendet werden – dennoch veröffentlichen es 950.631 Domains noch immer mit Stand 2026-06-29.

Ist der SPF-ptr-Mechanismus jemals gültig? Er wird noch immer geparst, und manche Empfänger werten ihn noch aus – aber der Standard rät in allen Fällen davon ab, manche Empfänger ignorieren ihn, und er verbraucht einen Ihrer zehn DNS-Lookups. Es gibt keine moderne Konfiguration, in der ptr die richtige Antwort ist.

Was sollte ich stattdessen verwenden? ip4:/ip6:-Blöcke für Server, die Sie kontrollieren, oder das dokumentierte include: Ihres Anbieters. Beide sind deterministisch, schnell und zuverlässig – alles, was ptr nicht ist.

Zählt ptr auf das SPF-Limit von 10 Lookups? Ja – jedes ptr kostet mindestens einen der zehn DNS-Lookups, die ein Empfänger durchführt, bevor er mit einem PermError aufgibt. Bei Einträgen, die bereits mit include:-Mechanismen vollgepackt sind, kann der tote Mechanismus derjenige sein, der Sie über die Grenze schiebt.

Prüfen Sie Ihren Eintrag auf Geister

Ein vor 12 Jahren abgekündigter Mechanismus, der noch immer in Ihrem DNS sitzt, ist genau die Art von Sache, nach der niemand sucht. Das Nachschauen dauert eine halbe Minute.

Prüfen Sie Ihre Domain → · SPF beheben → · Zwei SPF-Einträge = keiner → · Das SPF-Reifegradmodell → · Nur aggregierte Daten. Daten werden in der EU gespeichert und verarbeitet.