Fehler 550 5.7.515 in Outlook: Warum Microsoft Ihre Mails ablehnt und wie Sie es beheben
Eine Rechnung an einen Kunden mit Outlook.com-Adresse, ein Newsletter, eine ganz normale Antwort: plötzlich kommt nichts mehr an. Stattdessen landet im Postfach ein Non-Delivery-Report mit einer kryptischen Zeile wie 550 5.7.515 Access denied, sending domain does not meet the required authentication level. Für viele Administratoren beginnt damit eine kleine Krise, denn die Mails wurden zuvor jahrelang anstandslos zugestellt, und über Nacht häufen sich die Bounces. Der Auslöser ist kein Ausfall bei Microsoft, sondern eine bewusste Verschärfung, die seit dem 5. Mai 2025 scharf geschaltet ist.
Dieser Guide erklärt verständlich, was der Fehlercode bedeutet, warum Microsoft seit Mai 2025 so streng prüft und wie Sie die Ablehnung in drei sauberen Schritten dauerhaft beheben. Die Grundlagen zur Authentifizierung selbst vertieft der Beitrag zur DMARC-Pflicht 2025 und 2026.
Was der Fehler 550 5.7.515 bedeutet
TL;DR: Der Fehler 550 5.7.515 ist eine endgültige Ablehnung durch Microsoft, weil Ihre sendende Domäne die geforderte E-Mail-Authentifizierung nicht erfüllt. Es fehlen oder versagen SPF, DKIM oder DMARC. Behoben wird das in der DNS-Zone der sendenden Domäne: SPF um alle sendenden Systeme ergänzen, DKIM aktivieren und einen DMARC-Eintrag veröffentlichen. Erst wenn DMARC besteht, nimmt Microsoft die Mail wieder an.
Der dreistellige Code 550 steht im SMTP-Protokoll für eine permanente Ablehnung: Die Mail wird nicht in eine Warteschlange gestellt, sondern sofort und endgültig zurückgewiesen. Der erweiterte Status 5.7.515 grenzt die Ursache auf ein Sicherheits- und Richtlinienproblem ein, genauer auf eine nicht erfüllte Authentifizierungsanforderung der empfangenden Seite.
Microsoft prüft bei eingehenden Mails an Outlook.com, Hotmail und Live.com, ob die sichtbare Absenderdomäne ihre Nachrichten nachweislich autorisiert hat. Dieser Nachweis stützt sich auf drei Verfahren: SPF erlaubt bestimmten Servern den Versand für eine Domäne, DKIM signiert jede Nachricht kryptografisch, und DMARC verbindet beide und legt fest, wie mit fehlgeschlagenen Prüfungen umzugehen ist. Besteht keines dieser Verfahren in der von DMARC geforderten Form, antwortet Microsoft mit 550 5.7.515.
Wichtig ist die Einordnung: Das Problem liegt nicht beim Empfänger und nicht an einer Sperre Ihrer Adresse, sondern in der DNS-Konfiguration Ihrer eigenen Domäne. Genau deshalb lässt sich der Fehler vollständig auf Ihrer Seite beheben.
Warum Microsoft seit Mai 2025 so streng prüft
Die Verschärfung kommt nicht aus dem Nichts. Google und Yahoo haben bereits Anfang 2024 verbindliche Absender-Anforderungen eingeführt, die für Versender ab einem gewissen Volumen SPF, DKIM und eine bestandene DMARC-Ausrichtung verlangen. Microsoft ist diesem Kurs für seine Verbraucherdienste gefolgt. Mails, die die Anforderungen nicht erfüllten, wurden zunächst in den Junk-Ordner verschoben. Mit der Scharfschaltung im Mai 2025 wird stattdessen aktiv abgelehnt, und genau hier erscheint der Fehler 550 5.7.515.
Der Zweck dahinter ist Missbrauchsbekämpfung. Ohne durchgesetzte Authentifizierung lässt sich jede Absenderadresse fälschen, was Phishing und CEO-Fraud erst möglich macht. Eine erzwungene DMARC-Prüfung hebt die Hürde für Fälschungen deutlich an. Für legitime Absender ist die Botschaft eindeutig: Ohne saubere Authentifizierung gilt eine Domäne im Zweifel als nicht vertrauenswürdig.
Diagnose in drei Schritten
Die gute Nachricht: Der Fehler ist systematisch zu beheben. Arbeiten Sie die folgenden drei Schritte in genau dieser Reihenfolge ab.
Schritt 1: SPF prüfen und vervollständigen
SPF, das Sender Policy Framework, listet in einem TXT-Eintrag Ihrer Domäne alle Server, die in Ihrem Namen senden dürfen. Der häufigste Fehler ist ein unvollständiger Eintrag: Microsoft 365 ist enthalten, der separate Newsletter-Dienst oder ein vorgeschaltetes Gateway aber nicht. Prüfen Sie den vorhandenen Eintrag und ergänzen Sie alle sendenden Systeme. Achten Sie auf das Limit von zehn DNS-Lookups, das ein zu verschachtelter Eintrag schnell überschreitet. Ein gültiges SPF allein reicht jedoch nicht, denn DMARC verlangt zusätzlich, dass die SPF-geprüfte Domäne zur sichtbaren Absenderadresse passt.
Schritt 2: DKIM aktivieren und prüfen
DKIM, DomainKeys Identified Mail, versieht jede ausgehende Nachricht mit einer kryptografischen Signatur, deren öffentlicher Schlüssel im DNS hinterlegt ist. Damit lässt sich belegen, dass eine Mail tatsächlich von Ihrer Domäne stammt und unterwegs nicht verändert wurde. In Microsoft 365 wird DKIM im Defender-Portal je Domäne aktiviert, und die beiden CNAME-Einträge werden in der DNS-Zone veröffentlicht. Für Drittdienste wie Newsletter-Versender gilt der gleiche Grundsatz: Schlüssel erzeugen, im DNS hinterlegen, Signatur aktivieren. DKIM ist besonders robust, weil die Signatur auch über Weiterleitungen hinweg gültig bleibt, an denen SPF oft scheitert.
Schritt 3: DMARC-Record veröffentlichen
DMARC bindet SPF und DKIM zusammen und entscheidet, ob eine Mail als authentifiziert gilt. Veröffentlicht wird ein TXT-Eintrag unter _dmarc.ihre-domain.de. Ein erster Eintrag im Beobachtungsmodus sieht so aus: v=DMARC1; p=none; rua=mailto:dmarc-reports@ihre-domain.de. Die Richtlinie p=none erzwingt zunächst nichts, sorgt aber dafür, dass Sie über die Reporting-Adresse rua Aggregat-Berichte erhalten und sehen, welche Quellen sauber authentifiziert sind. Entscheidend ist die Ausrichtung, das sogenannte Alignment: SPF oder DKIM müssen nicht nur bestehen, sondern auch zur sichtbaren Absenderdomäne passen. Erst dann besteht DMARC, und Microsoft nimmt die Mail an. Wie Sie einen passenden Eintrag erzeugen, zeigt der DMARC-Record-Generator.
Prüf-Tabelle: Symptom, Ursache, Lösung
Die folgende Übersicht ordnet die häufigsten Konstellationen rund um 550 5.7.515 ihrer Ursache und der passenden Maßnahme zu.
| Symptom | Wahrscheinliche Ursache | Lösung |
|---|---|---|
| Bounce 550 5.7.515 an alle Outlook.com-Empfänger | Kein DMARC-Eintrag vorhanden | DMARC-Eintrag unter _dmarc veröffentlichen, zunächst mit p=none |
| Nur Mails aus einem Drittdienst werden abgelehnt | SPF unvollständig, Dienst nicht autorisiert | Sendendes System in den SPF-Eintrag aufnehmen, DKIM des Dienstes aktivieren |
| SPF besteht, DMARC scheitert dennoch | Fehlende SPF-Ausrichtung wegen abweichender Envelope-Domäne | DKIM für die Absenderdomäne aktivieren und ausrichten |
| DKIM-Signatur ungültig nach Weiterleitung | Inhalt verändert oder falscher Schlüssel | Korrekte CNAME- oder Schlüsseleinträge prüfen, Selector kontrollieren |
| Einrichtung scheint korrekt, Bounces bleiben | Mehrere sendende Quellen, eine nicht erfasst | DMARC-Aggregat-Berichte auswerten und Lücke schließen |
Die letzte Zeile ist der Kern des Problems: In vielen Organisationen senden mehr Systeme in Ihrem Namen, als auf den ersten Blick sichtbar ist. Erst die DMARC-Berichte machen diese Quellen vollständig sichtbar.
Wie Conbool DMARC die Ursache sichtbar macht
Der schnelle Weg, einen einzelnen 550-5.7.515-Bounce zu beheben, ist oft nur ein Pflaster. Sobald eine weitere sendende Quelle hinzukommt, etwa ein neues Ticketsystem oder ein Marketing-Tool, taucht der Fehler erneut auf. Die nachhaltige Lösung besteht darin, alle sendenden Quellen sichtbar zu machen und die Authentifizierung lückenlos zu überwachen. Genau das leistet Conbool DMARC.
Die DMARC-E-Mail-Authentifizierung von Conbool wertet die Aggregat-Berichte aller Empfänger zentral aus und zeigt in einer verständlichen Oberfläche, welche Systeme für Ihre Domäne senden, ob SPF und DKIM bestehen und ob die Ausrichtung passt. Statt rohes XML zu lesen, sehen Sie auf einen Blick, welche Quelle den Bounce verursacht. So lässt sich der Schritt von p=none über p=quarantine bis p=reject kontrolliert gehen, ohne legitime Mails zu verlieren. Wer eine ganze Mailinfrastruktur absichern möchte, ergänzt die Authentifizierung sinnvoll um ein zentrales Gateway wie Conbool MailGuard, das ein- und ausgehende Nachrichten an einer Stelle prüft.
Einen ersten Eindruck vom Status Ihrer Domäne liefert der kostenlose Check. Er zeigt, ob SPF, DKIM und DMARC vorhanden und stimmig sind, bevor der nächste Bounce auftritt.
Häufig gestellte Fragen
Was bedeutet der Fehler 550 5.7.515 in Outlook?
Der Fehler 550 5.7.515 ist eine endgültige Ablehnung durch Microsoft, weil die sendende Domäne die Authentifizierungsanforderungen nicht erfüllt. Es fehlen oder versagen SPF, DKIM oder DMARC, sodass sich die Herkunft der Mail nicht belegen lässt. Anders als bei einem temporären Defer hilft kein Abwarten, die Ursache liegt in der DNS-Konfiguration der sendenden Domäne.
Warum lehnt Microsoft meine Mails seit Mai 2025 ab?
Microsoft hat seine Absender-Anforderungen für Outlook.com, Hotmail und Live.com verschärft und folgt damit den Vorgaben von Google und Yahoo. Nicht authentifizierte Mails landeten zunächst im Junk-Ordner und werden seit der Scharfschaltung im Mai 2025 mit 550 5.7.515 abgelehnt. Wer ohne saubere Authentifizierung sendet, bemerkt das oft erst durch eine Welle von Bounces.
Wie behebe ich den Fehler 550 5.7.515 Schritt für Schritt?
In drei Schritten in Ihrer DNS-Zone: SPF um alle sendenden Systeme ergänzen, DKIM für die Absenderdomäne aktivieren und einen DMARC-Eintrag unter _dmarc.ihre-domain.de veröffentlichen. Erst wenn SPF oder DKIM bestehen und zur Absenderadresse ausgerichtet sind, ist DMARC erfüllt und Microsoft nimmt die Mail an.
Betrifft der Fehler 550 5.7.515 auch kleine Absender?
Ja. Auch wer nur gelegentlich an Outlook.com-Adressen sendet, kann den Fehler erhalten, sobald SPF, DKIM oder DMARC fehlen oder fehlerhaft sind. Die strengsten Schwellen gelten für Massenversender, die saubere Authentifizierung ist aber für jede Domäne die Grundlage einer zuverlässigen Zustellung. Kleine Absender übersehen einzelne Bounces leicht, weil sie keine eigene Zustellbarkeitsüberwachung betreiben.
Reicht ein SPF-Eintrag aus, um 550 5.7.515 zu vermeiden?
Nein. Microsoft erwartet eine bestandene DMARC-Prüfung, und DMARC verlangt, dass SPF oder DKIM zur sichtbaren Absenderadresse passen, also ausgerichtet sind. Über einen Dienstleister mit eigener Envelope-Adresse scheitert die SPF-Ausrichtung oft, obwohl SPF an sich besteht. Dann trägt DKIM die Authentifizierung. Deshalb sollten SPF und DKIM gemeinsam eingerichtet und per DMARC überwacht werden.
Fazit
Der Fehler 550 5.7.515 wirkt im ersten Moment bedrohlich, hat aber eine klare und vollständig auf Ihrer Seite lösbare Ursache: Microsoft verlangt seit Mai 2025 eine bestandene Authentifizierung, und Ihre Domäne erfüllt diese noch nicht. Wer SPF sauber vervollständigt, DKIM aktiviert und einen DMARC-Eintrag veröffentlicht, beendet die Ablehnungen dauerhaft und verbessert nebenbei den Schutz vor gefälschten Absendern.
Der nächste Schritt liegt bei Ihnen: Prüfen Sie Ihre Domäne mit dem kostenlosen Check und sehen Sie auf der Seite zur DMARC-E-Mail-Authentifizierung, wie Conbool DMARC jede sendende Quelle sichtbar macht und eine erneute Ablehnung verhindert.
Weiterführende Artikel:
