Smarte, fokussierte E-Mails.
Perfekte Cross-Platform-Mails für mehr Ordnung – so können Sie sich aufs Wesentliche konzentrieren.
💡 Reverse DNS Lookup: Der Prozess, bei dem eine IP-Adresse zurück in einen Domainnamen aufgelöst wird – das Gegenteil davon, wie DNS normalerweise funktioniert. Bei E-Mails ist es die Art und Weise, wie empfangende Server prüfen, ob eine sendende IP-Adresse tatsächlich zu der Domain gehört, die sie zu repräsentieren vorgibt. Normales DNS geht von Domain zu IP. Reverse DNS geht von IP zurück zu Domain. Beide Richtungen müssen übereinstimmen.
Wahrscheinlich nicht direkt, aber es lohnt sich zu wissen, warum.
Wenn Sie E-Mails über Gmail, Google Workspace, Outlook oder Microsoft 365 versenden, wird Reverse DNS automatisch von Google und Microsoft auf ihren eigenen sendenden IPs gehandhabt. Sie fassen es nicht an. Dasselbe gilt für gemeinsam genutzte IPs auf Plattformen wie Mailchimp oder Klaviyo. Diese ESPs verwalten PTR-Einträge für die IP-Adressen, von denen ihre Server senden.
Reverse DNS wird dann zu Ihrem Problem, wenn Sie von einer dedizierten IP-Adresse senden (über einen Dienst wie SendGrid oder Mailgun) oder Ihren eigenen Mailserver auf einem VPS oder einer Cloud-Instanz betreiben. In diesen Situationen wird der PTR-Eintrag für Ihre IP nicht automatisch gesetzt. Sie müssen ihn konfigurieren. Und wenn er fehlt oder falsch konfiguriert ist, leidet Ihre E-Mail-Zustellbarkeit.
Der praktische Test: Wenn Ihre E-Mails im Spam landen und Ihr DKIM, SPF und DMARC-Eintrag alle bestehen, ist ein fehlender oder defekter PTR-Eintrag der logische nächste Punkt, den Sie prüfen sollten.
Der Prozess wird Forward-Confirmed reverse DNS (FCrDNS) genannt. Das passiert, wenn Ihre E-Mail bei einem empfangenden Server ankommt.
Der empfangende Server nimmt Ihre sendende IP-Adresse und fragt beim DNS den zugehörigen PTR-Eintrag (Pointer) ab. Diese Abfrage geht in eine spezielle DNS-Zone namens in-addr.arpa. Wenn ein PTR-Eintrag konfiguriert ist, gibt die Abfrage einen Hostnamen zurück, etwa mail.yourbusiness.com.
Der empfangende Server führt dann einen regulären Forward-DNS-Lookup auf diesen Hostnamen durch, um zu bestätigen, dass er sich wieder auf die ursprüngliche IP auflöst. Wenn die IP übereinstimmt, besteht die Prüfung. Wenn sich der Hostname auf eine andere IP auflöst oder überhaupt kein PTR-Eintrag vorhanden ist, wirkt der Absender nicht vertrauenswürdig.
Genau darum geht es bei dieser bidirektionalen Verifizierung. Jeder kann behaupten, von yourbusiness.com zu senden. Weit weniger Leute können sowohl den PTR-Eintrag als auch das Forward-DNS so manipulieren, dass sie übereinstimmen. Seit Google und Yahoo 2024 die Anforderungen für Massenversender verschärft haben, gibt Gmail nun einen bestimmten Fehler (421 4.7.23) für IPs ohne gültigen PTR-Eintrag zurück. Für jeden, der ein nennenswertes Volumen versendet, ist das nicht mehr optional.
Fehlendes oder nicht übereinstimmendes Reverse DNS ist eines der heimtückischsten Zustellbarkeitsprobleme. Es erzeugt nicht immer einen eindeutigen Bounce. Ihre E-Mails landen möglicherweise einfach stillschweigend und ohne Erklärung im Spam.
Bevor Sie versuchen, etwas zu beheben, prüfen Sie, ob ein PTR-Eintrag existiert und ob er korrekt ist.
MXToolbox: Gehen Sie auf mxtoolbox.com/ReverseLookup.aspx und geben Sie die IP-Adresse Ihres Mailservers ein. Es gibt den PTR-Eintrag zurück oder meldet, wenn keiner existiert.
Kommandozeile (Mac/Linux/Windows):
nslookup [your IP address]
Oder auf Mac/Linux:
dig -x [your IP address]
Die Ausgabe sollte einen PTR-Eintrag zeigen, der auf den Hostnamen Ihres Mailservers verweist. Wenn sie nichts zeigt oder auf etwas Generisches wie den Standard-Hostnamen eines Cloud-Anbieters verweist (ec2-203-0-113-25.compute-1.amazonaws.com), ist das ein Problem, das sich zu beheben lohnt.
Hier ist das entscheidende Detail, das die meisten Leute falsch machen: PTR-Einträge werden von demjenigen kontrolliert, dem die IP-Adresse gehört (Ihrem Hosting- oder VPS-Anbieter, nicht Ihrem Domain-Registrar).
Sie können bei Cloudflare oder GoDaddy keinen PTR-Eintrag setzen. Sie setzen ihn über DigitalOcean, Vultr, Hetzner, AWS, Linode oder wo auch immer die IP Ihres Mailservers liegt.
Allgemeiner Ablauf (selbst gehosteter Mailserver):
Damit Ihr Setup FCrDNS besteht, müssen Sie außerdem bestätigen, dass der Hostname Ihres Mailservers einen A-Eintrag hat, der sich wieder auf dieselbe IP auflöst. Beide Richtungen müssen funktionieren.
Wenn Sie eine dedizierte IP über einen ESP nutzen: SendGrid, Mailgun und ähnliche Dienste haben in ihren Dashboards eigene Abläufe zur Reverse-DNS-Einrichtung. Bei SendGrid finden Sie es unter Settings > Sender Authentication > Reverse DNS. Sehen Sie sich den Reverse-DNS-Leitfaden von SendGrid für die vollständige Anleitung an. Sie generieren die Einträge und führen Sie durch deren Veröffentlichung.
Wenn Sie eine gemeinsam genutzte IP über einen ESP nutzen: Der Anbieter kümmert sich um die PTR-Einträge für gemeinsam genutzte IPs. Sie müssen nichts konfigurieren.
Vermeiden Sie generische Cloud-Hostnamen. Ein Standard-PTR von einem Cloud-Anbieter signalisiert „generische VPS-Instanz“ statt „verwalteter Mailserver“. Empfangende Server behandeln das als Warnsignal. Ersetzen Sie ihn durch einen benutzerdefinierten Hostnamen, der zu Ihrer Domain passt.
PTR ist eine Schicht, nicht der gesamte Stack. Ein sauberer PTR hilft, eine grundlegende Sende-Legitimität zu etablieren, aber er wirkt zusammen mit DKIM, SPF und DMARC, nicht anstelle von ihnen. Ein perfekter PTR ohne DKIM hat trotzdem Schwierigkeiten. Bringen Sie zuerst alle drei Authentifizierungsschichten an ihren Platz; überprüfen Sie dann Ihren PTR.
Überprüfen Sie ihn nach jeder Infrastrukturänderung erneut. Wenn Sie auf einen neuen Server migrieren, eine neue IP erhalten oder den Hosting-Anbieter wechseln, folgt Ihr PTR-Eintrag nicht automatisch. Er muss für die neue IP neu konfiguriert werden. Leicht zu vergessen. Es lohnt sich, es zu prüfen.
Ein PTR-Eintrag pro IP, der auf Ihren sendenden Hostnamen verweist. Ihr PTR-Eintrag sollte sich auf denselben Hostnamen auflösen, den Ihr SMTP-Server in SMTP-Kommunikationen ankündigt (der HELO/EHLO-Befehl). Nicht-Übereinstimmungen wirken für Spamfilter inkonsistent.