FCrDNS — wenn Reverse DNS und A-Record zusammenpassen müssen

Warum der PTR-Record allein nichts beweist

Ein Reverse-DNS-Eintrag lässt sich behaupten. Wer eine IP-Adresse gemietet hat, kontrolliert deren Reverse-Zone und kann dort eintragen, was er möchte — auch mail.bekannte-bank.example. Der PTR-Record allein ist deshalb eine Selbstauskunft, keine Bestätigung.

FCrDNS — forward-confirmed reverse DNS — schließt die Lücke, indem es den Weg zurückgeht:

1. Zur IP 203.0.113.10 den PTR-Record nachschlagen → mail.example.com
2. Für mail.example.com die A- und AAAA-Records nachschlagen
3. Prüfen, ob 203.0.113.10 darunter ist

Der entscheidende Punkt ist, dass die beiden Richtungen von verschiedenen Parteien kontrolliert werden. Die Reverse-Zone gehört dem Betreiber des Adressblocks, die Forward-Zone dem Inhaber der Domain. Stimmen beide überein, haben sich zwei unabhängige Stellen auf dieselbe Aussage festgelegt. Genau das macht FCrDNS zu einem Nachweis und den PTR-Record allein zu einer Behauptung.

Was AnalyzeMy.Email prüft

Die Prüfung läuft an drei Stellen, weil sie an jeder etwas anderes aussagt:

• Für die sendende IP — ergänzt den HELO/rDNS-Vergleich um die Rückrichtung.
• Für jeden MX-Host der Domain, mit passendem Abfragetyp: A-Records werden gegen die IPv4-Adresse geprüft, AAAA gegen die IPv6-Adresse.
• Für jede aus dem SPF-Record aufgelöste IP — dort zeigt sich, ob die autorisierten Adressen überhaupt zu benannten Mailservern gehören.

Nachgeschlagen wird über den eigenen Resolver mit gesetztem Zeitlimit, nicht über die Namensauflösung des Betriebssystems — die lässt sich nicht zuverlässig begrenzen und blockiert im Fehlerfall die gesamte Analyse.

Was ein Fehlschlag bedeutet

Große Anbieter behandeln fehlendes oder nicht bestätigtes FCrDNS als hartes Kriterium. Google und Microsoft nennen es ausdrücklich in ihren Anforderungen an sendende Systeme; manche Server lehnen ohne gültiges FCrDNS bereits die Verbindung ab, andere erhöhen den Spam-Score deutlich.

Die häufigen Ursachen sind ernüchternd banal:

• Kein PTR gesetzt — bei vielen Cloud-Anbietern ist das der Auslieferungszustand.
• PTR zeigt auf den Standardnamen des Providers, etwa ip-203-0-113-10.hoster.example, für den es keinen passenden A-Record gibt.
• PTR gesetzt, A-Record vergessen — die Rückrichtung existiert, die Hinrichtung nicht.
• Nur IPv4 gepflegt — der Server sendet über IPv6, und dort fehlt der PTR-Record vollständig.

Richtig einrichten

• PTR beim Betreiber des Adressblocks setzen — das ist der Hoster, nicht der DNS-Anbieter deiner Domain. Meist gibt es dafür ein eigenes Feld in der Serververwaltung.
• Denselben Namen wie im HELO verwenden. HELO-Name, PTR-Record und A-Record sollten identisch sein, dann stimmt alles auf einmal.
• Beide Adressfamilien pflegen, sobald der Server auch über IPv6 sendet.
• Nach der Änderung warten: Reverse-Zonen tragen oft lange TTLs, und viele Prüfer arbeiten zusätzlich mit eigenem Cache.