Defaults.Exposed › Behebungen › Guides

Gmail „550-5.7.1 Message Blocked“ — den Bounce entschlüsseln und beheben (2026)

Veröffentlicht 2026-07-08

Zahlen mit Stand 2026-06-29 · Methodik v7. Aggregierte Zensusdaten über 261 Millionen bewertete Domains. Siehe wie wir bewerten.

Gmail liefert 550-5.7.1, wenn es eine Nachricht aus Policy-Gründen blockiert statt wegen eines fehlenden Eintrags: die Richtlinie einer sendenden oder empfangenden Domain, eine IPv6-Verbindung ohne Reverse-DNS oder vermuteter Spam. Von den 12.145.313 Domains, die Googles eigene Server in SPF autorisieren, setzen nur 18,5% DMARC durch, laut dem Defaults.Exposed-Zensus über 261 Millionen Domains.

550-5.7.1 ist Gmails älteste Sammelabweisung, und die Lösung hängt vom Satz nach dem Code in Ihrem Bounce ab. Im Folgenden: eine Decoder-Tabelle für den genauen Wortlaut, dann der Lösungsweg je Variante — Policy-Abweisungen, IPv6-Server ohne Reverse-DNS, Spam- oder Content-Blockaden — plus die Doppelgänger-Codes, mit denen er verwechselt wird, einschließlich der 5.7.26-Familie, die Google inzwischen für die DMARC-Policy-Abweisung nutzt, die ältere Referenzen unter 5.7.1 einordneten.

Was bedeutet Gmails 550-5.7.1 eigentlich?

Im SMTP-Enhanced-Status-Schema (RFC 3463) bedeutet jeder 5.7.x-Code „permanenter Fehler, Policy-Gründe“. Gmail nutzt 550-5.7.1 als seine Legacy-Policy-Familie: Blockaden durch Absender- oder Empfänger-Policy, Blockaden wegen Spam-Reputation, und — die Variante, die die meisten Admins überrascht — Mail, die über IPv6 von einem Server ohne Reverse-DNS-Eintrag (PTR) ankommt.

Google kodiert Varianten im Lauf der Zeit um. Die DMARC-Policy-Abweisung („not accepted due to domain’s DMARC policy“) steht in Googles aktueller Referenz jetzt unter 550-5.7.26, obwohl ältere Bounces in freier Wildbahn sie noch als 5.7.1 zeigen können; die Content-Sicherheitsblockade ist jetzt als 552 5.7.0 kodiert. Zwei weitere Geschwister werden mit 5.7.1 verwechselt: 550-5.7.26, die Authentifizierungsanforderungen-Familie (eigener Leitfaden), und 550-5.7.25, der Code für fehlendes PTR bei jeder IP-Version. Welcher Code es auch ist — entschlüsseln Sie den Text unten.

Welche 550-5.7.1-Variante haben Sie?

Ordnen Sie den Wortlaut in Ihrem Non-Delivery-Report (NDR) zu. Google passt diese Zeichenfolgen zwischen den Jahren an — orientieren Sie sich am Sinn, nicht an der Zeichensetzung.

Wie beheben Sie einen 550-5.7.1-Bounce?

1. Führen Sie den kostenlosen Scan bei defaults.exposed durch — er bewertet Ihr SPF, DKIM und DMARC, wie die Welt sie sieht, bevor Sie DNS anfassen, und zeigt, ob die DMARC-Variante für Ihre Domain überhaupt möglich ist.
2. Lesen Sie den vollständigen NDR-Text gegen die Decoder-Tabelle — der Satz, nicht der Code, identifiziert die Ursache.
3. DMARC-Variante: Finden Sie heraus, welche sendende Quelle die Authentifizierung nicht bestanden hat, und reparieren Sie diese Quelle (nächster Abschnitt).
4. IPv6/PTR-Variante: Fügen Sie passendes Reverse-DNS für die IPv6-Adresse des Servers hinzu, oder leiten Sie über den Smarthost Ihres Anbieters weiter.
5. Spam-/Policy-Variante: Postmaster Tools, Spam-Rate unter 0,10% (Googles harte Anforderungsgrenze liegt bei 0,30%), Listenhygiene, RFC-8058-Ein-Klick-Abmeldung.
6. Senden Sie eine Testmail an eine Gmail-Mailbox erneut und scannen Sie erneut — bestätigen Sie, dass der Bounce verschwunden ist und die Bewertung das widerspiegelt.

