Outlook- und Hotmail-Adressen überprüfen: Was wirklich funktioniert

Outlook- und Hotmail-Adressen lassen sich per SMTP prüfen, ohne etwas zu senden, aber „Microsoft“ sind in Wirklichkeit drei verschiedene Systeme. Das private Outlook.com (hotmail, live, msn) antwortet bei nicht verfügbaren Postfächern mit 550 5.5.0. Microsoft 365 mit Edge Blocking lehnt unbekannte Empfänger mit 550 5.4.1 ab. 365 hinter einem Gateway oder im Hybridmodus nimmt womöglich alles an. Stellen Sie zuerst fest, mit welchem System Sie es zu tun haben.

Die meisten Anleitungen werfen all das unter „Outlook“ in einen Topf, und deshalb widersprechen sich die Ratschläge zur Verifizierung so sehr. Dieser Beitrag unterscheidet die Systeme zuerst anhand von DNS-Abfragen, die wir am 1. Oktober 2026 durchgeführt haben, und stützt sich dann auf Microsofts eigene Dokumentation dazu, was jedes System antwortet.

Schritt 1: Herausfinden, mit welchem Microsoft Sie sprechen

Der MX-Eintrag verrät, welches System antwortet, und jedes System antwortet anders. Das hat dig MX für eine Reihe von Domains geliefert, die bei Microsoft gehostet werden:

Domain	MX-Host	System
outlook.com	outlook-com.olc.protection.outlook.com	Privates Outlook.com
hotmail.com	hotmail-com.olc.protection.outlook.com	Privates Outlook.com
live.com	live-com.olc.protection.outlook.com	Privates Outlook.com
msn.com	msn-com.olc.protection.outlook.com	Privates Outlook.com
hotmail.co.uk, outlook.fr	eur.olc.protection.outlook.com	Privates Outlook.com (europäische Regionaldomains)
microsoft.com	microsoft-com.mail.protection.outlook.com	Microsoft 365 (Exchange Online)
Ein Unternehmen hinter einem Security-Gateway	z. B. ein pphosted.com-Host	Unbekannt: Es antwortet das Gateway, nicht Microsoft

Das Muster ist einfach. olc.protection.outlook.com steht für ein privates Postfach. mail.protection.outlook.com steht für einen Firmenmandanten bei Microsoft 365. Alles andere bedeutet – selbst bei einem Unternehmen, von dem Sie wissen, dass es intern Outlook nutzt –, dass ein Gateway eines Drittanbieters davorgeschaltet ist und Sie gegen dessen Regeln verifizieren. Dieselbe Abfrage können Sie für jede Domain mit dem MX-Lookup-Tool durchführen.

Privates Outlook.com, Hotmail, Live und MSN

Microsofts Server für Privatkunden können nicht verfügbare Postfächer schon im Schritt RCPT TO ablehnen, aber die Ablehnung ist weniger eindeutig als bei Gmail. Die Antwort, die Sie sehen werden, lautet:

550 5.5.0 Requested action not taken: mailbox unavailable

Genau dieser Text taucht in Bounce-Protokollen auf, die in Microsofts eigenem Q&A-Forum gepostet wurden. Microsoft veröffentlicht für die SMTP-Antworten seines Privatkundendienstes keine Referenztabelle, wie Google es für Gmail tut. Die Bedeutung muss man also aus dem Verhalten ablesen.

Und genau dieses Verhalten ist das Problem. Im selben Q&A-Thread berichtete ein Absender, dass Nachrichten an dieselben Outlook.com-Postfächer bei manchen Versuchen zugestellt und bei anderen mit 550 5.5.0 abgelehnt wurden. Als eine der Ursachen wurde diskutiert, dass einige der Konten gesperrt waren und eine Telefonverifizierung erforderten, bevor sie wieder E-Mails empfangen konnten.

550 5.5.0 von einem Microsoft-Server für Privatkunden kann also bedeuten:

• Die Adresse hat nie existiert oder wurde geschlossen. Als ungültig behandeln.
• Das Konto existiert, ist aber gesperrt oder ausgesetzt. Eine echte Person, die gerade nicht erreichbar ist.

