auth.spf.ptr_mechanism

Veralteter ptr-Mechanismus

Was wir prüfen

Wir durchsuchen den SPF-Eintrag nach dem ptr-Mechanismus (ptr oder ptr:domain). RFC 7208 §5.5 hält fest, dass dieser Mechanismus nicht veröffentlicht werden sollte — er ist langsam, über Resolver hinweg unzuverlässig und belastet die .arpa-Reverse-DNS-Nameserver stark.

Was dieses Ergebnis bedeutet

Dein SPF-Eintrag verwendet ptr. Zur Auswertung muss ein Empfänger die verbindende IP per Reverse-DNS zu einem Hostnamen auflösen und diesen dann per Forward-Abfrage bestätigen — ein fragiler Mehrfach-Abfrage-Vorgang. Viele Anbieter unterstützen ihn kaum noch, und schon ein kurzes Reverse-DNS-Timeout kann legitime Mail an SPF scheitern lassen.

Warum das wichtig ist

• Unzuverlässige Ergebnisse. Der Mechanismus hängt an Reverse-DNS, das du oft nicht kontrollierst; ein langsamer oder fehlender PTR kann dein SPF-Ergebnis unvorhersehbar kippen.
• Abfrage-Budget. ptr zählt zu den Termen gegen das 10-Abfragen-Limit, und jede Auswertung kann mehrere Abfragen nachziehen — das Budget ist schnell verbraucht.
• Bessere Optionen. Nach Jahren Praxis kommt der Standard zum Schluss, dass ptr überflüssig ist; direkte ip4:/ip6: oder include: sind schneller und verlässlich.

So behebst du das

1. Ersetze ptr durch explizite Mechanismen. Für Server mit statischen Adressen die IPs direkt listen (null Abfragen); für Drittanbieter deren include: verwenden:

   example.com.  IN  TXT  "v=spf1 ip4:203.0.113.0/24 include:_spf.dein-anbieter.example -all"
   

2. Entferne den ptr-Term ganz, sobald die Ersatzmechanismen dieselben Absender abdecken.

So fließt es in die Bewertung ein

Ein veralteter ptr-Mechanismus kostet 5 Punkte in der Authentifizierungskategorie. Das vollständige Scoring-Modell steht in der Bewertungsmethodik.

Evidenzbeispiel

$ dig +short TXT example.com
"v=spf1 ptr ~all"
        ^^^ RFC 7208 §5.5: „SHOULD NOT be published"

Referenzen

• RFC 7208 — Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1