Warum Empfänger darauf bestehen
Ein PTR-Eintrag setzt voraus, dass jemand Kontrolle über den IP-Block hat — er wird beim Betreiber der Adresse gesetzt, nicht von dem, der sie gerade benutzt. Genau deshalb ist er ein brauchbares Mindestsignal: Wer aus einem gekaperten Endgerät oder einem beliebigen Cloud-Container heraus versendet, hat ihn typischerweise nicht.
Google, Microsoft und die meisten großen Empfänger lehnen ohne PTR schon beim Verbindungsaufbau ab — noch bevor SPF, DKIM oder der Inhalt betrachtet werden.
PTR allein genügt nicht: FCrDNS
Geprüft wird in beide Richtungen. Der Kreis muss sich schließen:
Zeigt der PTR auf einen Namen, dessen A-Record woanders hinführt, gilt das als nicht bestätigt (FCrDNS fail) und wird von vielen Empfängern wie ein fehlender Eintrag behandelt. Beide Richtungen müssen zusammenpassen.
Wo der Eintrag gesetzt wird
Das ist der Punkt, an dem die meisten hängenbleiben: Der PTR gehört nicht in deine Domain-Zone. Er liegt in der in-addr.arpa-Zone des IP-Blocks und wird deshalb bei dem verwaltet, von dem du die IP hast — Hoster, Rechenzentrum oder Provider. Bei den meisten steht dafür ein Feld im Kundenportal, sonst genügt ein kurzer Support-Auftrag.
Der A-Record für denselben Namen dagegen liegt bei dir. Beide Seiten müssen gesetzt sein.
Dazu passend: der HELO-Name
Viele Empfänger vergleichen zusätzlich, ob der Name, mit dem sich der Server im HELO/EHLO vorstellt, zum PTR passt. Am saubersten verwendest du überall denselben voll qualifizierten Namen — im HELO, im PTR und im A-Record. Ein Standard-HELO wie localhost.localdomain ist ein eigenständiger Ablehnungsgrund.
Geduld beim Prüfen
Reverse-DNS-Zonen werden von vielen Resolvern lange zwischengespeichert. Nach dem Setzen kann es Stunden dauern, bis alle Empfänger den Eintrag sehen — eine unmittelbare Gegenprobe sagt daher wenig aus.