Gmail-Fehler 550 5.7.26 beheben: Ursachen und Lösung

Gmail antwortet mit 550-5.7.26, wenn eine Nachricht ohne Authentifizierung ankommt, die sich der Domain in deiner Absenderadresse (From) zuordnen lässt: Entweder haben weder SPF noch DKIM bestanden, oder sie haben für eine fremde Domain bestanden und deine DMARC-Richtlinie hat Gmail angewiesen, die Mail abzulehnen. Die Lösung ist fast nie „noch ein include in den SPF-Eintrag“. Entscheidend ist, dass DKIM mit deiner eigenen Domain signiert und der Envelope-Absender (Return-Path) ebenfalls auf deiner Domain liegt, damit mindestens eines davon zur From-Domain passt (Alignment).

Was bedeutet der Gmail-Fehler 550-5.7.26?

Es ist eine dauerhafte Ablehnung (die führende 5) von Mail, die Gmail als nicht authentifiziert einstuft. Googles Referenz der SMTP-Fehlercodes führt unter 5.7.26 drei Formulierungen auf, und der genaue Satz in deiner Unzustellbarkeitsnachricht verrät, welche Prüfung gescheitert ist.

Der Bindestrich in 550- ist kein anderer Code. SMTP-Server senden mehrzeilige Antworten mit 550- in jeder Zeile außer der letzten, die 550 mit Leerzeichen trägt. Deshalb taucht derselbe Fehler mal als „550-5.7.26“ und mal als „550 5.7.26“ auf.

Stand: November 2026, Wortlaut aus Googles Referenz der SMTP-Fehlercodes.

Warum du ihn jetzt öfter siehst: Die Gmail-Richtlinien für Absender verlangen seit dem 1. Februar 2024 von allen Absendern SPF oder DKIM und von Massenversendern (mehr als 5.000 Nachrichten pro Tag an Gmail) SPF, DKIM und DMARC mit passender From-Domain. Laut FAQ zu den Absenderrichtlinien verschärft Gmail ab November 2025 die Durchsetzung bei nicht konformem Traffic, mit vorübergehenden und dauerhaften Ablehnungen. Mail, die früher im Spam landete, kommt jetzt zurück.

Die Grundlagen der einzelnen Einträge erklärt unser Artikel Was sind SPF, DKIM und DMARC?. Hier geht es um genau diesen Bounce und wie du ihn loswirst.

Wie liest du Authentication-Results unter „Original anzeigen“?

Schick eine Nachricht an eine Gmail-Adresse, die dir gehört, öffne sie, wähle Mehr → Original anzeigen und such den Header Authentication-Results: mx.google.com. Er enthält drei Ergebnisse und, wichtiger noch, die drei Domains, auf die sich jedes bezog.

Kam die Nachricht gar nicht an, zitiert der Bounce diese Ergebnisse oft selbst. Sonst setz deine DMARC-Richtlinie vorübergehend auf p=none, damit die Nachricht zugestellt wird und du sie untersuchen kannst.

Authentication-Results: mx.google.com;
       dkim=pass header.i=@relay.example.net header.s=s1 header.b=Ab12Cd34;
       spf=pass (google.com: domain of bounces+8812@mail.relay.example.net designates 203.0.113.25 as permitted sender) smtp.mailfrom="bounces+8812@mail.relay.example.net";
       dmarc=fail (p=REJECT sp=REJECT dis=REJECT) header.from=example.com

Das ist der klassische Fall von 550-5.7.26: SPF und DKIM melden pass, DMARC scheitert trotzdem. Lies die Domains, nicht die Ergebnisse:

DMARC besteht, wenn mindestens eine der Prüfungen SPF und DKIM besteht und ihre Domain zu header.from passt. Hier passt keine, also dmarc=fail, und weil example.com p=reject veröffentlicht, lautet das Ergebnis dis=REJECT: der Bounce.

💡 Tipp: Eine Nachricht kann mehrere DKIM-Signaturen tragen. Eine passende genügt, also such zuerst nach einem dkim=pass, dessen header.i auf deine eigene Domain endet, bevor du etwas änderst.

Warum fällt Mail über ein Relay bei DMARC durch?

Weil die meisten Relays ab Werk mit ihrer eigenen Domain signieren und ihre eigene Bounce-Domain verwenden. Beide Prüfungen bestehen dann für das Relay, nicht für dich. Alignment entsteht erst, wenn du dem Relay für mindestens eine der beiden deine Domain gibst.

