Outlook-Absenderanforderungen seit Mai 2025 und die Ablehnung 550 5.7.515

Die Unzustellbarkeitsmeldung 550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level bedeutet, dass Outlook.com Ihre Nachricht abgelehnt hat, weil Ihre Domain die SPF-, DKIM- und DMARC-Prüfungen nicht bestanden hat, die Microsoft von Absendern mit hohem Versandvolumen verlangt. Die Lösung liegt in Ihrem DNS und in der Konfiguration der Systeme, die Ihre E-Mails versenden, nicht im Inhalt der Nachricht.

Microsoft hat die Regeln im April 2025 im Microsoft Defender for Office 365 Blog angekündigt und setzt sie seit dem 5. Mai 2025 durch. Sie gelten für Outlook.com, den Verbraucherdienst von Microsoft, also für Adressen unter outlook.com, hotmail.com und live.com.

Die Anforderungen orientieren sich eng an dem, was Gmail und Yahoo 2024 eingeführt haben. Eine Domain, die für einen Anbieter korrekt eingerichtet ist, erfüllt daher meist schon den Großteil der Anforderungen der anderen.

Was Microsoft verlangt

Laut der Ankündigung müssen Domains, die mehr als 5.000 E-Mails pro Tag an Outlook.com senden, 3 Bedingungen erfüllen:

• SPF muss bestehen für die sendende Domain, und der DNS-Eintrag muss die autorisierten IP-Adressen und Hosts korrekt auflisten.
• DKIM muss bestehen, um Integrität und Echtheit der Nachricht zu bestätigen.
• DMARC muss mindestens mit p=none veröffentlicht sein und mit SPF oder DKIM übereinstimmen (Alignment, laut Microsoft idealerweise mit beiden).

Microsoft nennt außerdem Regeln zur E-Mail-Hygiene für große Absender und behält sich vor, Absender zu filtern oder zu blockieren, die sie ignorieren:

• Eine gültige From- oder Reply-To-Adresse, die die tatsächliche sendende Domain widerspiegelt und Antworten empfangen kann.
• Eine klare, funktionierende Abmeldemöglichkeit für Marketing- und Massen-E-Mails.
• Regelmäßiges Entfernen ungültiger Adressen und die Verarbeitung von Bounces.
• Zutreffende Betreffzeilen, keine irreführenden Header und Empfänger, die dem Erhalt Ihrer Nachrichten zugestimmt haben.

Junk-Ordner oder Ablehnung

In der ursprünglichen Ankündigung hieß es, nicht konforme E-Mails würden zunächst in den Junk-Ordner geleitet. Microsoft hat den Beitrag am 29. April 2025 aktualisiert: Nachrichten, die die Authentifizierungsanforderungen nicht erfüllen, werden mit dem Fehler 550 5.7.515 abgelehnt, wirksam wie geplant ab dem 5. Mai 2025 (Quelle).

In der Praxis ist das hilfreich: Eine Ablehnung erscheint in Ihren Versandprotokollen und Bounce-Berichten, während ein stilles Verschieben in den Junk-Ordner lange unbemerkt bleiben kann.

Warum eine legitime Domain 5.7.515 erhält

Die üblichen Ursachen sind Konfigurationslücken, nichts Bösartiges:

Ein Versandtool ohne DKIM für Ihre Domain. Newsletter-Plattformen, CRMs und Rechnungstools signieren oft mit ihrer eigenen Domain, solange Sie deren DKIM-Einträge nicht in Ihrer Domain hinterlegen.

SPF besteht für den Anbieter, nicht für Sie. Viele Dienste verwenden ihren eigenen Return-Path, sodass SPF für bounce.vendor.net besteht. Ohne übereinstimmendes DKIM scheitert DMARC.

Kein DMARC-Eintrag. Microsoft verlangt mindestens p=none. Ein fehlender _dmarc-Eintrag reicht für eine Ablehnung.

SPF über dem Lookup-Limit. SPF erlaubt höchstens 10 DNS-Lookups (RFC 7208, Abschnitt 4.6.4). Ein Dienst zu viel, und SPF liefert bei jeder Nachricht einen Fehler.

Eine kürzliche DNS-Änderung. Eine Migration zu einem neuen DNS-Anbieter oder Mailhoster, bei der ein DKIM-Selektor oder das SPF-Include für einen Dienst verloren ging.

So finden Sie die Ursache

Beginnen Sie mit Ihrem DNS:

dig +short TXT yourcompany.com | grep spf1
dig +short TXT _dmarc.yourcompany.com
dig +short TXT selector1._domainkey.yourcompany.com

Finden Sie dann heraus, welches System die abgelehnte Nachricht gesendet hat. Die Unzustellbarkeitsmeldung enthält meist die ursprünglichen Header. Senden Sie anschließend aus genau diesem System eine Testnachricht an eine Outlook.com-Adresse, auf die Sie Zugriff haben, und prüfen Sie den Header Authentication-Results. Wie man ihn liest, erklärt Microsoft in seiner Dokumentation zu Nachrichtenheadern. Sie suchen nach:

spf=pass smtp.mailfrom=yourcompany.com
dkim=pass header.d=yourcompany.com
dmarc=pass header.from=yourcompany.com

Zeigt smtp.mailfrom oder header.d die Domain des Anbieters statt Ihrer eigenen, liegt das Problem beim Alignment. Steht dort dkim=none, signiert das System überhaupt nicht.

So beheben Sie es

1. Veröffentlichen Sie einen DMARC-Eintrag, falls Sie keinen haben: v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com.
2. Richten Sie in jedem Versandtool DKIM mit Ihrer eigenen Domain ein (das Tool stellt die CNAME- oder TXT-Einträge bereit).
3. Wenn das Tool einen eigenen Return-Path unterstützt, lassen Sie ihn auf eine Subdomain Ihrer Domain zeigen, damit auch SPF übereinstimmt.
4. Führen Sie SPF in einem einzigen Eintrag zusammen, entfernen Sie nicht mehr genutzte Dienste und bleiben Sie unter 10 Lookups.
5. Senden Sie erneut eine Testnachricht an Outlook.com und prüfen Sie, dass alle 3 Prüfungen bestehen.
6. Sobald die DMARC-Berichte zeigen, dass alle legitimen E-Mails bestehen, gehen Sie zu p=quarantine und später zu p=reject über.

Für weitere Hilfe verweist Microsoft Absender auf sein Outlook Sender Support Portal. Unser Leitfaden zu SPF, DKIM und DMARC erklärt jeden Eintrag genauer.

Kurze Checkliste

• SPF besteht, 1 Eintrag, unter 10 Lookups.
• DKIM-Signatur mit Ihrer Domain in jedem System, das E-Mails versendet.
• DMARC veröffentlicht, mindestens p=none, übereinstimmend mit SPF oder DKIM.
• Bounce-Protokolle nach jeder Änderung an DNS oder Anbieter auf 5.7.515 geprüft.
• Funktionierende Abmeldung und bereinigte Listen für Marketing-E-Mails.

Wo Datahorses ins Spiel kommt

Datahorses überwacht Ihre E-Mail-bezogenen DNS-Einträge jeden Tag von außen. So fällt ein entfernter DKIM-Selektor, ein defekter SPF-Eintrag oder eine abgeschwächte DMARC-Richtlinie auf, bevor daraus Unzustellbarkeitsmeldungen werden. Jede Änderung prüft ein Mensch und schickt Ihrem Entwickler die genauen Einträge, die korrigiert werden müssen. Sehen Sie sich an, was wir überwachen, wie wir mit einem Fund umgehen, oder das Beispiel-Dashboard.