Warum weist Gmail eine E-Mail ab, obwohl SPF und DKIM beide erfolgreich validiert werden? Das Dashboard Ihres E-Mail-Tools zeigt „gesendet“ an. Ein Teil Ihrer Gmail-Empfänger erhält die Nachricht dennoch nie. Die Erklärung steckt in einem Code, den kaum jemand zu lesen weiß: 550 5.7.25.
Fehler 550 5.7.25 bedeutet: Die versendende IP hat keinen gültigen PTR-Eintrag (Reverse DNS), oder dieser PTR löst in umgekehrter Richtung nicht zur selben IP auf (Forward-Confirmed Reverse DNS, FCrDNS). 3 DNS-Prüfungen genügen, um herauszufinden, welche der beiden Ursachen bei Ihnen vorliegt. Die Korrektur hängt anschließend davon ab, wer die Reverse-Zone kontrolliert: der Hoster bei einem VPS oder Dedicated Server, der Anbieter bei einem ESP.
Was der Code 550 5.7.25 wirklich bedeutet
Wenn Ihr Server Gmail kontaktiert, beginnt der Austausch mit einem EHLO und dann einem MAIL FROM, das den Absender ankündigt. Gmail prüft an diesem Punkt die Netzwerkidentität der Quell-IP, noch bevor der Inhalt der Nachricht gelesen wird. Der Code 5.7.25 ist ein Enhanced Status Code. Die Klasse 5.7.x umfasst Ablehnungen im Zusammenhang mit Sicherheit und Authentifizierung. Das Suffix .25 verweist präzise auf ein Reverse-DNS-Problem. Diese Genauigkeit ist ein Vorteil: Eine generische Ablehnung wie der SMTP-Fehler 554 5.0.0 lässt 5 mögliche Ursachen offen, während 5.7.25 nur eine einzige benennt.
« 550-5.7.25 [IP] The IP address sending this message does not have a PTR record setup, or the corresponding forward DNS entry does not match the sending IP. As a policy, Gmail does not accept messages from IPs with missing PTR records. »
Das ist der exakte Text, den der empfangende Server zurückgibt. Dabei sind 2 DNS-Einträge im Spiel. Der PTR (Pointer) übersetzt eine IP in einen Hostnamen: das ist die umgekehrte Abfrage. Der A-Eintrag (oder AAAA bei IPv6) macht das Gegenteil. Er übersetzt einen Hostnamen in eine IP. Gmail verlangt, dass beide übereinstimmen: Der PTR Ihrer IP muss auf einen Hostnamen zeigen, und dieser Hostname muss wieder zur selben IP auflösen. Ohne diesen geschlossenen Kreislauf landet die Nachricht mit dem Code 550 5.7.25 im NDR (Non-Delivery Report) Ihres Servers, noch bevor sie überhaupt auf Spam geprüft wird.
Warum diese Ablehnung seit Dezember 2025 häufiger auftritt
Der Code 5.7.25 existiert seit mehreren Jahren. Ablehnungen waren vor Ende 2025 selten. Laut Spam Resource (Dezember 2025) hat Google die Durchsetzung dieser Regel verschärft: IP-Adressen mit unvollständigem oder inkonsistentem Reverse DNS, die zuvor durch die Maschen fielen, werden inzwischen systematischer blockiert.
Diese Verschärfung folgt einem Trend, der im Februar 2024 begann, als Gmail und Yahoo anfingen, gemeinsame Anforderungen an Absender durchzusetzen, mit einer Spam-Beschwerdequote von maximal 0,3 %. Unser Artikel über den Anstieg der SMTP-Ablehnungen und die Absenderanforderungen von Gmail beschreibt sämtliche dieser Schwellenwerte im Detail. Der PTR ist nur einer der Kontrollpunkte dieser Liste, aber einer der wenigen, die die Verbindung blockieren, noch bevor der Inhalt der Nachricht überhaupt geprüft wird.
Den PTR mit 3 Prüfungen diagnostizieren
Bevor Sie irgendjemanden kontaktieren, prüfen Sie der Reihe nach 3 Dinge. Jede schließt eine mögliche Ursache aus.
- Prüfen Sie den IPv4-PTR der IP, die die Nachricht tatsächlich versendet, nicht die IP Ihres Webservers, sondern die ausgehende SMTP-IP. Der Bounce liefert sie Ihnen, sie erscheint in eckigen Klammern direkt nach dem Code 550-5.7.25. Führen Sie
dig -x 203.0.113.10 +shortvon einem beliebigen Rechner aus. Unter Windows liefertnslookup 203.0.113.10dieselbe Antwort. Eine leere Antwort weist auf einen fehlenden PTR hin, also Ursache Nr. 1. - Prüfen Sie den IPv6-PTR mit
dig -x 2001:db8::25 +short, falls Ihr Server über dieses Protokoll senden kann. Das ist der Punkt, den die meisten Checklisten auslassen. Ein Server mit IPv6-Konnektivität öffnet die Verbindung zu Gmail standardmäßig über IPv6, da die MX-Einträge von Gmail AAAA-Records veröffentlichen. Die offiziellen Google-Richtlinien für Absender sind an dieser Stelle eindeutig: Ein IPv6-Autorisierungsfehler stammt meist von einem PTR, der nur in IPv4 existiert. Ein einwandfreier IPv4-PTR bei gleichzeitig fehlendem IPv6-PTR führt daher dazu, dass genau diese Verbindungen abgelehnt werden, je nach Fall mit 550 5.7.25 oder mit dem für IPv6-Anforderungen reservierten 550 5.7.1. - Prüfen Sie den Forward Match: Der vom PTR zurückgegebene Hostname muss über einen A-Eintrag (oder AAAA) verfügen, der wieder auf dieselbe Ausgangs-IP zeigt. Nehmen Sie den Hostnamen aus dem vorherigen Schritt und führen Sie
dig A mail.votredomaine.fr +shortaus, danachdig AAAA mail.votredomaine.fr +shortfür IPv6. Die zurückgegebene IP muss exakt der Ausgangs-IP entsprechen. Schon eine kleine Abweichung an dieser Stelle bricht den FCrDNS.
Die Schritt-für-Schritt-Details dieser Vorgänge, inklusive der Befehle, sind in unserem Leitfaden zur Reverse-DNS-Abfrage beschrieben.
Korrigieren, je nachdem wer Ihr Reverse DNS kontrolliert
Ein PTR lässt sich niemals über Ihr Domain-Verwaltungspanel ändern: Er gehört dem Eigentümer des IP-Adressblocks. Die Vorgehensweise unterscheidet sich grundlegend danach, wem diese Reverse-Zone gehört.
| Hosting-Typ | Wer kontrolliert den PTR | Vorgehensweise | Propagationszeit |
|---|---|---|---|
| VPS oder Dedicated Server (OVH, Hetzner, DigitalOcean, AWS EC2) | Der Hoster, über sein Netzwerkpanel oder ein Support-Ticket | Das Droplet oder die Instanz mit dem gewünschten Hostnamen umbenennen (DigitalOcean), den PTR über die Elastic-IP-Einstellungen anfordern (AWS) oder ihn im Netzwerkbereich des Kundenpanels hinzufügen (Hetzner, OVH) | Wenige Minuten bis wenige Stunden |
| Shared Hosting | Ausschließlich der Hoster, meist über einen gemeinsam genutzten IP-Pool | Ein Support-Ticket öffnen und dabei die genaue ausgehende IP sowie den gewünschten Hostnamen angeben | Unterschiedlich, teilweise mehrere Tage je nach Anbieter |
| ESP oder E-Mail-SaaS (Brevo, Mailgun, SendGrid, Google Workspace) | Der Anbieter, auf seinen eigenen IPs | Auf Ihrer Seite ist beim PTR nichts zu tun: Prüfen Sie stattdessen das Alignment von SPF, DKIM und DMARC für die Absenderdomain | Nicht zutreffend, bereits erledigt |
Bei AWS wird der PTR über die EC2-Konsole (Bereich Elastic IP) angefordert oder per Ticket, wenn die IP nicht elastisch ist. Bei DigitalOcean genügt es, das Droplet mit dem gewünschten FQDN umzubenennen: Der PTR aktualisiert sich automatisch. Prüfen Sie anschließend mit einem Testversand, ob der A/PTR-Kreislauf tatsächlich geschlossen ist. Die Propagation dauert meist zwischen wenigen Minuten und wenigen Stunden. Planen Sie ein Zeitfenster von 2 bis 4 Stunden ein, bevor Sie erneut testen, falls die erste Prüfung noch fehlschlägt.
Die Falle des generischen PTR, der die technische Prüfung besteht
Ein Fall kommt häufig vor: Der PTR existiert und löst sogar in beide Richtungen korrekt auf. Die Ablehnung besteht trotzdem weiter. Die häufigste Ursache ist ein generischer PTR, der automatisch vom Hoster vergeben wurde, etwa vom Typ 123-45-67-89.provider.com.
Technisch besteht dieser PTR die FCrDNS-Prüfung: Er zeigt auf einen Hostnamen, und dieser Hostname zeigt wieder auf dieselbe IP. Das Problem liegt woanders. Eine IP, die ausschließlich für generisches Hosting genutzt wurde, ohne eigene Versandhistorie und ohne individuellen Hostnamen, entspricht dem Profil kompromittierter Server, die für Massenspam verwendet werden. Gmail bewertet dieses Signal als schwach, selbst wenn der technische Kreislauf geschlossen ist. Die Korrektur besteht darin, einen individuellen PTR anzufordern, der den Domainnamen oder die Subdomain aufgreift, die für den Versand tatsächlich genutzt wird, zum Beispiel mail.votredomaine.fr statt des Standard-Hostnamens des Servers.
Ein weiterer häufiger Einwand: „Ich nutze eine E-Mail-Plattform, dieses Problem betrifft mich nicht.“ Das stimmt für den PTR selbst: Große ESPs verwalten ihre eigenen IPs und ihr Reverse DNS. Aber dasselbe Symptom, eine Gmail-Ablehnung, obwohl scheinbar alles konfiguriert ist, kann auch von einer Absenderdomain stammen, die beim DKIM-Alignment falsch eingerichtet ist, ein Problem, das sich vom PTR unterscheidet. Zu prüfen, welche der beiden Ursachen wirklich vorliegt, erspart Ihnen, Zeit mit dem falschen Ansprechpartner zu verlieren. Ein aggregierter DMARC-Bericht zeigt, welche Versandquelle beim Alignment scheitert.
Nach der PTR-Korrektur prüfen, ob der Rest Ihre Absenderreputation nicht belastet
Die Korrektur des PTR löst die unmittelbare SMTP-Ablehnung. Für den weiteren Verlauf garantiert das nichts. Die Absenderreputation (sender reputation) bei Gmail baut sich aus mehreren kumulierten Signalen auf: der Hard-Bounce-Rate, der Beschwerdequote (complaint rate) und der Versandhistorie der IP. DNS-Konformität allein reicht dafür nicht aus.
Bei einer IP in einem gemeinsam genutzten Pool spielt sich dieses Zusammenspiel zu mehreren ab: Wenn ein anderer Kunde desselben Pools eine hohe hard bounce-Rate erzeugt, leidet Ihre eigene deliverability darunter, selbst mit einem einwandfreien PTR. Bei einer dedizierten IP in der Phase des IP warm-up wiegt jeder Versand an eine ungültige oder inaktive Adresse schwerer auf der Vertrauenskurve, die Gmail aufbaut, weil das Referenzvolumen noch gering ist.
„E-Mails vor dem Versand zu verifizieren kostet Geld, da kann man auch nachträglich filtern.“ Gerade hier zählt die Reihenfolge: Ein von Gmail nach dem Versand registrierter hard bounce beschädigt die Reputation der IP bereits in dem Moment, in dem er auftritt. Eine vor dem Versand entfernte ungültige Adresse hinterlässt keine negative Spur. Eine Stichprobe Ihrer nächsten Liste vor der Kampagne zu verifizieren, zeigt den Unterschied zwischen beiden Ansätzen konkret an der tatsächlichen Hard-Bounce-Rate.
Der Gmail Postmaster (Google Postmaster Tools) bleibt die zuverlässigste Quelle, um diese Reputation langfristig zu verfolgen, sowohl auf IP- als auch auf Domain-Ebene. Unser Leitfaden zur Reputation einer IP-Adresse erklärt im Detail, wie sich diese Daten lesen lassen und wie sich eine beginnende Blocklist-Aufnahme erkennen lässt.
Häufig gestellte Fragen zum Fehler 550 5.7.25
Blockiert der Code 550 5.7.25 alle meine E-Mails oder nur bestimmte?
Die Ablehnung gilt pro IP. Sie kann sich sogar auf ein einziges Protokoll beschränken, wenn der IPv4-PTR korrekt ist, der IPv6-PTR aber fehlt. Versendet Ihre Infrastruktur von mehreren IPs aus, werden nur die Flüsse über die betroffene IP abgelehnt, während die anderen weiterhin normal ankommen.
Warum bounden meine an eine Gmail-Adresse weitergeleiteten E-Mails mit 550 5.7.25 zurück?
Gmail prüft den PTR der Maschine, die die Verbindung öffnet, nicht den des ursprünglichen Absenders. Bei einer automatischen Weiterleitung, etwa einem geschäftlichen Postfach, das an ein privates Gmail-Konto weiterleitet, muss also der weiterleitende Server einen gültigen PTR haben, selbst wenn der ursprüngliche Absender auf seiner Seite einwandfrei konfiguriert ist. Derselbe Mechanismus gilt für ein sekundäres SMTP-Relay oder ein Antispam-Gateway, das Ihrem Server vorgeschaltet ist. Lesen Sie die IP in eckigen Klammern im Bounce: Das ist diejenige, deren Reverse DNS korrigiert werden muss. Sie gehört oft zu einer Maschine, an die Sie zuletzt gedacht hätten.
Wie lange dauert es, bis die PTR-Korrektur wirksam wird?
Die Propagation dauert in der Regel zwischen wenigen Minuten und wenigen Stunden. Warten Sie ein Zeitfenster von 2 bis 4 Stunden ab, bevor Sie erneut testen, damit die DNS-Resolver ihren Cache aktualisieren können.
Schützt mich die Nutzung eines ESP automatisch vor diesem Fehler?
Ja, was den PTR selbst betrifft: Große Plattformen verwalten ihr eigenes Reverse DNS auf ihren IPs. Eine Gmail-Ablehnung, die trotz ESP bestehen bleibt, stammt meist von einem DKIM-Alignment-Problem oder einer falsch konfigurierten Absenderdomain, selten vom PTR selbst.
Reicht ein IPv4-PTR aus, wenn mein Server auch über IPv6 versendet?
Nein, siehe Prüfung Nr. 2 oben, um genau diesen Fall zu diagnostizieren. Bietet Ihr Hoster keinen IPv6-PTR an, bleibt die Deaktivierung des ausgehenden IPv6-Versands serverseitig eine schnellere Übergangslösung als ein Support-Ticket, auf dessen Antwort Sie warten müssen.