Vergleichen Sie das mit Gmail, wo 550 5.1.1 „existiert nicht“ bedeutet und ein eigener Code, 550 5.2.1, „inaktiv“. Siehe wie Sie prüfen, ob eine Gmail-Adresse existiert. Bei Microsofts Privatkunden-Mail ist ein einzelnes 550 ein guter Beleg, und ein 550 bei zwei Prüfungen, die einen Tag oder mehr auseinanderliegen, ein starker Beleg.

Hotmail-Adressen verfallen schneller als die meisten

Microsoft schließt ungenutzte private Postfächer nach einem Jahr. Dadurch verfallen alte Listen mit vielen Hotmail-Adressen schnell. Microsofts Supportseite zu fehlenden Outlook.com-E-Mails sagt: „Wenn Sie sich nicht mindestens einmal innerhalb eines Jahres bei Ihrem Outlook.com-Postfach angemeldet haben, schließt Microsoft Ihr Outlook.com-Postfach, und alle E-Mails werden gelöscht“ („If you haven't signed in to your Outlook.com mailbox at least once in a one-year period, Microsoft will close your Outlook.com mailbox and all email will be deleted.“). Der Microsoft-Servicevertrag ergänzt, dass man sich „mindestens einmal innerhalb von zwei Jahren anmelden muss, um das Microsoft-Konto“ aktiv zu halten („must sign in at least once in a two-year period to keep your Microsoft account“).

Bei Google liegt die entsprechende Frist für private Gmail-Konten bei zwei Jahren. Eine Privatkundenliste mit vielen hotmail.com- und live.com-Adressen, die seit einem Jahr oder länger weder angeschrieben noch verifiziert wurde, sollte neu verifiziert werden, bevor irgendetwas anderes mit ihr passiert. Siehe wie oft Sie Ihre Liste neu verifizieren sollten.

Eine Aussage von Microsoft dazu, ob eine geschlossene Outlook.com-Adresse später von jemand anderem registriert werden kann, haben wir nicht gefunden. Wir behaupten daher weder das eine noch das andere.

Firmenmandanten bei Microsoft 365

Eine Microsoft-365-Domain, deren Postfächer alle in der Cloud liegen, lehnt unbekannte Empfänger schon am Rand des Netzwerks ab, und zwar mit einem dokumentierten Code. Die Funktion heißt Directory-Based Edge Blocking (DBEB). Laut Microsofts DBEB-Dokumentation „blockiert der Dienst die Nachricht, noch bevor überhaupt gefiltert wird“ („the service blocks the message before filtering even occurs“), wenn eine Adresse nicht existiert. Die Antwort sieht so aus:

550 5.4.1 Recipient address rejected: Access denied

Microsofts NDR-Referenz für Exchange Online beschreibt diesen Code in einer Zeile: „The recipient's address doesn't exist“ (die Empfängeradresse existiert nicht).

Zwei Dinge sorgen hier oft für Verwirrung.

Die Worte „Access denied“ klingen nach einer Sperre, nicht nach einer falschen Adresse. Absender sehen 5.4.1 ... Access denied, nehmen an, ihre IP stehe auf einer Blocklist, und fangen an, ihre Reputation zu untersuchen. Für einen einzelnen Empfänger bei RCPT TO ist es aber eine Adresse, die nicht existiert. Eine echte Sperre wegen Reputation oder Richtlinien kommt mit einem anderen Code, meist aus der 5.7.x-Familie, etwa 550 5.7.1.

Derselbe Code 5.4.1 hat eine zweite Bedeutung. Die NDR-Referenz führt auch 5.4.1 Relay Access Denied auf, was bedeutet: „The mail server that's generating the error doesn't accept mail for the recipient's domain“ (der Mailserver, der den Fehler erzeugt, nimmt keine E-Mails für die Domain des Empfängers an). Das deutet auf ein DNS- oder Konfigurationsproblem beim Empfänger hin, nicht auf ein totes Postfach. Lesen Sie den Text nach dem Code, nicht nur die Zahl. Die allgemeine Seite zu 550 5.4.1 behandelt beide Fälle.

Wenn Microsoft 365 alles annimmt

DBEB funktioniert nur, wenn Microsoft jede gültige Adresse kennt. Manche 365-Domains nehmen deshalb unbekannte Empfänger an und verhalten sich wie Catch-all. Die DBEB-Dokumentation sagt ausdrücklich, dass die Funktion greift, wenn „alle Empfänger Ihrer Domain in Exchange Online sind“ („all recipients for your domain are in Exchange Online“). Während Migrationen wird die Domain auf Internal relay statt Authoritative gestellt, und in diesem Modus werden E-Mails an unbekannte Adressen weitergeleitet, statt am Rand abgelehnt zu werden. Microsoft weist außerdem darauf hin, dass selbst bei aktiviertem DBEB „in seltenen Fällen Empfängeradressen, die in Ihrer Microsoft-365- oder Office-365-Organisation nicht existieren, über den Dienst weitergeleitet werden können“ („There might be infrequent instances where recipient addresses that don't exist in your Microsoft 365 or Office 365 organization are allowed to relay through the service.“).

Dasselbe gilt für Unternehmen, deren MX auf ein Security-Gateway eines Drittanbieters zeigt. Das Gateway entscheidet, wie geantwortet wird, und ein Gateway, das erst annimmt und die Zustellung später regelt, sieht von außen genau wie ein Catch-all aus.

In beiden Fällen ist das Ergebnis dasselbe wie bei jeder Catch-all-Domain: Eine erfundene Adresse wird angenommen, also lässt sich keine Adresse der Domain bestätigen. Ein Verifizierungstool, das zuerst eine zufällige Adresse testet, erkennt das und meldet riskant.

Alles zusammengefasst

Was Sie sehen	System	Urteil
550 5.5.0 Requested action not taken: mailbox unavailable	Privates Outlook.com	Ungültig, aber erneut prüfen, bevor Sie einen großen Anteil löschen, denn gesperrte Konten erzeugen diese Antwort ebenfalls
550 5.4.1 Recipient address rejected: Access denied	Microsoft 365 mit DBEB	Ungültig
550 5.4.1 Relay Access Denied	Microsoft 365, falsch konfigurierte Domain	Problem der Domain. Riskant
250 für die echte Adresse und für eine zufällige	365 im Modus Internal relay oder ein Gateway	Catch-all. Riskant
250 für die echte Adresse, 550 für eine zufällige	Beide	Gültig
Timeout oder eine vorübergehende 4xx-Antwort	Beide	Unbekannt. Später erneut versuchen

An Microsoft senden, nachdem Sie verifiziert haben

Die Verifizierung entfernt die toten Postfächer; ob der Rest Ihrer E-Mails angenommen wird, entscheiden Microsofts Regeln für Absender. Seit dem 5. Mai 2025 setzt Microsoft für Domains, die mehr als 5.000 Nachrichten pro Tag an seine privaten Postfächer senden, eine Authentifizierung durch. Die Ankündigung verlangt SPF, DKIM und DMARC, kündigt an, dass nicht konforme E-Mails mit „550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level“ abgelehnt werden, und nennt als Best Practice: „Entfernen Sie ungültige Adressen regelmäßig, um Spam-Beschwerden, Bounces und verschwendete Nachrichten zu reduzieren“ („Remove invalid addresses regularly to reduce spam complaints, bounces, and wasted messages.“).

Die Einträge Ihrer eigenen Domain können Sie mit dem Zustellbarkeits-Audit prüfen. Alle Anforderungen von Microsoft finden Sie unter Anforderungen von Microsoft Outlook an Bulk-Sender. Warum Outlook angenommene E-Mails trotzdem in den Junk-Ordner verschiebt, erklärt „Warum E-Mails im Junk-Ordner von Outlook landen“.

Das Fazit für die Praxis

1. Sortieren Sie Microsoft-Adressen nach MX in privat (olc.protection.outlook.com), Microsoft 365 (mail.protection.outlook.com) und hinter einem Gateway.
2. Behandeln Sie 550 5.4.1 Recipient address rejected als ungültig und verwechseln Sie es nicht mit einer Sperre.
3. Behandeln Sie ein privates 550 5.5.0 als ungültig, aber prüfen Sie erneut, wenn ein großer Teil einer ansonsten guten Liste diese Antwort liefert.
4. Rechnen Sie damit, dass manche 365- und Gateway-Domains Catch-all sind, und behandeln Sie sie als riskant.
5. Verifizieren Sie Listen mit vielen Hotmail-Adressen nach einem Jahr neu, denn dann schließt Microsoft ungenutzte Postfächer.

Um zu sehen, welcher dieser Fälle auf eine bestimmte Adresse zutrifft, zeigt der kostenlose E-Mail-Checker Ergebnis und Grund für jeweils eine Adresse.