Die aktuelle DMARC-Spezifikation RFC 9989 (Mai 2026, ersetzt RFC 7489) kennt zwei Modi. Relaxed Alignment, der Standard, akzeptiert jede Domain mit derselben Organisationsdomain, also passt bounce.example.com zu example.com. Strict Alignment (aspf=s oder adkim=s) verlangt exakte Übereinstimmung. RFC 9989 ermittelt die Organisationsdomain per DNS-Tree-Walk statt über die Public Suffix List; für gewöhnliche Domains ist das Ergebnis gleich.

Stand: November 2026, Alignment-Regeln nach RFC 9989.

Ziel ist die vorletzte Zeile. DKIM-Alignment übersteht Weiterleitungen besser als SPF (warum, erklären die nächsten Abschnitte), und SPF-Alignment gibt dir einen zweiten Weg, wenn ein Gateway den Inhalt umschreibt und die DKIM-Signatur bricht.

Weitere typische Ursachen desselben Fehlers:

• Ein neuer Versanddienst, den niemand eingerichtet hat. Ein CRM, ein Helpdesk oder ein Rechnungsprogramm sendet als @example.de mit Standardeinstellungen. Jeder Dienst mit deiner From-Domain braucht dieselbe Behandlung, auch Postfächer bei IONOS, Strato oder Hetzner, wenn du darüber Geschäftsmail verschickst.
• Eine From-Domain, die dem Absender nicht gehört. Versand als @gmail.com oder @gmx.de über deinen eigenen Server kann nie passen.
• Unnötig striktes Alignment. adkim=s; aspf=s scheitert, wenn ein Relay mit mail.example.com signiert und From example.com ist.
• Ein kaputter DKIM-Schlüssel. Ein falsch in Strings aufgeteilter TXT-Eintrag, ein vom DNS-Panel abgeschnittener Schlüssel oder ein Selektor, den das Relay rotiert hat: dkim=fail oder dkim=neutral (body hash did not verify).

Wie behebst du 550-5.7.26 Schritt für Schritt?

DKIM signiert mit deiner Domain, der Envelope-Absender bekommt deine Domain, wo das Relay es zulässt, SPF stimmt für die Envelope-Domain und DMARC ist veröffentlicht. Arbeite die Schritte in dieser Reihenfolge ab; jeder lässt sich einzeln testen.

1. Alles auflisten, was als deine Domain sendet

   Das Relay deiner Newsletter-Plattform, dein Mail-Provider (Google Workspace, Microsoft 365, IONOS, Strato), Transaktionsmails deiner App, CRM, Helpdesk, Rechnungen. DMARC-Sammelberichte (Schritt 5) zeigen dir, was du vergessen hast.

2. DKIM mit eigener Domain bei jedem Relay einschalten

   Jedes Relay gibt dir entweder CNAME-Einträge, die auf von ihm rotierte Schlüssel zeigen, oder einen TXT-Eintrag mit einem öffentlichen Schlüssel. Veröffentliche genau das Angezeigte und bestätige es in der Konsole des Relays. Google empfiehlt 2048-Bit-Schlüssel, wo der Anbieter sie unterstützt (Absenderrichtlinien).

3. Eigene MAIL-FROM-Domain (Return-Path) setzen

   Die meisten Relays erlauben eine Subdomain wie bounce.example.com als Envelope-Absender. Sie verlangen dafür einen MX-Eintrag (damit Bounces weiter bei ihnen ankommen) und einen SPF-TXT-Eintrag auf dieser Subdomain.

4. SPF für die Envelope-Domain korrigieren

   Ein SPF-Eintrag pro Name, endend auf ~all oder -all, mit höchstens 10 Mechanismen, die DNS-Abfragen auslösen (include, a, mx, ptr, exists, redirect), gemäß RFC 7208, Abschnitt 4.6.4. Zwei SPF-Einträge auf einem Namen ergeben permerror, und das zählt als Fehlschlag.

5. DMARC veröffentlichen, zuerst mit p=none

   Ein TXT-Eintrag auf _dmarc.example.com mit einer Berichtsadresse. Wechsle erst zu quarantine und reject, wenn die Berichte alle legitimen Quellen als passend zeigen.

6. Erneut testen

   Schick eine Nachricht an ein Gmail-Test-Postfach und bestätige dmarc=pass, bevor du wieder an echte Abonnenten sendest.

Beispieleinträge für eine Domain, die Mitarbeiter-Mail über Google Workspace und Newsletter über Amazon SES verschickt (Tokens, Region und Berichtsadresse durch deine ersetzen):

; SPF für die From-Domain (Mitarbeiter-Mail über Google Workspace)
example.com.                      TXT   "v=spf1 include:_spf.google.com ~all"

