550 5.7.26: Warum Gmail und Outlook Ihre E-Mails ablehnen

Was bedeutet der Fehler 550 5.7.26 in Ihrer Bounce-Mail?

Der Fehlercode 550 5.7.26 in einer Rückläufer-Nachricht bedeutet, dass Gmail Ihre E-Mail dauerhaft abgelehnt hat, weil die Absenderdomain die Sicherheitsprüfung über SPF, DKIM oder DMARC nicht bestanden hat. Während Outlook vergleichbare Verstöße unter 550 5.7.515 oder 550 5.7.1 abweist, beheben Sie die Ursache durch vollständige Authentifizierungseinträge im DNS Ihrer Domain.

Wenn ein Eingangsserver Ihre E-Mail abweist, schickt er automatisch eine Bounce-Mail zurück, und zwar mit zwei Zahlenfolgen aus dem Simple Mail Transfer Protocol (SMTP). Schon die erste Ziffer klärt dabei, ob einfaches Abwarten hilft: Die führende 5 im dreistelligen Code 550 steht für eine dauerhafte Ablehnung (Permanent Negative Completion reply), sodass Ihr Mailserver denselben Zustellversuch nicht wiederholt. Insgesamt meldet der Code 550 nach dem Standard RFC 5321 (Oktober 2008), dass der empfangende Server die Zustellung wegen eines nicht erreichbaren Postfachs oder aus Richtliniengründen verweigert hat.

Erst die zweite Zahlenfolge dahinter grenzt die genaue Ursache ein, denn der erweiterte Statuscode 5.7.26 schlüsselt die Ablehnung nach RFC 3463 (Januar 2003) weiter auf: Die 5 bestätigt erneut einen dauerhaften Fehler (Permanent Failure), während die 7 auf eine Sicherheits- oder Richtlinienprüfung (Security or Policy Status) verweist. Die Endung 26 vergibt Google gezielt für fehlgeschlagene Authentifizierungsprüfungen und hängt deshalb das eigene Kürzel gsmtp (Google Simple Mail Transfer Protocol) an. Steht am Ende stattdessen gcdp, hat der Administrator der empfangenden Google-Workspace-Domain die Nachricht über eine eigene Filterregel (Google Custom Domain Policies) gestoppt.

Der Fehlertext hinter dem Code verrät Ihnen dann, welches Prüfverfahren konkret gescheitert ist. Denn Gmail bündelt unter 550 5.7.26 laut der Übersicht der Gmail-SMTP-Fehler und -Codes von Google (Stand 15. Oktober 2026) drei verschiedene Ursachen zum Schutz vor Spam und Phishing:

• Weder SPF noch DKIM bestanden: „Diese E‑Mail wurde blockiert, weil der Absender nicht authentifiziert ist. In Gmail müssen alle Absender ihre E‑Mails entweder mit SPF oder DKIM authentifizieren. Authentifizierungsergebnisse: DKIM = SPF nicht bestanden [domain-name] mit IP-Adresse [ip_address] = nicht bestanden.“
• SPF-Hard-Fail (-all) für die sendende IP-Adresse ausgelöst: „Die Domain (E)MAIL FROM [domain-name] hat einen SPF-Eintrag mit einer Hard-Fail-Richtlinie (-all), besteht jedoch nicht die SPF-Prüfungen mit der folgenden IP-Adresse: [ip-address].“
• Durch die eigene DMARC-Richtlinie Ihrer Domain abgewiesen: „Nicht authentifizierte E-Mails von Domainname werden aufgrund der DMARC-Richtlinie der Domain nicht akzeptiert. Wenden Sie sich an den Administrator der Domain domain-name, wenn es sich dabei um eine vertrauenswürdige E-Mail handelt.“

Warum lehnen Gmail und Outlook unauthentifizierte E-Mails ab?

