Defaults.Exposed › Behebungen › Guides

Gmail 550 5.7.26 „The Sender Is Unauthenticated“: die Lösung, in Anforderungsreihenfolge (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.26, wenn Ihre Nachricht die SPF- und DKIM-Authentifizierungsprüfungen nicht besteht. Beheben Sie es, indem Sie mindestens eines von SPF oder DKIM für Ihre sendende Domain zum Bestehen bringen — den meisten Absendern fehlt genau das: Von den 12.145.313 Domains, die Googles Server über _spf.google.com autorisieren, setzen nur 18,5% DMARC durch, laut dem Defaults.Exposed-Zensus über 261.086.232 Domains.

Die Lösung ist DNS-Arbeit, kein Support-Ticket: Bestätigen Sie, dass Ihre sendende IP Reverse-DNS hat, bringen Sie SPF oder DKIM für die Domain zum Bestehen, die Gmail tatsächlich prüft, dann bringen Sie DKIM mit Ihrer From-Adresse zum Alignment und veröffentlichen Sie einen DMARC-Eintrag. Unten steht die vollständige Anforderungsreihenfolge, plus eine Decoder-Tabelle für die 550-5.7.26-Familie und ihre Geschwistercodes.

Was bedeutet der Gmail-Fehler 550 5.7.26?

Seit Googles Absenderanforderungen von 2024 muss jeder Absender an Gmail — nicht nur Massenversender — mindestens eines von SPF oder DKIM für die sendende Domain bestehen. Scheitern beide, weist Gmail zur SMTP-Zeit mit 550 5.7.26 ab, statt in den Spam zuzustellen.

Die aktuelle Volltext-Version lautet: “This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM. Authentication results: DKIM = did not pass, SPF [domain] with ip: [ip] = did not pass.” Ältere Bounces in freier Wildbahn können noch Googles früheren Wortlaut tragen (“This mail is unauthenticated, which poses a security risk…”), und es gibt einen Rate-Limit-Geschwistercode — 421 4.7.26 This email has been rate limited because it is unauthenticated — mit derselben Ursache.

550 5.7.26 ist keine einzelne Meldung, sondern Teil einer Code-Familie, und der Wortlaut verrät, welches Bein gescheitert ist: Googles aktuelle Referenz führt drei 5.7.26-Zeichenfolgen (unauthentifiziert, SPF-Hard-Fail, DMARC-Richtlinie) und verschiebt die reinen Massenversender-Fehler für SPF und DKIM in eigene Codes, 5.7.27 und 5.7.30. Lesen Sie den genauen Text, bevor Sie DNS anfassen — er ist Ihre erste Diagnose.

Das Ausmaß der Lücke erklärt, warum dieser Bounce so verbreitet ist: 12.145.313 Domains autorisieren Googles Mailserver in ihrem SPF-Eintrag (von 138.927.207 Domains weltweit, die SPF veröffentlichen), doch nur 18,5% haben eine durchsetzende DMARC-Richtlinie und nur 8,0% nutzen striktes SPF (-all). Die meisten bei Google gehosteten Absender erfüllen nicht einmal Googles eigene Massenversender-Regeln — und Gmail setzt die Grundlagen jetzt bei allen durch.

Welche 550-5.7.26-Variante — oder welchen Geschwistercode — haben Sie?

Gleichen Sie den Ihnen zugesandten Bounce-Text mit dieser Tabelle ab. Die zitierten Fragmente folgen Googles aktueller SMTP-Fehlerreferenz — prüfen Sie sie immer gegen Ihren tatsächlichen NDR, da Google den Wortlaut regelmäßig überarbeitet.

Wie beheben Sie 550 5.7.26, in Anforderungsreihenfolge?

Google veröffentlicht keine wörtliche „Prüfreihenfolge“ — aber seine Anforderungen bauen logisch aufeinander auf, arbeiten Sie sie also in dieser Anforderungsreihenfolge ab. Die meisten Absender sind nach Schritt 3 entblockt; arbeiten Sie die Liste trotzdem zu Ende, denn die späteren Schritte halten Sie aus dem Spam, sobald Sie aus dem Bounce heraus sind.

1. Führen Sie zuerst den kostenlosen Scan durch. Er liest Ihre live SPF-, DKIM-, DMARC- und DNS-Konfiguration und zeigt genau, welches Bein scheitert — diagnostizieren, bevor Sie DNS anfassen.
2. Geben Sie Ihrer sendenden IP Reverse-DNS (PTR). Die verbindende IP muss einen PTR-Eintrag haben, dessen Hostname zur selben IP zurückauflöst. Gängige Anbieter erledigen das für Sie; es trifft Leute, die von eigenen Servern senden (und ist die ganze Geschichte hinter dem Geschwistercode 550 5.7.25).
3. Bringen Sie SPF oder DKIM zum Bestehen. Eine Leitplanke zuerst: Empfänger bewerten SPF gegen die Return-Path-Domain (RFC5321.MailFrom), nicht den From-Header — prüfen Sie, auf welche Domain Ihre Mail tatsächlich zurückspringt, bevor Sie entscheiden, dass SPF „bestehen sollte“. Fügen Sie Ihre echten Sendedienste zum SPF-Eintrag dieser Domain hinzu (vollständige SPF-Anleitung), oder aktivieren Sie DKIM-Signierung bei Ihrem Anbieter (vollständige DKIM-Anleitung). Schon eines von beiden bestanden hebt die grundlegende 550-5.7.26-Blockade auf.
4. Bringen Sie DKIM mit Ihrer From-Domain zum Alignment. Für Massenversand — und für DMARC — will Gmail Authentifizierung für die Domain in Ihrer From-Adresse, nicht einen Anbieter-Standardwert. Google-Workspace-Nutzer: Veröffentlichen Sie Ihren eigenen DKIM-Schlüssel (Workspace-DKIM-Einrichtung); eine Standard-gappssmtp.com-Signatur besteht DKIM, aligned aber nicht — eine Falle mit eigenem Leitfaden. Aligned DKIM übersteht außerdem Weiterleitung, was SPF nie tut.
5. Veröffentlichen Sie einen DMARC-Eintrag. Googles Absenderanforderungen verlangen mindestens p=none mit einer Berichtsadresse. Es ist eine Fünf-Minuten-DNS-Änderung — siehe „DMARC policy not enabled“ für den ehrlichen ersten Schritt und was p=none schützt und was nicht.
6. Senden Sie über TLS. Jeder moderne Mailserver oder Anbieter tut das standardmäßig; wenn Sie Ihren eigenen MTA betreiben, bestätigen Sie, dass ausgehendes TLS aktiviert ist — Massenmail ohne TLS bekommt inzwischen einen eigenen Code, 550 5.7.29.
7. Fügen Sie RFC-8058-Ein-Klick-Abmeldung hinzu (List-Unsubscribe- + List-Unsubscribe-Post-Header) für Marketing- und abonnierte Mail.
8. Halten Sie Ihre Spam-Rate in Google Postmaster Tools unter 0,10% — und lassen Sie sie nie 0,30% erreichen. Googles Anforderungsgrenze liegt bei 0,3%; die Empfehlung ist, unter 0,10% zu bleiben. Registrieren Sie Ihre Domain dort; es ist Googles eigenes Zeugnis über Sie, und die Spam-Raten-Schwelle ist die Anforderung, die kein DNS-Eintrag beheben kann.

Eines wird diese Liste nicht tun: Sie von einer Drittanbieter-Blockliste entfernen. Authentifizierung stoppt Gmails unauthentifizierte Abweisungen; eine IP mit Spam-Historie ist ein Reputationsproblem mit eigenem Bereinigungsweg — Authentifizierung zu reparieren verhindert Rückfälle, es entfernt Sie nicht von der Liste.

Gelten die Massenversender-Regeln, wenn Sie weniger als 5.000 E-Mails pro Tag senden?

Die vollständige Checkliste — aligned Authentifizierung, veröffentlichtes DMARC, Ein-Klick-Abmeldung, Spam-Rate — gilt formal ab 5.000+ Nachrichten pro Tag an Gmail, und die reinen Massenversender-Codes (5.7.27, 5.7.29, 5.7.30) stammen aus dieser Stufe. Aber die Authentifizierungsgrundlagen (SPF oder DKIM bestanden, gültiges PTR) werden bei allen durchgesetzt, weshalb auch kleine Absender 550 5.7.26 treffen. Behandeln Sie die Schritte 1–5 bei jedem Volumen als Pflicht, die Schritte 7–8 sobald Sie in großen Mengen senden. Der vollständige Anforderungssatz für beide Anbieter steht in unserem Datenartikel zu den Google- und Yahoo-Absenderanforderungen.

Häufig gestellte Fragen

Bedeutet 550 5.7.26, dass meine Domain oder IP auf einer Blockliste steht? Nein. Es ist ein Authentifizierungsfehler, kein Reputationsurteil — Gmail sagt „beweisen Sie, wer Sie sind“, nicht „wir wissen, dass Sie ein Spammer sind“. Das ist gute Nachricht: Es ist vollständig in DNS behebbar. Die schlechte Nachricht ist, wie normal es ist — im Zensus über 261.086.232 Domains (Stand 2026-06-29) haben nur 10,59% eine durchsetzende DMARC-Richtlinie.

Stoppt es die Bounces, wenn ich nur SPF repariere? Meist ja, für die grundlegende Variante — Gmail verlangt mindestens eines von SPF oder DKIM. Aber SPF wird gegen die Return-Path-Domain bewertet und bricht bei Weiterleitung, sodass aligned DKIM (Schritt 4) die dauerhafte Lösung ist. Nur 8,0% der 12.145.313 bei Google gehosteten Absenderdomains nutzen striktes SPF (Datenstand 2026-06-29), also sind Sie so oder so dem Feld voraus.

Ich nutze Google Workspace — warum weist Google meine eigene Mail ab? Weil Gmail die Domain authentifiziert, nicht den Mailbox-Anbieter. Eine Workspace-Domain ohne SPF-Eintrag und ohne eigenen DKIM-Schlüssel sendet Mail, die Google selbst nicht verifizieren kann — von 12.145.313 Domains, die Googles Server autorisieren, haben nur 18,5% durchsetzendes DMARC (Datenstand 2026-06-29). Google-Kunde zu sein und Googles Regeln zu erfüllen sind zwei verschiedene Dinge.

Wie lange nach der DNS-Reparatur akzeptiert Gmail meine Mail? Sobald die neuen Einträge sichtbar sind — typischerweise Minuten bis wenige Stunden, bei langsamen TTLs bis zu 48 Stunden. Auth-Reparaturen wirken sofort auf die 550-5.7.26-Prüfung; Spam-Raten- und Reputationserholung (421-4.7.0, 5.7.28) brauchen Tage bis Wochen sauberen Sendens.

Senden Sie dem Inhaber den Bericht

Wenn Sie das für einen Kunden reparieren, schließen Sie das Ticket nicht mit „Bounces behoben“. Führen Sie den kostenlosen Scan nach Ihren DNS-Änderungen erneut durch und leiten Sie den bewerteten Bericht an den Geschäftsinhaber weiter. Er zeigt in klarer Sprache, dass die Domain jetzt ihre E-Mail authentifiziert und wo sie noch zurückbleibt — der Beleg, den man für Cyberversicherungs-Verlängerungen und Lieferanten-Sicherheitsfragebögen braucht. Sie haben den Bounce repariert; der Bericht beweist es.

Prüfen Sie Ihre Domain kostenlos

Sehen Sie, bei welchem Bein von SPF, DKIM und DMARC Gmail Sie scheitern lässt — privat und nur für den Inhaber.

Prüfen Sie Ihre Domain → · SPF reparieren → · Gmail „550-5.7.1 message blocked“ → · Wie wir bewerten → · Nur aggregierte Daten. Daten werden in der EU gespeichert und verarbeitet.