; Eigene MAIL-FROM-Subdomain für Amazon SES
bounce.example.com.               MX    10 feedback-smtp.eu-central-1.amazonses.com.
bounce.example.com.               TXT   "v=spf1 include:amazonses.com ~all"

; Easy DKIM: drei CNAMEs aus der SES-Konsole (einer gezeigt)
abc123token._domainkey.example.com. CNAME abc123token.dkim.amazonses.com.

; DMARC, zuerst nur beobachten
_dmarc.example.com.               TXT   "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Die SES-Details (Sandbox, Regionen, SMTP-Zugangsdaten) stehen in unserer Anleitung zu Amazon SES als SMTP-Relay. Andere Relays nennen dieselben Funktionen anders: „custom return path“, „bounce domain“, „branded sending domain“ oder „domain authentication“.

⚠️ Achtung: Spring nicht sofort auf p=reject, um „konform“ zu sein. Gmails Regel für Massenversender akzeptiert p=none; eine strikte Richtlinie, bevor alle Quellen passen, erzeugt genau diesen 550-5.7.26 für deine eigene, legitime Mail.

Den ganzen Ablauf zum Verschärfen von DMARC, zum Aufwärmen und zur Überwachung findest du im Leitfaden zur Zustellbarkeit für selbst gehostete Absender (Englisch).

Warum prallen Weiterleitungen und Mailinglisten ab?

Eine Weiterleitung schickt deine Nachricht von einer neuen IP, die nicht in deinem SPF steht, also scheitert SPF; Mailinglisten ändern oft den Betreff oder hängen eine Fußzeile an, was deine DKIM-Signatur bricht. Fehlt beides, lehnt eine strikte DMARC-Richtlinie die weitergeleitete Kopie ab.

Googles Best Practices für die Weiterleitung an Gmail sagen, dass weitergeleitete Nachrichten oft an SPF scheitern und Gmail die Authentifizierung selbst neu prüft. Deshalb zählt passendes DKIM mehr als SPF: Eine unveränderte Nachricht behält ihre gültige Signatur über Weiterleitungen hinweg.

ARC (Authenticated Received Chain, RFC 8617, ein experimenteller RFC) lässt jeden Zwischenserver die gesehenen Authentifizierungsergebnisse festhalten und mit seiner eigenen Signatur versiegeln. Ein Empfänger, der diesem Zwischenserver vertraut, kann die versiegelten Ergebnisse nutzen, wenn die ursprünglichen Prüfungen nicht mehr bestehen. ARC setzen Weiterleiter und Listenserver, nicht du als ursprünglicher Absender, und der Empfänger entscheidet selbst, welchem Siegel er traut.

• Wenn deine Mail nach einer Weiterleitung abprallt: Stell sicher, dass DKIM passt und nichts die Nachricht nach dem Signieren verändert (manche Link-Tracking- oder Fußzeilen-Gateways tun das).
• Wenn du den Weiterleiter oder die Liste betreibst: Schreib nach Googles Rat den Envelope-Absender auf deine Weiterleitungsdomain um, pflege SPF und DKIM dafür und vermeide Änderungen, die DKIM brechen. Listensoftware ersetzt bei Absendern mit strikter DMARC-Richtlinie oft das From durch die Listenadresse.
• Wenn es die private Weiterleitung eines Abonnenten ist: Die kannst du nicht reparieren; ein einzelner Bounce von so einer Adresse heißt nicht, dass deine Authentifizierung kaputt ist.

Wie prüfst du, ob die Korrektur wirkt?

Prüf das DNS von außen, schick eine Nachricht an ein Gmail-Test-Postfach, lies Authentication-Results und beobachte danach mindestens eine Woche lang die Postmaster Tools.

# 1. Einträge, wie die Welt sie sieht (nur ein SPF-Eintrag)
dig +short TXT example.com | grep spf1
dig +short TXT bounce.example.com
dig +short TXT _dmarc.example.com
dig +short CNAME abc123token._domainkey.example.com

# 2. Test über dasselbe Relay und denselben Port wie deine Plattform (swaks)
swaks --to du@gmail.com --from newsletter@example.com \
      --server email-smtp.eu-central-1.amazonaws.com --port 587 --tls \
      --auth LOGIN --auth-user "$SMTP_USER" --auth-password "$SMTP_PASS" \
      --header "Subject: DMARC-Alignment-Test"

Ein bestandenes Ergebnis sieht so aus, mit deiner Domain an allen drei Stellen:

dkim=pass header.i=@example.com header.s=abc123token
spf=pass (google.com: domain of 0102018f-test@bounce.example.com designates 203.0.113.40 as permitted sender) smtp.mailfrom=bounce.example.com
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