Gmail und Outlook lehnen unauthentifizierte E-Mails ab, weil gefälschte Absenderadressen ohne technische Nachweise im DNS nicht von echten geschäftlichen Nachrichten unterscheidbar sind. Seit Februar 2024 setzt Google deshalb verbindliche Absenderregeln für SPF, DKIM und DMARC durch, während Microsoft seit Mai 2025 entsprechende Prüfungen bei Outlook.com, Hotmail und Live.com erzwingt.

Im Grundprotokoll für E-Mails kann zunächst jeder Server eine fremde Adresse wie info@ihre-domain.de als Absender eintragen, ähnlich wie auf einem Papierbrief jeder Name auf dem Umschlag stehen kann. Damit Angreifer keine gefälschten Rechnungen im Namen fremder Betriebe verschicken, prüfen Mailserver drei Einträge im Domain Name System (DNS), die ich auch in meiner Übersicht zu SPF, DKIM und DMARC vorstelle:

• Sender Policy Framework (SPF): Ein Text-Eintrag im DNS legt fest, welche Server und IP-Adressen für Ihre Domain senden dürfen.
• DomainKeys Identified Mail (DKIM): Ihr Mailserver versieht jede Nachricht mit einer digitalen Signatur, die der Empfänger über einen öffentlichen Schlüssel im DNS prüft.
• Domain-based Message Authentication, Reporting and Conformance (DMARC): Dieser Eintrag prüft, ob die sichtbare From:-Domain mit der SPF- oder DKIM-Domain übereinstimmt (Identifier Alignment), und regelt den Umgang mit Fehlversuchen.

Diese Pflicht greift bei Google schon für einzelne Nachrichten aus Ihrem Geschäftspostfach, denn seit dem 1. Februar 2024 müssen laut den E-Mail-Absenderrichtlinien von Google alle Absender an private Gmail-Konten (@gmail.com und @googlemail.com) mindestens SPF oder DKIM einrichten. Daneben verlangt Google gültige Vorwärts- und Rückwärts-DNS-Einträge (PTR-Records), eine TLS-Verschlüsselung, eine Formatierung nach RFC 5322 sowie in den Postmaster Tools eine Spamrate unter 0,3 % (empfohlen unter 0,1 %). Warum unveränderte Postfächer den Fehler teils erst später zeigen, erklären die Richtlinien-FAQs, denn dort heißt es außerdem wörtlich: „Ab November 2025 wird die Durchsetzung von Richtlinien für nicht richtlinienkonformen Traffic in Gmail verstärkt. Bei Nachrichten, die die Anforderungen an E‑Mail-Absender nicht erfüllen, kann es zu Störungen kommen, u. a. vorübergehende und dauerhafte Ablehnungen.“

Noch strengere Vorgaben greifen, sobald eine Domain binnen 24 Stunden 5.000 oder mehr Nachrichten an private Gmail-Konten versendet, denn bei Google gilt sie damit dauerhaft ohne Ablaufdatum als Großversender. Solche Domains müssen deshalb SPF und DKIM kombinieren, außerdem einen DMARC-Eintrag (mindestens p=none) samt Alignment veröffentlichen und bei Werbemails eine Ein-Klick-Abmeldung nach RFC 8058 und RFC 2369 anbieten.

Nach demselben Muster schützt der Konzern auch seine privaten Postfachdienste outlook.com, hotmail.com und live.com, wie die Ankündigung von Microsoft zu den Anforderungen für Großversender bei Outlook.com (Stand 30. April 2025) zeigt. Seit dem 5. Mai 2025 lehnt Microsoft dort Nachrichten von Domains mit über 5.000 E-Mails pro Tag unter dem Code 550; 5.7.515 ab, wenn SPF, DKIM oder DMARC (mindestens p=none mit Alignment) fehlen. Wie Sie Ihre geschäftliche Kommunikation darüber hinaus absichern, zeigt mein Ratgeber zur Website-Sicherheit für Unternehmen.

Wie prüfen Sie, ob SPF, DKIM oder DMARC bei Ihrer Domain fehlen?