Der Bounce erwähnt Ihre DMARC-Richtlinie — warum das Ihre Richtlinie ist, die funktioniert

Googles aktuelle Referenz kodiert diese Zeichenfolge als 550-5.7.26, aber ältere Bounces und Dokumentationen von Drittanbietern zeigen sie noch unter 5.7.1 — so oder so ist die Mechanik identisch. Es liest sich rückwärts, bis Sie es durchschauen: Gmail hat eine Nachricht geprüft, die vorgab, von Ihrer Domain zu stammen, festgestellt, dass weder SPF noch DKIM aligned bestanden haben, Ihren DMARC-Eintrag nachgeschlagen und genau das getan, worum Sie gebeten haben — abweisen. Ihr Zaun hat gehalten. Die Frage ist, was sich darin verfangen hat: ein vergessener legitimer Absender (ein CRM, ein Rechnungstool, eine Newsletter-Plattform) oder ein echter Spoof.

Lockern Sie die Richtlinie also nicht als ersten Schritt. Finden Sie die unauthentifizierte Quelle. Zwei Fallen erklären die meisten Fälle:

• SPF besteht, aber auf der falschen Domain. Empfänger bewerten SPF gegen die Return-Path-Domain (RFC5321.MailFrom), nicht den From-Header. Ein SaaS-Tool, das „von“ Ihnen sendet, besteht SPF meist auf seiner eigenen Bounce-Domain, die nicht mit Ihrer From-Domain aligned ist — also scheitert DMARC trotzdem. Durchgerechnetes Beispiel: DMARC schlägt fehl, obwohl SPF und DKIM bestehen.
• DKIM besteht, aber mit der Standardsignatur. Google Workspaces gappssmtp.com- und Microsofts onmicrosoft.com-Standardwerte verifizieren einwandfrei und aligned mit nichts. Siehe DKIM besteht, aber DMARC scheitert trotzdem.

Diese Variante ist seltener, als man denkt: 27.640.987 von 261.086.232 Domains — 10,59% — setzen eine DMARC-Richtlinie von quarantine oder reject durch, laut dem Defaults.Exposed-Zensus (2026-06-29). Die übrigen 89,41% sehen diesen Bounce nie, weil sie keinen Zaun haben, der halten könnte. Die Quelle zu reparieren, nicht die Richtlinie, wird von Anfang bis Ende im DMARC-Reparaturleitfaden behandelt.

Der Bounce erwähnt IPv6-Sendeversrichtlinien — der Reverse-DNS-Fix

Moderne Server verbinden sich oft standardmäßig über IPv6 mit Gmail, und Google verlangt, dass die verbindende IPv6-Adresse einen PTR-Eintrag hat, der zu einem Hostnamen auflöst, der wiederum zur selben Adresse zurückauflöst (Forward-Confirmed Reverse DNS). Fehlt das, bekommt jede Nachricht 550-5.7.1, egal wie sauber Ihr SPF ist.

Drei Lösungen, in Reihenfolge der Präferenz:

• Setzen Sie den PTR-Eintrag für die IPv6-Adresse Ihres Servers — erledigt dort, wo die IP beheimatet ist (Ihr VPS-Host oder das Kontrollpanel Ihres ISP, nicht die DNS-Zone Ihrer Domain), mit einem passenden AAAA-Eintrag, der zurückverweist.
• Leiten Sie über den Smarthost Ihres Anbieters weiter. Wenn Sie rDNS nicht kontrollieren können, routen Sie ausgehende Mail über das Relay Ihres E-Mail-Anbieters oder ISPs, das bereits korrektes rDNS hat.
• Bevorzugen Sie IPv4-Transport als Notlösung. Er versteckt das Symptom meist, weil Ihre IPv4-Adresse ein PTR hat — ein Workaround, keine Lösung. Setzen Sie das IPv6-PTR, sobald Sie können.

Der Bounce sagt “likely unsolicited email” — der Reputationsweg

Hier kann die Authentifizierung in Ordnung sein, aber Gmails Filter trauen der Mail nicht. Authentifizierung ist der Boden, nicht die Decke — unter den 12.145.313 Domains, die _spf.google.com autorisieren, sperren nur 8,0% SPF mit einem strikten -all ab, sodass eine bestandene Prüfung für sich genommen wenig aussagt. (Vollständiger Vergleich: welcher E-Mail-Anbieter die stärksten SPF-Standardwerte liefert.)