Das Compliance-Status-Dashboard der Google Postmaster Tools zeigt, ob deine Domain die Absenderrichtlinien erfüllt (SPF, DKIM und für Massenversender DMARC und Abmeldung mit einem Klick). Google weist darauf hin, dass die Daten ein gleitender Durchschnitt über mehrere Tage sind, und empfiehlt, nach 7 Tagen erneut zu prüfen; erwarte also kein Grün in der Stunde nach der DNS-Korrektur. Die Abmeldung mit einem Klick ist eine eigene Anforderung; siehe unseren Leitfaden zu RFC 8058.

Und wenn du die abgewiesene Mail nie verschickt hast?

Dann hat jemand anderes deine Domain in die Absenderadresse geschrieben, und Gmail hat genau getan, was deine DMARC-Richtlinie verlangt. Ein Bounce für eine Nachricht, die du nie gesendet hast, heißt Backscatter: Der Server des Fälschers hat die Ablehnung an den gefälschten Return-Path geschickt, und das kann deine Adresse sein.

Prüf die im Bounce zitierten Header. Eine IP, die keinem deiner Anbieter gehört, ein Message-ID-Format, das deine Systeme nicht verwenden, oder ein Betreff, den du nie geschrieben hast, deuten auf Spoofing hin. Deine DMARC-Sammelberichte zeigen dasselbe im Großen: Quellen mit deinem header.from, die weder SPF noch DKIM bestehen.

• Lockere DMARC nicht, damit die Bounces aufhören; p=reject schützt deine Empfänger vor der gefälschten Mail.
• Filtere oder verwirf Bounces an Adressen, die du nie als Return-Path nutzt.
• Nennen die Bounces einen echten, vergessenen Absender von dir, ist das Schritt 1 der Korrektur oben, kein Spoofing.

Dauerhafte Bounces legitimer Mail sind ein eigenes Thema: Hard und Soft Bounces und das Sperren von Adressen behandelt unser Leitfaden zum Bounce-Management.

550-5.7.26 beim Versand mit NetSendo beheben

NetSendo sendet über das Postfach, das du verbindest (ein SMTP-Relay wie Amazon SES oder Mailgun, die Gmail-API, SendGrid oder NMI, die NetSendo Mail Infrastructure). Die Authentifizierung richtest du also bei diesem Anbieter und in deinem DNS ein. NetSendo veröffentlicht kein eigenes SPF-include.

• Wer DKIM signiert: Bei SMTP-, SendGrid- und Gmail-Postfächern signiert der Anbieter, nicht NetSendo; aktiviere dort DKIM mit deiner Domain. NMI erzeugt 2048-Bit-DKIM-Schlüssel und zeigt die DNS-Einträge zum Kopieren an.
• Return-Path: Seit NetSendo 2.2.0 wird die Bounce-Adresse des sendenden Postfachs bei jedem Versand über SMTP- und Gmail-Postfächer als Envelope-Absender gesetzt, nicht mehr nur bei Automationen. Liegt das Bounce-Postfach auf deiner Domain, wird SPF für diese Domain geprüft, ihr SPF-Eintrag muss das Relay also erlauben. Die SendGrid-API setzt ihren eigenen Envelope-Absender; nutze dort die Domain-Authentifizierung von SendGrid. Manche Relays ersetzen den Envelope-Absender durch ihre eigene Bounce-Domain; prüf deren Einstellung für ein eigenes MAIL FROM.
• Prüfungen in NetSendo: Deliverability Shield, Teil der GOLD-Lizenz, prüft SPF, DKIM und DMARC verifizierter Domains regelmäßig. Seit 2.8.0 kannst du den DKIM-Selektor von Relays wie Amazon SES eintragen, die Tokens pro Domain verwenden, und der DMARC-Generator beginnt mit p=none und relaxed Alignment. Die DNS-Einträge selbst funktionieren mit jeder Lizenz, auch mit der kostenlosen SILVER-Lizenz.

Postfächer, Versandoptionen und NMI beschreibt die Konfigurationsdokumentation; die Installation von NetSendo sind ein paar Befehle aus dem Schnellstart.

Häufig gestellte Fragen

Quellen

• Google Workspace: Gmail SMTP errors and codes
• Google: Email sender guidelines
• Google: Email sender guidelines FAQ
• Google: Postmaster Tools dashboards
• Gmail Help: Best practices for forwarding email to Gmail
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 7208: Sender Policy Framework (SPF)
• RFC 8617: Authenticated Received Chain (ARC)