Sie prüfen fehlende Einträge für SPF, DKIM und DMARC direkt im Quelltext einer gesendeten E-Mail über die Kopfzeile Authentication-Results oder durch eine DNS-Abfrage Ihrer Domain. Dort sehen Sie für jedes der drei Verfahren einzeln, ob der empfangende Server die Prüfung mit pass bestanden oder mit fail und permerror abgewiesen hat.

Öffnen Sie dazu in Ihrem E-Mail-Programm über „Original anzeigen“ oder „Nachrichtenquelle anzeigen“ den technischen Header einer Nachricht und suchen Sie nach Authentication-Results. Wie Microsoft in seiner DMARC-Dokumentation zeigt, protokolliert der Empfangsserver dort alle drei Ergebnisse:

Authentication-Results: mx.example.com;
  spf=pass (sender IP is 192.0.2.1) smtp.mailfrom=ihre-domain.de;
  dkim=pass (signature was verified) header.d=ihre-domain.de;
  dmarc=pass action=none header.from=ihre-domain.de

Prüfen Sie dabei nicht nur pass oder fail, sondern auch die drei Domains hinter smtp.mailfrom, header.d und header.from. Selbst wenn spf=pass und dkim=pass einzeln bestehen, scheitert DMARC mit dmarc=fail, sobald keine dieser beiden Domains mit der sichtbaren Absenderdomain hinter header.from=ihre-domain.de übereinstimmt. Dieses fehlende Alignment nach RFC 7489 (März 2015) entsteht, wenn ein Drittdienst zwar seine eigene Serverdomain beglaubigt, aber Ihre Adresse in das From:-Feld setzt.

Testen Sie deshalb nicht nur eine einzelne Nachricht aus Ihrem E-Mail-Programm, sondern alle Versandwege Ihrer Domain:

• Normales Postfach: Der Versand läuft über Ihren Hosting-Anbieter, Microsoft 365 oder Google Workspace.
• Website-Formulare: Wenn Ihr Webserver Anfragen unbeglaubigt per PHP-Mail verschickt, helfen Ihnen die Schritte aus meinem Leitfaden, wenn eine WordPress-E-Mail nicht ankommt, und dem Ratgeber für ein Kontaktformular, das nicht funktioniert.
• Drittdienste und Umzüge: Auch Shops, Newsletter-Tools oder ein Serverwechsel ändern die Versandserver, weshalb meine Checkliste, wie Sie Ihre E-Mails beim Hosterwechsel sichern, diese Einträge vorab abgleicht.

Wie beheben Sie die Ursache des Fehlers 550 5.7.26 im DNS?

Sie beheben den Fehler 550 5.7.26 nachhaltig, indem Sie im DNS Ihrer Domain einen einzigen SPF-Eintrag mit allen versendenden Servern anlegen, die digitale DKIM-Signatur Ihres Mailservers aktivieren und einen DMARC-Eintrag ergänzen. Dabei starten Sie die DMARC-Richtlinie im Beobachtungsmodus p=none, damit kein legitimer Versandweg Ihrer Website versehentlich blockiert wird.

Alle drei Einträge hinterlegen Sie in der DNS-Verwaltung Ihres Domain- oder Hosting-Anbieters. Gehen Sie dabei der Reihe nach vor, weil DMARC auf funktionierenden SPF- und DKIM-Einträgen aufbaut. Vorlagen dafür zeigt das DNS-Beispiel für SPF, DKIM und DMARC auf meiner Leistungsseite, während meine Anleitung, wie Sie SPF, DKIM und DMARC einrichten, die Umsetzung Schritt für Schritt erklärt.

1. SPF-Eintrag zusammenführen und Abfragegrenzen einhalten

Den SPF-Eintrag speichern Sie als TXT-Eintrag direkt auf der Hauptdomain; er startet mit v=spf1 und nennt erlaubte Quellen wie den Mail Exchange Record (MX-Record) sowie per include: eingebundene Versandserver:

Name/Host: @
Typ:       TXT
Wert:      v=spf1 mx include:spf.example.com -all