Die Reputations-Checkliste:

• Registrieren Sie sich in Google Postmaster Tools und beobachten Sie das Spam-Rate-Dashboard — halten Sie sie unter 0,10% und lassen Sie sie nie die 0,30%-Grenze erreichen, die Googles Bulk-Sender-Richtlinien als harte Anforderung setzen.
• Bereinigen Sie Ihre Liste. Entfernen Sie Nicht-Interagierende und alles Gekaufte oder Gescrapte; senden Sie nur an Menschen, die gefragt haben.
• Implementieren Sie RFC-8058-Ein-Klick-Abmeldung bei Massenmail — von Googles Regeln vorgeschrieben, und jede Abmeldung, die kein „Spam“-Klick ist, schützt Ihre Rate.
• Halten Sie die Authentifizierung aligned (SPF und DKIM auf Ihrer eigenen Domain), damit Reputation einer Domain zugutekommt, die Sie kontrollieren.

Häufig gestellte Fragen

Ist 550-5.7.1 dasselbe wie 550-5.7.26? Nein. 550-5.7.26 ist Gmails Authentifizierungsanforderungen-Familie (SPF/DKIM fehlt oder scheitert) — und Googles aktuelle Referenz ordnet die DMARC-Policy-Abweisung dort auch ein. 550-5.7.1 ist die ältere Policy-Familie: Empfänger- und Absender-Policy-Blockaden, IPv6 ohne PTR, Spam- und Reputationsblockaden. Der Bounce-Text, nicht die Nummer, sagt Ihnen, welche Lösung greift (Stand 2026-06-29 und aktuelle Google-Richtlinien).

Sollte ich meine DMARC-Richtlinie auf p=none zurücksetzen, um die Bounces zu stoppen? Das stoppt sie, indem es den Zaun abreißt. Nur 10,59% der 261.086.232 Domains im Defaults.Exposed-Zensus (2026-06-29) setzen DMARC überhaupt durch; wenn Sie dazugehören, behalten Sie es bei und reparieren Sie die unauthentifizierte Quelle — die Richtlinie zu lockern öffnet Exact-Domain-Spoofing wieder.

Warum blockiert Gmail meine Mail, wenn mein SPF-Eintrag bei jedem Checker besteht? Checker testen den Eintrag; Gmail testet die Nachricht. SPF wird gegen die Return-Path-Domain bewertet, nicht die sichtbare From-Adresse, also nützt ein Bestehen auf der Bounce-Domain eines Anbieters Ihrem DMARC-Alignment nichts — und Reputationsblockaden ignorieren SPF vollständig. Der kostenlose Scan zeigt, welche Ebene tatsächlich scheitert.

Bedeutet 550-5.7.1, dass meine IP auf einer Blacklist steht? Nicht zwingend. Gmail betreibt ein eigenes Reputationssystem; Sie können von Google blockiert werden, während Sie auf keiner öffentlichen Blockliste stehen. Prüfen Sie Postmaster Tools für Googles Sicht — und beachten Sie, dass das Reparieren der Authentifizierung künftigen Schaden verhindert, aber nicht von selbst eine schlechte Sendereputation zurücksetzt.

Senden Sie dem Inhaber den Bericht

Sobald der Bounce behoben ist, führen Sie den Scan erneut durch und leiten Sie den bewerteten Bericht an den Geschäftsinhaber oder Kunden weiter, dessen Mail zurückgewiesen wurde. Er zeigt in klarer Sprache, was kaputt war, was Sie repariert haben und wo die Domain jetzt gegenüber der 261-Millionen-Domain-Basislinie steht — genau das, was für die Versicherungsverlängerung oder den Kunden-Sicherheitsfragebogen gebraucht wird, der fragt „authentifizieren Sie Ihre E-Mail?“. Ein still behobener Bounce ist unsichtbare Arbeit; ein Vorher-Nachher-Bericht ist der Beweis.

Prüfen Sie Ihre Domain → · Gmail 550-5.7.26 — die Lösung in Anforderungsreihenfolge → · DMARC reparieren → · Wie wir bewerten → · Nur aggregierte Daten. Daten werden in der EU gespeichert und verarbeitet.