Die Absender-Anforderungen von Microsoft (Outlook, Hotmail) 2025

Die Microsoft-Filterung: Junk Email Reporting und SCL

Microsoft nutzt sein eigenes Bewertungssystem, den SCL (Spam Confidence Level), der bestimmt, wo eine Nachricht landet: Posteingang, Junk-Ordner oder komplette Blockierung. Dieser Wert stützt sich auf die Authentifizierung (SPF/DKIM/DMARC), die IP-/Domain-Reputation (teilweise über SNDS sichtbar) und die Inhaltsanalyse — eine Logik, die der von Gmail nahekommt, aber mit eigenen internen Gewichtungen, die nicht im Detail veröffentlicht werden.

Ein spezifisches Signal, das im Auge zu behalten ist: das Junk Email Reporting Program (JMRP), das Programm, über das Outlook-Nutzer eine Nachricht als unerwünscht melden. Wie bei Gmail verschlechtert eine hohe Beschwerderate die Reputation schnell — aber die Anmeldung bei JMRP (getrennt von SNDS) liefert direkt eine Kopie der Meldungen zu den eigenen E-Mails, also ein Frühwarnsignal, das nur wenige Absender nutzen.

DMARC-Ausrichtung: dieselben Regeln, ein manchmal strengeres Verhalten

DMARC funktioniert bei Microsoft nach demselben Standard wie überall sonst — die SPF/DKIM-Ausrichtung mit dem From: hat nichts Spezifisches für dieses Ökosystem. Was sich in der Praxis unterscheidet, ist, dass manche Administratoren von einer etwas strengeren Behandlung von Ausrichtungsfehlern bei Outlook im Vergleich zu Gmail berichten, insbesondere bei Grenzfällen. Die praktische Lehre: Eine DMARC-Konfiguration, „die bei Gmail durchgeht", reicht bei Microsoft nicht automatisch aus — die Ausrichtung jeder Quelle ist gezielt in den aggregierten DMARC-Berichten zu prüfen, mit einem besonderen Auge auf die Empfänger outlook.com/hotmail.com.

Microsoft 365 auf Unternehmensseite: eine weitere Schicht

Nutzt ein Teil der Empfänger Microsoft 365 in einer geschäftlichen Umgebung statt der Privatkunden-Domains, kommt hinzu, dass Unternehmensadministratoren über zusätzliche Filterschichten verfügen (Exchange Online Protection, benutzerdefinierte Transportregeln, interne Sperrlisten), die zur Standard-Microsoft-Filterung hinzukommen. Eine tadellose Authentifizierung garantiert nicht, dass man eine aggressive interne Blockierregel passiert, die vom Administrator eines Empfängers gesetzt wurde — ein Faktor außerhalb der eigenen Kontrolle, aber nützlich zu wissen, um keinen Fehler auf DMARC-Seite zu suchen, wo keiner ist.

Checkliste zur Microsoft-Konformität

• SPF und DKIM ausgerichtet, speziell auf dem Verkehr zu outlook.com/hotmail.com in den Berichten überprüft.
• DMARC veröffentlicht, mit dem Ziel einer Steigerung auf quarantine und dann reject nach derselben Methode wie für jeden anderen Empfänger — siehe p=reject erreichen, ohne seine E-Mails zu zerstören.
• Anmeldung bei SNDS für die Sichtbarkeit der IP-Reputation, sofern die Versand-IPs im eigenen Zugriff sind.
• Anmeldung beim JMRP-Programm, um Spam-Meldungen zu den eigenen Versänden direkt zu erhalten.
• Listenhygiene identisch zu der für Gmail empfohlenen — Microsoft beobachtet dieselben Verhaltenssignale (Beschwerden, Bounces, Engagement).
• Funktionierendes und sichtbares Abmelden, das den Rückgriff auf die Schaltfläche „als unerwünscht melden" reduziert.

Der Verschärfungszeitplan auf Microsoft-Seite

Ein Punkt, der bei der Vorbereitung des Fahrplans zählt: Das Durchsetzungstempo von Microsoft hat nicht immer dem von Gmail und Yahoo entsprochen. Wo Google bereits bei der ersten Ankündigung 2024 einen präzisen und datierten Zeitplan kommunizierte, ist Microsoft lange durch schrittweise Anpassungen seiner Filterung ohne so strukturierte öffentliche Ankündigung vorgegangen. Die praktische Konsequenz: Die Annahme „die Frist von Google ist verstrichen, also ist alles überall geregelt" trägt nicht. Die Microsoft-Filterung entwickelt sich unabhängig weiter, und eine Domain, die vor sechs Monaten problemlos durchging, kann ihre Outlook-Zustellbarkeit sich verschlechtern sehen, ohne dass eine Änderung auf Absenderseite die Ursache wäre — einfach weil sich die Toleranzschwelle auf Microsoft-Seite verschoben hat.

Das ist ein weiteres Argument dafür, die Reputationsüberwachung (über SNDS) als fortlaufende Übung zu behandeln und nicht als ein einmal bei der Erstkonformität abzuhakendes Kästchen.

Praxisfall: ein französischer B2B-Absender