Beachten Sie dabei zwei harte Grenzen aus der Spezifikation des Sender Policy Framework in RFC 7208 (April 2014):

• Nur ein SPF-Eintrag je Domain: Wenn bereits ein v=spf1-Eintrag existiert, führt ein zweiter TXT-Eintrag laut RFC 7208 zwingend zum Fehler permerror. Tragen Sie weitere Server deshalb immer im bestehenden Eintrag vor -all oder ~all ein.
• Maximal 10 DNS-Lookups: Die Mechanismen include, a, mx, ptr, exists und redirect dürfen zusammen höchstens 10 DNS-Abfragen auslösen, sonst bricht die Prüfung ebenfalls mit permerror ab; ip4, ip6 und all zählen dabei nicht mit.

2. DKIM-Schlüssel im DNS hinterlegen und Signatur aktivieren

Für DKIM hinterlegen Sie den öffentlichen Schlüssel Ihres Mailservers unter einem Selektor im DNS – etwa als TXT-Eintrag unter default._domainkey oder bei Microsoft 365 über zwei CNAME-Einträge namens selector1._domainkey und selector2._domainkey. Achten Sie dabei auf die Schlüssellänge, denn sowohl der Standard RFC 6376 (September 2011) als auch Google verlangen mindestens 1.024 Bit, während Google 2.048 Bit empfiehlt. Danach aktivieren Sie im Postfach-Menü die DKIM-Signierung, damit ausgehende Mails den DKIM-Signature-Header erhalten.

3. DMARC stufenweise im Beobachtungsmodus starten

Den DMARC-Eintrag speichern Sie als TXT-Eintrag unter dem Hostnamen _dmarc:

Name/Host: _dmarc
Typ:       TXT
Wert:      v=DMARC1; p=none; rua=mailto:dmarc@ihre-domain.de

Ich richte DMARC grundsätzlich in Stufen ein und beginne immer mit p=none samt Berichtsadresse (rua=mailto:...), statt sofort eine Sperre zu aktivieren. Wer direkt p=quarantine oder p=reject einträgt, sperrt schnell eigene Versandwege wie ein Website-Kontaktformular, einen Onlineshop oder ein Rechnungsprogramm aus, falls dort noch SPF oder DKIM fehlen. Genau dann löst Ihre eigene DMARC-Regel bei Gmail den Fehler 550 5.7.26 oder bei Microsoft 365 den Fehler 550 5.7.1 aus.

Deshalb verschärfe ich die Richtlinie erst dann schrittweise von p=none (beobachten) über p=quarantine (Spam-Ordner) auf p=reject (ablehnen), wenn die DMARC-Berichte bestätigen, dass alle echten E-Mails Ihrer Domain die Prüfung bestehen. Nach dem Speichern hängt die Wartezeit von der Gültigkeitsdauer (Time to Live, TTL) ab: Microsoft nennt für SPF mindestens 3.600 Sekunden (eine Stunde), während Google bis zu 48 Stunden veranschlagt, wie ich im Beitrag zur DNS-Propagation beim Website-Umzug erläutere.

Was unterscheidet den Fehler 5.7.515 von 5.7.26?

Beide Statuscodes melden eine abgelehnte E-Mail wegen fehlender Absender-Authentifizierung, stammen jedoch von unterschiedlichen E-Mail-Anbietern. Während Google bei Gmail und Google Workspace den Code 550 5.7.26 sowie verwandte Codes von 5.7.27 bis 5.7.40 vergibt, nutzt Microsoft bei Outlook.com den Code 550 5.7.515 und bei Microsoft 365 den Code 550 5.7.1.

Wenn Sie Nachrichten sowohl an Google- als auch an Microsoft-Adressen verschicken, erzeugt derselbe DNS-Fehler deshalb verschiedene Rückläufer. Bei Microsoft hängt der Code außerdem davon ab, ob Sie an ein privates oder ein geschäftliches Postfach schreiben:

