[English]Microsoft hat ein Problem mit seinen Exchange Online-Instanzen, das seine Kunden leicht ins Abseits schießt. Die Absender-Domains für Mails werden als Spam klassifiziert und abgelehnt. Führt dazu, dass Firmen keine Mail mehr versenden können. Nachdem ich das hier im Blog mehrfach thematisiert habe, hat mir ein Blog-Leser die Bestätigung durch Microsoft zukommen lassen.
Anzeige
Microsoft 365: Mails werden als SPAM abgewiesen
Es ist ein Thema, welche Administratoren von Microsoft 365/Exchange Online-Instanzen zur Verzweiflung treibt. Die abgeschickten E-Mails werden vom Empfänger als SPAM zurückgewiesen. Ich hatte erstmals im Blog-Beitrag Microsoft IP-Adressen auf Blacklists gelandet (Jan. 2023) berichtet, dass Nutzer von Exchange Online in Probleme mit der Mail-Zustellung laufen, weil IP-Adressen, die Microsoft hält, auf Sperrlisten (Blacklists) landen.
Bei den Kunden des Lesers betraf es die IP-Adresse 40.107.20.44. Das wurde zwar bereinigt, aber der nächste Fall schlug Mitte Februar 2024 bei mir ein. Ich hatte im Beitrag Mail-Zustellungsprobleme: Microsoft 365/Exchange Online; 1&1 IONOS-Status; Vodafone über entsprechende Probleme berichtet. Microsoft war mit diversen IPs wieder auf einer Sperrliste (Black-List) gelandet, so dass keine Mails zugestellt werden konnten. Das betraf in Bayern ein Behörden-"Netzwerk", wo keine Mails über Exchange Online bei den Empfängern zugestellt werden können.
Auch Google nimmt keine Mails mehr von Microsoft an, wie ich in einem Beitrag erwähnt habe (siehe Links am Artikelende). Es gibt im Microsoft Answers-Forum seit dem 3. März 2023 den Thread Emails being blocked by Gmail from office 365, der sich mit dem gleichen Phänomen beschäftigt. Der Thread umfasst bereits viele Seiten, es ist also ein größeres Problem, was wohl nie angegangen wurde.
Anzeige
Microsoft bestätigt SPAM-Problematik
Ein Blog-Leser weist in diesem Kommentar hin, dass die Meldung bereits "seit längerem" im Azure-Admin-Portal eine Meldung ausgegeben werden, dass die ausgehenden Exchange Online-E-Mail-Nachrichten einiger Benutzer möglicherweise als Spam markiert und nicht zugestellt werden. Das läuft seit dem 26. Februar 2024 und hält an.
Blog-Leser Andreas P. hat mir nun einige Statusauszüge aus dem Azure- bwz. Microsoft 365-Admin-Portal zukommen lassen, die mir zeigen, dass Microsoft sich inzwischen der Problematik bewusst ist. Die erste Volltext-Nachricht im Statusbereich scheint vom 26. Februar 2024 zu stammen. Hier der Text.
Published Time: 26.02.2024 05:51:48
Title: Some users' outbound Exchange Online email messages may be marked as spam and not delivered
User impact: Users' outbound Exchange Online email messages may be marked as spam and not delivered.
More info: This isn't connection method specific and thus occurs in all Exchange Online connection methods. Affected users receive a Non-Delivery Report (NDR) message that references the third-party anti-spam service name that has added the IP address to their block list.
Current status: We're currently investigating service side logs as well as affected IPs provided by some reporting users to pinpoint the cause of impact and cultivate our troubleshooting steps.
Scope of impact: The problem may impact some users sending outbound email messages if they're leveraging a specific third-party anti-spam service mentioned within the NDR.
Next update by: Monday, February 26, 2024, at 6:30 AM UTC
Published Time: 26.02.2024 05:35:13
Title: Some users' outbound Exchange Online email messages may be marked as spam and not delivered
User impact: Users' outbound Exchange Online email messages may be marked as spam and not delivered.
Current status: We're investigating a potential issue and checking for impact to your organization. We'll provide an update within 30 minutes.
Diese Statusaktualisierungen werden in zyklischen Abständen veröffentlicht. Mir lieg der letzte Statusauszug vom 6. März 2024 im Volltext vor. Dort finden sich folgende Hinweise:
Published Time: 06.03.2024 21:48:27
Title: Some users' outbound Exchange Online email messages may be marked as spam and not delivered
User impact: Users' outbound Exchange Online email messages may be marked as spam and not delivered.
More info: This isn't connection method specific and thus occurs in all Exchange Online connection methods. Affected users receive a Non-Delivery Report (NDR) message that references the third-party anti-spam service name that has added the IP address to their block list.
Current status: We're working with the third-party anti-spam service to better identify the IP
address ranges affected by this problem, so that we can more quickly identify and manage sources of potentially malicious email messages. This will help reduce the frequency of spam and phishing email, which would also reduce the number of reported and blocked IP addresses, returning some mail flow as expected. In parallel, we're reviewing long-term solutions to prevent similar problems.
Scope of impact: The problem may impact some users sending outbound email messages if they're leveraging a specific third-party anti-spam service mentioned within the NDR.
Root cause: A third-party anti-spam service is blocking a portion of Microsoft's email IP address ranges to protect organizations that use their services.
Next update by: Friday, March 8, 2024, at 9:00 PM UTC
Dieses Problem ist laut Microsoft nicht verbindungsmethodenspezifisch und tritt daher bei allen Exchange Online-Verbindungsmethoden auf. Das heißt, das Experimentieren mit DKIM-Einträgen etc. hilft in der Regel wenig. Betroffene Benutzer erhalten weiterhin eine NDR-Nachricht (Non-Delivery Report), die auf den Namen des Anti-Spam-Dienstes eines Drittanbieters verweist, der die IP-Adresse zu seiner Blockierliste hinzugefügt hat.
Aktuell bleibt Microsoft nicht anderes übrig, als mit dem Anti-Spam-Dienst des Drittanbieters zusammen zu arbeiten, um die betroffenen IP-Adressbereiche besser zu identifizieren und von den Block-Listen herunter zu bekommen.
Ähnliche Artikel:
Microsoft IP-Adressen auf Blacklists gelandet (Jan. 2023)
Mail-Zustellungsprobleme: Microsoft 365/Exchange Online; 1&1 IONOS-Status; Vodafone
Microsoft 365: Versand zu GMail, Yahoo & Co. als SPAM abgewiesen
Anzeige
Mit „connection method" meint Microsoft üblicherweise die Art der Verbindung zu EXO, also Web, Outlook Client, usw., was natürlich hier vollkommen irrelevant ist.
Ja da rächt es sich wenn man alles in der Cloud bei Microsoft hat. Wenn die da zig IPs zusammenklöppeln und sich wundern wenn dann alles als Spam markiert wird ist es schon traurig. Das wird noch lustig werden wenn die das nicht in den Griff bekommen.
Kann ich nur bestätigen. OneDrive macht seit Monaten massive Synchronisationsprobleme und Datenverlust habe seit Wochen Kontakt mit Support der mir das letzte Woche bestätigte. Zudem ist der Explorer nicht mehr fähig in gewohnter Art und Weise zu arbeiten. 5 GB dauern bis zu 16 Std Synchro bei funktionierenden Internet mit 250 Mbs. Ich bin nun ganz umgestiegen auf iCloud das ich schon 12 Jahre ohne große Vorkommnisse habe.
Die Cloud ist ein Irrweg.
Microsoft ist sowie Gmail ne Spamschleuder.
Sind korrekt ständig auf Spamlisten. Wer dort professionell Mails versendet muss sich nicht wundern.
Nicht nur die beiden, sondern potentiell alle Cloudanbieter/Hoster. Die Spammer können direkt VMs mieten oder indirekt über schlecht gesicherte MTAs bzw. abgeschöpfte Logins arbeiten. Die Hoster spielen da ständig Whac-a-Mole. Manche machen das recht gut; andere sind weniger erfolgreich. Und wenn ein Anbieter momentan viele Spammer im Netz hat, kommt er halt auf die RBLs. Etwas Schadenfreude darf schon sein, da MS selber gerne MTAs kleinerer Netze aussperrt (muss man freischalten lassen).
"Das betraf in Bayern ein Behörden-"Netzwerk", wo keine Mails an Exchange Online zugestellt werden können.
Auch Google nimmt keine Mails mehr von Microsoft an, .."
Das klingt für mich so, als würde Exchange Online keine Emails von Microsoft annehmen.
Sollte das nicht "Das betraf in Bayern ein Behörden-"Netzwerk", wo keine Mails von/via Exchange Online zugestellt werden können" heißen?
Nein. Mails von bayrischen Behörden an Exchange Online Konten wurden nicht zugestellt. Das betroffene "Netzwerk" ist für die Behörden der Weg aus dem eigenen Netz in das öffentliche Netz. Salopp gesprochen konnte also ganz Bayern keine einzige Mail an ein externes Mailkonto schicken, sobald dieses Konto über Exchange Online (oder wie immer Winzigweich das Geraffel gerade nennt) verwaltet wurde.
@Pau1
Das betraf in Bayern ein Behörden-"Netzwerk", wo keine Mails über Exchange Online bei den Empfängern zugestellt werden können.
Danke, aber das ergibt doch keinen Sinn.
Es werden doch Exchange Mail Outs durch die Blacklist gesperrt, die von Gmail Mail in verwendet werden.
Es sperrt sich das Exchange ja nicht selbst.
Das Behörden-"Netzwerk" konnt keine E-Mail an Kunden mit Gmail Account senden, weil sie dafür MS outgoing nutzen. Oder hat Behörden-"Netzwerk" etwas anderes verwendet, das verhinderte dass emails von Microsoft-Kunden angenommen wurden?
Chef ruft an: Tja Chef – Auftrag ist weg, die Cloud hängt gerade wieder. Ja DIE Cloud, die sie doch so gerne wollten. Können wir nix machen, sind IPs von M$. Doch das hatten wir vor der Migration streng angesprochen. Der Dienstleister ? Ja der hatte tolle Slides – sau geil – aber halt eher Kindergarten. Das dauert, bis die RBLs wieder sauber sind – nein wir können da nichts machen. Ja, onprem könnten wir schneller bei den RBLs reagieren.
Aber ehrlich Chef, ist doch ne geile Unterhaltung und darauf stehen sie doch. Sie sind doch der Spieler Typ.
Ja, sie können das Angebot auch noch mit unserem Fax schicken oder per Post.
weiß wer welche Blacklist es ist, wieder spamcop?
Bei der vielzahl der kompromitierten Konten im M365 Umfeld eigentlichlich nicht verwunderlich, dass Spam Dienstleister das zunehmend blocken werden.Viel mehr wundert mich dass solche Robleme nicht noch wesentlich häufiger auftreten.
"Aktuell bleibt Microsoft nicht anderes übrig, als mit dem Anti-Spam-Dienst des Drittanbieters zusammen zu arbeiten, um die betroffenen IP-Adressbereiche besser zu identifizieren und von den Block-Listen herunter zu bekommen."
Für Microsoft gibt's da nichts zu "verhandeln".
Microsoft muß primär dafür sorgen, das über seine outgoings kein Spam versendet wird.
"Aber wir sind doch so groß, wie sollen wir hundert tausende, ja Millionen von Users überwachen? Also dürft ihr unsere IPs nicht auf die Liste aufnehmen"
Das würde dem Sinn der RBLs widersprechen und es wird keine RBL da mitmachen.
Es gab einmal eine Initiative zum Whitelisten seriöser Outgoings. Damit sollte seriöse Anbieter z.B. Newsletter verschicken dürfen. Ich glaube es gab das Problem, das es keine Seriösen Newsletter Versender gab.
Und wer würde Microsofts outgoing da aufnehmen?
Microsoft will alle anderen Mail Provider kaputt machen, in dem sie Spam fördern und so die E-Mail Zustellung durch Dritte unzuverlässig machen.
auch diese Aussage findet Ihr von mir in meinem Video über den massiven Spam von Microsoft und unter ständigem Umgehen der RFC Regeln:
https://youtu.be/oENudGiPqxs?si=vqfvoOJ2ChM4asbQ
SMTP basiertes Messaging braucht eben Prozesse, die in der realen analogen Welt dem Ausweis/Ticket und einer Einlasskontrolle nachempfunden sind. Seriöse Geschäftskommunikation braucht schon heute wegen der Compliance diverse Zertifikate und MFA. Da spielt Cloud oder OnPremise keine Rolle.
Ist immer wieder herrlich, wie hier so wunderbar verallgemeinert wird. Weder ich noch einer meiner zahlreichen Microsoft-365-Geschäftskunden hat in den vergangenen Jahren jemals eine unberechtigte Nichtzustellbarkeitsmeldung erhalten oder sie mir nicht mitgeteilt, was sehr unwahrscheinlich ist. Sollte einer der Myriaden von Cloud-SMTP-Gateway-Servern tatsächlich mal in einer DNSBL landen – das dürfte immer mal wieder der Fall sein, wird Microsoft den vermutlich temporär nicht nutzen, zumindest, wenn man sich an den Support wendet, z. B. über https://admin.microsoft.com. Das klappt bei Problemen regelmäßig (wenn auch nur äußerst selten nötig) vorzüglich, und das ab 5,60 € monatlich auch für Einzelkämpfer-Unternehmen mit Microsoft 365 Business Basic. Man wird kurzfristig zurückgerufen und das Problem wird beseitigt, oder sie bleiben so lange mit Hochdruck dran, bis das der Fall ist. Ohne weitere Kosten.
Auf der Admin-Startseite unter "Gesundheit" findet man den Service-Status der Unmengen von Diensten, mit denen es regelmäßig irgendwelche Probleme irgendwo auf der Welt für irgendwelche Anwendergruppen gibt. Das ist fast immer der Fall! Daraus pauschal zu folgern, "Google nimmt keine E-Mails von Microsoft mehr an", ist einfach nur lächerlich und zeugt von wenig Fachwissen. Es seit denn, man ergänzt solche Aussagen mit "einige Anwender von…". Aber das ist halt uncool.
Es mag in dem Fall hier durchaus vermehrt vorgekommen sein, vermutlich dennoch wie üblich eher bei 0,0000001 % der ausgehenden SMTP-E-Mails…
Ich lasse mich gerne durch fundierte Statistiken eines Besseren belehren.
Es mag ja sein, dass Microsoft dran bleibt – es zumindest so aussieht.
Aber wenn Du mit den Spezialisten (E5 Account) mal zu tun hast und sie können sich nicht erklären, warum ein Defender ATP die Verbindungen auf TCP 80 vom CryptSvc immer wieder blockiert, dann musst Dich schon fragen was das soll oder warum ein DNS request auf Port 53 ein uncommon port sein soll. Anmerkung: Der CryptSvc von Windows ist für die Validierung von Zertifikaten da, das geschieht über CRL oder OCSP Zugriffe und bei CRL ist http (TCP 80) "normal".
Für normale Fälle mag der Support okay sein, aber sobald es tiefer geht, wird auch nur versucht den Kunden abzuwimmeln. Bzw. Du sollst die Situation nachstellen, wenn überhaupt nicht klar ist, warum der Defender etwas blockiert und Du genau deswegen den Support call offen hast.
Oliver, ich kann Dir von einen E5 Account nur sagen, dass ich (belegbar) an einem Sonntag um 14:02 CET eine E-Mail versendet habe (inkl. Vermerk an der original E-Mail auf die ich geantwortet habe) und diese E-Mail ist am darauffolgenden Tag um 08:00 zugestellt worden und trug alle timestamps von 8 Uhr CET.
Keine Mitteilungen über die Verzögerungen, nichts, ich habe die E-Mail (aus dem Verteiler wo ich auch drauf bin) auch untersucht, kein einziger timestamp aus den Received auf Vortag 14 Uhr.
Da funktioniert definitiv etwas nicht sauber.
Ich glaube, du bekommst erst nach 24h eine Verzögerungsmitteilung, und nach 4 (?) Tagen gibt Exchange dann auf und schickt dir die Info, dass nicht zugestellt werden konnte. Will man mehr oder schnellere Infos, müsste man das Log selbst überwachen oder zumindest bei Verdacht mal reinschauen und filtern.
Zum Test schicke ich mir einige wenige E-Mails, bei denen ich später sagen könnte, das sie verschickt wurden (z. B. Newsletter), per BCC an ein privates gmx-Konto. Bisher zumindest klappt das noch, was natürlich nicht heißt, dass es aktuell noch Probleme gibt oder gegeben hat.
Hi Oliver,
und wenn Du Testmails verschickst, dann geheiratet generierst Du auch maschinell überprüfbare Inhalte um später festzustellen, welche Email nun um wieviele Stunden in ExO verzögert wurde?
Die 2. Email an die Kollegen habe ich kurz nach 20 Uhr abends (6 Stunden später) verschickt und die kam sofort an. Zumindest kam sie 12 Stunden früher an als die erste. Und wie gesagt, die timestamps in der ersten Email waren Fake!
Ein Produkt das Emails entgegen nimmt, behauptet etwas verschickt zu haben und bei der Zustellung sind alle Daten 18 Stunden später aufgeführt ist nicht reliable.
Und wenn Du hier andere Forenten darauf hinweist, dass sie nicht wissen würden wie DNSBL arbeiten, darf ich Dir in Vertretung desjenigen schreiben, dass es einem Produkt überlassen bleibt wie eine DNSBL eingesetzt wird, so kann man diese – was ich mache – einsetzen um SMTP traffic bereits beim Dialog zu blockieren. Man kann sie aber auch einsetzen um bereits empfangene Emails weiter zu klassifizieren (zum Beispiel durch Betrachtung der Einträge in den Received Zeilen). Es gibt schließlich zig verschiedene DNSBL und man kann auch eigene erstellen und nutzen.
Interessant ist das Problem natürlich.
Ich konnte bei einem Kunden am Sonntag auch etwas beheben was durchaus damit zusammenhängen könnte.
Dort wurde auf Projektanforderung der Zugriff auf Webmail unterbunden. Dazu gehörte auch "outlook.live.com"!
Nun hat Microsoft (wie angekündigt) den public webmail service (der mit dem vielen SPAM) mit Exchange Online verheiratet. Damit wurde bei diesem Kunden der Zugriff auf Exchange Online (gleiche Protokolle, gleiche IP Adressen) plötzlich blockiert.
Was ich mir nun vorstellen könnte, dass ein Anti-Spam Dienstleister das Vorhandensein von outlook.live.com IP Adressen in den Received Headern bereits als "hohe SPAM Wahrscheinlichkeit" sieht und damit Teile der Exchange Online Emails per false positive blockiert wird.
Ist ja nur so ein Gedanke
Sinnlos , weil man mittlerweile selbst der doofe ist wenn man die MS Mails auf Grund Blacklistfilterung nicht annimmt als Nicht-MS Kunde.
Dann verstehst du nicht, wie DNSBL funktioniert, dass der Absender (also hier Exchange 365 Nutzer, nur zum Beispiel) natürlich eine Nichtzustellbarkeitsmitteilung erhält und die E-Mail daher nochmals versenden wird. Zumindest professionelle E-Mail-Systeme melden dir, wenn eine E-Mail nicht zugestellt werden konnte und exakt aus welchem Grund, d. h. die Rückmeldung des Empfangs-Servers oder es eigenen Gateways, wenn dies gar erst keine Socket-Verbindung zum Ziel-Host aufbauen konnte. Der Empfänger bekommt davon nichts mit. Das alles gilt natürlich nicht nur für Microsoft.
Servus,
ist seit gestern wieder etwas im Gange bei MS?
Bei einem Kunden und bei mir selbst im Ex Online landen viele viele Nachrichten in Quarantäne "Nachricht mit hoher Phishingwahrscheinlichkeit"…
Die Absender sind absolut sauber und der Nachrichteninhalt nichts schlimmes…
Viele Grüße,
Stephan