Stand: Juli 2026

Zusammenfassung: Der ptr-Mechanismus in einem SPF-Record versucht über Reverse-DNS-Abfragen zu prüfen, ob ein sendender Server autorisiert ist. Laut aktuellem Standard verbraucht er jedoch zu viele Ressourcen und gilt als unzuverlässig, weshalb er nicht mehr veröffentlicht werden soll.

In den Anfangszeiten des Sender Policy Frameworks (SPF) schien der ptr-Mechanismus eine elegante Lösung zu sein, um alle Server einer Domain automatisch zu autorisieren. Heute rät der Standard von dieser Methode jedoch ausdrücklich ab.

Wie der ptr-Mechanismus theoretisch arbeitet

Wenn ein SPF-Record einen ptr-Mechanismus enthält:

v=spf1 ptr ~all

führt der empfangende Mailserver eine mehrstufige Reverse-DNS-Prüfung durch. Er nimmt die IP-Adresse des einliefernden Servers und fragt im DNS nach dem zugehörigen PTR-Record (dem Reverse-DNS-Hostnamen). Anschließend löst er diesen gefundenen Hostnamen wiederum per A- oder AAAA-Abfrage auf, um zu prüfen, ob die ursprüngliche IP-Adresse darin enthalten ist und ob der Hostname zur geschützten Domain gehört.

Warum der Standard von ptr abrät

Die Spezifikation in RFC 7208 lässt keinen Zweifel daran, wie mit diesem Mechanismus umzugehen ist: Der Mechanismus sollte nicht veröffentlicht werden (SHOULD NOT be published).

Der Standard begründet diese Empfehlung mit mehrjährigen Praxiserfahrungen:

  1. Langsamkeit und Unzuverlässigkeit: Der Mechanismus ist langsam und bei DNS-Fehlern weitaus weniger zuverlässig als andere Mechanismen. Schon ein kurzes Timeout bei der Reverse-Auflösung kann dazu führen, dass legitime E-Mails abgewiesen werden.
  2. Hohe Last auf Namensservern: Die aufwendigen Reverse-Abfragen erzeugen eine erhebliche Last auf den globalen .arpa-Namensservern.
  3. Strenge Voraussetzungen: Falls ptr dennoch verwendet wird, müssen für alle Hosts der Domain korrekte PTR-Einträge existieren und der Mechanismus sollte erst als einer der letzten im Record geprüft werden.

Das klare Fazit des RFC lautet, dass ptr nach jahrelanger SPF-Erfahrung überflüssig ist und stattdessen zuverlässigere Alternativen genutzt werden sollten.

Das 10-Lookup-Limit und permerror

Neben der Unzuverlässigkeit belastet der ptr-Mechanismus auch das DNS-Lookup-Limit massiv. Laut RFC 7208 verursachen die Mechanismen include, a, mx, ptr und exists sowie der Modifier redirect bei der Auswertung DNS-Abfragen.

Da SPF-Implementierungen die Gesamtzahl dieser Abfragen pro Prüfung strikt auf maximal 10 Lookups begrenzen müssen, bricht die Auswertung bei einer Überschreitung mit einem permanenten Fehler (permerror) ab. Weil eine einzige ptr-Prüfung intern gleich mehrere DNS-Abfragen anstößt, führt ihr Einsatz häufig zu einer sofortigen Überschreitung des 10-Lookup-Budgets. Zudem darf eine Domain niemals mehrere separate SPF-Records veröffentlichen, da auch dies unverzüglich zu einem permerror führt.

Zuverlässigere Alternativen

Statt ptr solltest du auf direkte und performante Mechanismen setzen:

  • ip4 und ip6: Wenn du feste IP-Adressen oder Netzbereiche nutzt, sind direkte IP-Mechanismen ideal – sie erzeugen keine DNS-Lookups und verbrauchen kein Budget.
  • include: Wenn du externe Versanddienste anbindest, verweist ein sauber definierter include direkt auf deren gepflegte Infrastruktur.

Konfiguration bereinigen und prüfen

Wenn in deinem SPF-Record noch alte ptr-Anweisungen schlummern, solltest du sie entfernen und deine Konfiguration mit dem kostenlosen MXAudit-Scanner überprüfen. Das Tool warnt dich vor veralteten Mechanismen und zählt deine verbleibenden DNS-Lookups präzise nach.

Weitere Informationen zur Modernisierung deiner E-Mail-Authentifizierung findest du im SPF-Hub und in Leitfäden wie SPF bei IONOS einrichten.