Nehmen wir ein konkretes Beispiel, um diese Begriffe zu verankern. Ein französisches KMU, das seine Rechnungen und Mahnungen per E-Mail versendet, erreicht eine Mischung aus geschäftlichen Empfängern — oft auf geschäftlichen Microsoft-365-Domains — und Privatpersonen, die stärker zwischen Gmail, Outlook.com/Hotmail und den französischen Anbietern (Orange, Free, SFR) verteilt sind. Für dieses KMU ist es keine nebensächliche Option, die Microsoft-Schicht zu ignorieren: Es ist potenziell die Hälfte seines geschäftlichen Verkehrs, die durch dieses Ökosystem läuft.

Der richtige Reflex ist, die DMARC-Konfiguration als universell zu behandeln (ein einziger Eintrag, gültig für alle Empfänger), aber die Reputationsüberwachung als spezifisch für jedes Ökosystem: Postmaster Tools für den Gmail-Anteil, SNDS für den Microsoft-Anteil und eine Wachsamkeit gegenüber den aggregierten DMARC-Berichten, um zu erkennen, ob ein bestimmter Empfänger eine im Vergleich zu den anderen ungewöhnlich hohe Fehlerrate zeigt. Diese differenzierte Wachsamkeit kostet nach der Einrichtung wenig Zeit und vermeidet den häufigsten blinden Fleck bei französischen Absendern: eine ausgezeichnete Gmail-Zustellbarkeit, die eine mittelmäßige Outlook-Zustellbarkeit verdeckt, einfach weil niemand auf diese Seite geschaut hat.

Konkret läuft die Einrichtung für dieses KMU auf eine kurze Prüfliste hinaus, die an einem Vormittag erledigt ist. Zuerst wird der bestehende DMARC-Eintrag durch den Analysator geschickt, um zu bestätigen, dass SPF und DKIM sauber ausgerichtet sind — dieser Schritt ist ohnehin schon gemacht, wenn die Gmail-Konformität abgeschlossen wurde. Dann folgt die Anmeldung bei SNDS, sofern das KMU seine Versand-IPs kontrolliert; nutzt es eine gemeinsam geteilte Versandplattform, muss es prüfen, ob diese den SNDS-Zugang für ihre Kunden weiterreicht, was viele professionelle Anbieter tun. Schließlich wird eine wiederkehrende Aufgabe eingerichtet — sagen wir, monatlich —, um die SNDS-Kennzahlen und die aggregierten DMARC-Berichte gemeinsam durchzusehen. Diese drei Handgriffe verwandeln einen blinden Fleck in eine überwachte Fläche, ohne dass das KMU einen einzigen zusätzlichen DNS-Eintrag anfassen müsste.

Der entscheidende Punkt, den ein französisches KMU verinnerlichen sollte: Die Outlook-Welt ist in Frankreich keineswegs eine Randgröße. Viele Privatpersonen haben historisch eine Hotmail- oder Live-Adresse behalten, und ein erheblicher Teil der kleinen und mittleren Unternehmen läuft auf Microsoft 365. Eine Zustellbarkeit, die man nur an Gmail misst, gibt also ein systematisch verzerrtes Bild — sie kann glänzend aussehen, während ein Drittel oder mehr des tatsächlichen Verkehrs unbemerkt im Junk-Ordner von Outlook landet.

Warum man sich nicht mit der Gmail-Konformität begnügen sollte

Der häufigste Denkfehler: „Ich bin für Gmail bereits konform, also bin ich es überall." Technisch ist die Authentifizierung (SPF/DKIM/DMARC) tatsächlich dieselbe DNS-Konfiguration für alle Empfänger — keine Duplizierung bei den Einträgen nötig. Aber die Reputation ist spezifisch für jedes Ökosystem: Die Reputation bei Google und die bei Microsoft sind zwei unabhängige Historien, die auf Signalen aufbauen, die von jedem getrennt beobachtet werden. Eine ausgezeichnete Zustellbarkeit bei Gmail garantiert nichts bei Outlook, und umgekehrt — beide Filter ziehen ihre Schlüsse aus ihren eigenen Nutzern, nicht aus einem zwischen Anbietern geteilten Referenzsystem. Daher der Nutzen, beide zu überwachen (über Postmaster Tools und SNDS), statt anzunehmen, dass ein guter Wert beim einen für den anderen gilt.

Zusammenfassung

Die Grundlagen DMARC/SPF/DKIM sind universell und werden nur einmal konfiguriert. Was sich bei Microsoft ändert, sind die Sichtbarkeitswerkzeuge (SNDS, JMRP) und die Tatsache, dass sich die Reputation dort unabhängig von der bei Gmail erworbenen aufbaut. Ein ernsthaftes DMARC-Deployment deckt beide Ökosysteme von Anfang an ab, ohne einen für eines von ihnen spezifischen Zustellbarkeitsvorfall abzuwarten, um sich darum zu kümmern.

Um zu überprüfen, dass die Authentifizierung korrekt konfiguriert ist — die identische Voraussetzung unabhängig vom Empfänger — genügt ein Durchlauf der Domain durch den kostenlosen DMARC-Analysator. Das ist der gemeinsame Ausgangspunkt für beide Ökosysteme; die Reputationsüberwachung spielt sich danach getrennt bei jedem einzelnen ab.