• Microsoft Outlook.com (550; 5.7.515): Bei über 5.000 E-Mails pro Tag an outlook.com, hotmail.com oder live.com meldet Microsoft ohne gültiges SPF, DKIM und DMARC seit dem 5. Mai 2025 wörtlich: „550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.“
• Microsoft 365 / Exchange Online (550 5.7.1): Wenn die Absenderdomain p=reject vorschreibt und die Prüfung scheitert, lehnt Exchange Online die Nachricht mit 550 5.7.1 (dmarc=fail action=oreject, compauth=fail reason=100) ab; bei p=quarantine landet sie dagegen im Junk-E-Mail-Ordner (action=quarantine).

Auch Google fächert seine Rückmeldungen neben 550 5.7.26 noch weiter auf und trennt dabei zwischen einer vorübergehenden Drosselung (421 oder 451) und einer dauerhaften Sperre (550), damit Sie den genauen Fehler schneller erkennen. Wenn einer Großversender-Domain speziell DMARC fehlt, vergibt Google etwa den Code 550 5.7.40 und meldet dazu wörtlich: „Ihre Nachricht wurde blockiert, weil die Absenderdomain keinen DMARC-Eintrag hat oder der DMARC-Eintrag keine DMARC-Richtlinie angibt.“

DNS-Einträge selbst anpassen oder E-Mail-Authentifizierung einrichten lassen?

Sie können SPF, DKIM und DMARC selbst im DNS hinterlegen, wenn Ihre Domain nur über ein einziges Postfach sendet und Sie sicheren Zugriff auf die DNS-Verwaltung Ihres Hosters haben. Sobald jedoch Website-Formulare, Onlineshops oder Newsletter-Dienste hinzukommen, deckt eine fachgerechte Einrichtung mit mehrwöchiger DMARC-Auswertung unerkannte Versandwege auf, bevor strenge DMARC-Regeln geschäftliche E-Mails abweisen.

Die Zahl Ihrer Versandquellen entscheidet darüber, ob Sie die Anpassung selbst vornehmen oder abgeben:

• Selbst einrichten: Sie nutzen nur ein einzelnes Postfach bei Ihrem Hoster, Ihre Website sendet bereits über dieses SMTP-Konto, und Sie kennen die TXT- und CNAME-Verwaltung Ihres Anbieters.
• Einrichten lassen: Über Ihre Domain senden mehrere Systeme wie Postfach, Kontaktformular, Onlineshop, Newsletter oder Rechnungsprogramm, Ihr SPF-Eintrag nähert sich dem 10-Lookup-Limit oder Sie möchten die XML-Berichte nicht selbst auswerten.

Wenn ich die Umsetzung übernehme, prüfe ich Ihre Domain vorab kostenlos. Auf meiner Leistungsseite stehen dafür drei feste Pakete in der Kostenübersicht für SPF, DKIM und DMARC (Stand Oktober 2026):

• Einrichtung (249 € netto zzgl. 19 % USt.): SPF, DKIM und DMARC für eine Domain und bis zu zwei Versandwege (etwa Postfach und Website-Kontaktformular samt SMTP-Umstellung), Start mit p=none, Testmails an Gmail und Outlook sowie Dokumentation aller Einträge.
• Komplett (490 € netto zzgl. 19 % USt.): Umfasst sämtliche Versandwege einer Domain (inklusive Shop, Newsletter, Rechnungsprogramm und Kundenverwaltung) sowie sechs Wochen DMARC-Auswertung mit schrittweiser Umstellung bis zur strengen Einstellung, sobald alle echten Versandwege die Prüfung bestehen, samt Abschlussbericht.
• Überwachung (19 € im Monat netto zzgl. 19 % USt., monatlich kündbar): Monatliche Auswertung der DMARC-Berichte, Warnung bei fremden Servern und DNS-Anpassung bei neuen Versanddiensten.

Schicken Sie mir bei Rückläufern einfach Ihre Domain und die Fehlermeldung, indem Sie auf der Leistungsseite eine kostenlose Vorab-Prüfung Ihrer Domain anfordern.