Microsoft 365: Versand zu GMail, Yahoo & Co. als SPAM abgewiesen

MailProbleme mit dem Versand von E-Mails über Outlook 365 und Microsoft-Mail-Servern an Empfänger bei Google-Mail, Yahoo und &Co.? Die E-Mails werden als SPAM klassifiziert und abgewiesen. Ein Blog-Leser hat mich auf diese unschöne Entwicklung hingewiesen und einen Workaround entwickelt.


Anzeige

Zustellprobleme bei Microsoft 365/Exchange Online

Entwickeln die Microsoft E-Mail-Server (Exchange Online) so langsam zum Sorgenkind von Administratoren in IT-Dienstleistern? Ich hatte im Januar 2024 im Beitrag Microsoft IP-Adressen auf Blacklists gelandet (Jan. 2023) darüber berichtet, dass Nutzer von Exchange Online in Probleme mit der Mail-Zustellung laufen, weil IP-Adressen, die Microsoft hält, auf Sperrlisten (Blacklists) landen.

Geblockte Microsoft IP

Ein Leser schrieb, dass er bei einem Kunden darauf gestoßen sei, dass wohl einige Microsoft IP-Adressen auf Blacklists stehen und deswegen beim E-Mail-Versand abgelehnt werden. Bei seinem Kunden 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 an Exchange Online zugestellt werden können.

Auch GMail erkennt SPAM

Tecci, der als IT-Dienstleister arbeitet, hat mich die Woche in einer persönlichen Nachricht auf Facebook darüber informiert, dass er bei Kunden auch auf das Problem stößt, dass GMail keine Mails von Microsoft 365/Exchange Online annimmt, sondern diese als SPAM abweist. Der Absender erhält dann die nachfolgende Benachrichtigung:

Geblockte Microsoft Mail durch gmail.com

Der Nutzer wird informiert, dass gmail.com vermutet, dass es sich bei der Nachricht um SPAM handelt. Es gibt den Hinweis, dass Aktionen erforderlich sind. Tecci hat sich dann die Fehlerdetails der abgelehnten Mail angesehen und folge Informationen erhalten.

Die Nachricht wurde von mx.google.com abgelehnt und an den Absender zurück geschickt, weil GMail SPAM vermutet. Es wird das Fehlerdetail 550 5.7.350 gemeldet.


Anzeige

Meldung bei Microsoft Answers

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. Im betreffenden Post findet sich ein "How to fix it?"-Abschnitt, der Hilfe verspricht (die Nachricht soll nur anderes formuliert werden). Das scheint aber nicht zu klappen.

Umstellung des Connectors auf IPv4

Tecci schreibt in seinem eigenen Beitrag Versand aus MS365 zu gmail | googlemail | yahoo.com …. "550 5.7.350", in dem er das Problem zum 4. März 2024 aufgreift, dass die obige Lösung aus MS-Answers nicht wirklich zum Erfolg führe. Spätestens bei der nächsten Prüfung wird die Mail wieder als SPAM abgewiesen.

Tecci schreibt, dass das Problem auftritt, wenn die Mails per IPv6 über den Microsoft Mailserver versandet werden. In seinem Beitrag hat er dann den Connector in Microsoft 365 so umgestellt, dass die Nachrichten an GMail per IPv4 verschickt werden. Seit dieser Änderung soll die Mail-Annahme wieder funktionieren. O-Ton aus einer seiner Ergänzungen:

Was genau ich das getrieben habe, weiß man eigentlich nicht. Jedenfalls wird der Versand so getriggert, dass es am Ende funktioniert. BTW, das betrifft am Ende alles, was bei Google gehostet ist. Nicht nur gmail oder googlemail. Es betrifft auch Empfänger die mit Ihrer eigenen Domain die Google-Dienste nutzen. Bspw. HHK/Trimble um nur einen zu nennen.


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Cloud, Mail, Office, Störung abgelegt und mit , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

42 Antworten zu Microsoft 365: Versand zu GMail, Yahoo & Co. als SPAM abgewiesen

  1. Robert Glöckner sagt:

    meine Testmail ging problemlos durch

    Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on0717.outbound.protection.outlook.com. [2a01:111:f400:fe0c::717])
    by mx.google.com with ESMTPS id

    der Email-Header war überraschend groß, die Stelle gar nicht einfach zu finden…

    • Anonymous sagt:

      Hat es eventuell auch damit zu tun, dass Google und Yahoo nun DMARC puscht/verlangt?

      • Pau1 sagt:

        Ja, natürlich!
        man man, echt.
        Kein DMARC record geht gar nicht.
        Warum sollte man das nicht nutzen?
        Weil es ja auch ohne funktioniert…
        Es scheint absolute Unwissen zu herrschen.
        Aber klar, man hat ja alles an die Profis von MS ausgelagert.
        Warum sollte man sich da noch selbst Weiterbilden?

        Wer alles Emails administren darf und mit wie wenig Wissen erschreckt mich.
        Anwesende natürlich ausgenommen.

  2. Steven Koppers sagt:

    Hi,

    in dem Artikel ist eine Lösung verlinkt, einen Outbound Partner-Connector für die RemoteDomains googlemail.com und gmail.com zu erstellen und diesen zu den offiziellen MX-Records der Partnerorganisation zu senden unter Verwendung von TLS und einem gültigen Zertifikat einer trusted CA.
    In diesen MX-Records sind allerdings auch IPv6 Adressen hinterlegt und m.W.n. ist durch die Erstellung eines Outbound Connectors nicht explizir IPv6 abgeschaltet oder?

    Kann es sein, dass das Ganze nur funktioniert, weil dadurch (zufällig?) die IPv4 Adresse als Erstes verwendet wird?

    Oder stehe ich gerade irgendwie komplett auf dem Schlauch?

    Beste Grüße

    • Pau1 sagt:

      Du weißt schon was ein MX record ist und was der mit dem Versand Deiner E-Mails zu hat?
      Falls nicht?
      Der MX sagt nur, wo Deine E-Mails angeliefert werden sollen. Mehr nicht.
      Wo Deine E-Mails versendet werden steht im SPF und DMARC.
      In sofern ist es vollkommen wurscht, ob der MX IPv6 oder IPv4 ist.

      Unbedingt den Fehler vermeiden, mehrere IP in den MX einzutragen, wie davor 30 Jahren empfohlen wurde. Das gibt heut6nur noch Probleme weil die User davon ausgehen,das jede Email nach 30sec beim Empfänger ist. Zu blöd, wenn einer der redundanten MX unpässlich ist. Dann bleibt die Email da hängen.
      Aber niemand merkt es weil ja der andere MX noch funktioniert und abwechselnd benutzt wird.
      "keine Email" fällt auf, aber weniger?
      Der Absender der auf dem kaputten MX gelandet ist, merkt ja auch nichts davon. Erst nachdem er keine Reaktion bemerkt schickt er die E-Mail noch Mal, nun landet sie auf dem funktionierendrn MX
      Es gibt keinen Grund mehr, mehr als einen MX zufahren.
      Aber wenn es es ein DOS gibt. Dann sind auch 2 MXe weg.

      • Steven Koppers sagt:

        Hallo Pau1,

        vielen Dank für die Antworten, allerdings sind diese nicht in Bezug auf meine Frage und inhaltlich entweder unglücklich formuliert oder falsch.

        Der MX-Record ist weiterhin der Eintrag, in dem der Empfänger praktisch seine Zielsysteme für den Empfang von E-Mails angibt.
        An der Stelle besteht erst einmal kein Zusammenhang zu SPF und DMARC, welche auf Absendeseite (also wir in dem Falle) natürlich Gültigkeit haben muss, damit die Mails empfangen werden bzw. nicht im Spam landen oder abgewiesen werden.

        Dementsprechend bleibt die Frage, was der Unterschied seitens EXO ist zwischen:
        – Kein Partner-Connector zu gmail -> Wo ja m.W.n. der MX-Record standardmäßig verwendet wird (es sei denn MS macht dort irgendwelche "Magie")
        – Konfigurierter Partnerconnector zu gmail unter Verwendung des MX-Records -> Sofern die MS-"Magie" vorhanden ist, lässt sich das evtl. dadurch aushebeln, allerdings sehe ich keine Einstellung bzgl. "nur IPv4" verwenden und in den von gmail verwendeten MX-Records (wo übrigens mehrere Systeme drin stehen), gibt es sowohl IPv6, als auch IPv4 mit Derselben Priorität

        • Pau1 sagt:

          Was bitte ist ein "Partner konnector"?
          Hört sich sehr nach neuem Schlangenöl an.

          Natürlich hat der MX *Record* einer Domain nichts, aber gar nichts mit dem SPF oder DMARC zu tun.
          Der SPF sagt, welche IP E-Mails mit dieser Domain verschicken kann. Wenn das zig tausende sind wie bei Microsoft ist das natürlich als Spammer Schutz wirkungslos.
          Der DMARC zertifiziert, das diese E-Mail "echt" ist.
          Das ist auch nix was etwas mit dem MX zu tun hat.
          Natürlich muss der MX-host diese Recodes kenn und auswerten
          Aber ist dafü egal welcher Host den MX macht.

          • Steven Koppers sagt:

            Partner Connector ist ein Outbound Connector zu einer Partnerorganisation, wie er in der verlinkten Seite im Screenshot steht.
            Kein Schlangenöl, sondern ein Grundbaustein von EXO, ich habe mich lediglich umgangssprachlich ausgedrückt ;-)

            • Pau1 sagt:

              Interessanter Versuch etwas mit sich selbst zu erklären…

              Ich habe etwas gefunden und komme immer mehr zu der Annahme, das das mit diesem Microsoft nur ein völlig surrealer Alptraum drin kann.

              Also dieser Partner ist ein Art "Whitelisting"
              Lese ich da doch,
              "Exchange nutzt dabei den RFC8321-MAILFROM des Envelope und nicht den "RFC8322-FROM des SMTP-Headers."

              Irre. Komplett irre
              Aber kein serienmäßiges DKIM?

              Klar das Google diese Müllsysteme blockt.

              • Steven Koppers sagt:

                Ich habe lediglich für nicht EXO-affine Menschen die Unklarheit aus der Welt geschafft. :-)

                Ich rate Ihnen, sich erst einmal mit Exchange Online und seinen Funktionalitäten auseinanderzusetzen, da gibt es mehrere mehrtägige Schulungen davon, um die Zusammenhänge zu verstehen.

                Ein Microsoft Bashing ohne die notwendigen Hintergründe zu kennen ist nicht sachdienlich und beantwortet weiterhin nicht meine ursprüngliche Frage.

                Falls jemand das hier liest und die ursprüngliche Frage qualifiziert beantworten kann, wäre ich sehr dankbar, für mich macht die im Screenshot hinterlegte Konfiguration weiterhin keinen Sinn.
                In dem Artikel ist answers.microsoft.com hinterlegt und dort steht Folgendes:
                "Find some ipv4 ips for incoming smtp servers from google"

                Das macht technisch schon mehr Sinn, als wie in dem Screenshot einfach den MX-Record zu verwenden, sauber konfiguriert ist das natürlich überhaupt nicht, aber wann sind das Workarounds schon.

  3. anon sagt:

    schauen on spf und dkim im Einsatz sind und keine selfsigned Zertifikate verwenden. sind alles basics heute zu tage. um den begriff zu verwenden, stand der Technik
    https://blog.google/products/gmail/gmail-security-authentication-spam-protection/

  4. Wolf789 sagt:

    Mailverkehr über/an/von gmail oder googlemail ???
    Dejenige der das macht oder nicht um eine sicherere Maid-Adr. bittet, hat offenbar den letzten Schuß nicht gehört.
    Auf mailbox.org kann man dafür schon eine automatische Antwort mit der Ablehnung der Mail und diesem Ziel einrichten (war glaub ich auch auf Kuketz beschrieben – find ich aber auf die schnelle nicht).
    Aus diesem Grunde find ich das Problem gut und kann gerne so bleiben. Gilt auch für yahoo & Konsorten.

  5. Pau1 sagt:

    Generell sollte ein guter Postmaster per Cron job einmal täglich nachsehen, ob sein outgoing IP in einer Blacklist erscheint.
    Nur so kann er zeitnah reagieren.
    Warum sollte er das tun? Das ist doch alles bei Microsoft in der Cloud…
    Weil der E-Mail-Versand sehr lange auch trotz blacklist funktioniert und nur wenige solche blacklists zum blocken benutzen.
    Ein Postmaster hat dafür zu sorgen, das die E-Mails ankommen.

    Natürlich ist es für den KlickiBunti Admin nicht möglich zu testen, ob sein Outgoing Host in einer Blacklist steht: welche IP benutzt wird, bestimmt ja Microsoft. Und wer sich jemals den SPF record seiner Domain angesehen hätte, hätte gesehen, das tausbe von Microsoft IP emails für diese Domain verschicken dürfen. finde den Fehler…
    Man MUSS also seine emails6von einer eigenen festen IP versenden, will man zuverlässige E-Mails machen.

    Außerdem hatten wir ja schon festgestellt, das man auch als Microsoft-Opfer, DMARC/DKIM selbst aktivieren MUSS auch wenn man nicht so genau weiß was das ist. Die E-Mails macht ja Microsoft in der cloud. Da braucht man sich als klicki-bunti "Admin" doch nicht mehr drum kümmern.

    Also:
    1. DMARC aktivieren
    2. Die Outgoing Emails Uber eine Feste, eigene IP versenden
    3. Die User und den Chef informieren, dass sie wichtige Sachen per Telefon klären müssen weil Email nicht mehr so zuverlässig sein kann, weil das über die Microsoft-Cloud geht. You get what you pay for.
    There ain't no free lunch.
    Wer billig kauft, kauft zwei Mal.

    • Werner sagt:

      Genau,

      Punkt 2 läuft bei mir, weil komplett eigener Mailserver. WENN ich auf ner Blacklist lande, dann muss ich mal nach meinen eigenen Usern schaun, wer da über die Stränge schlägt. Probleme in über 10 Jahren: einmal nach Providerwechsel, die neue IP war 'verbrannt'.

      Manchmal ist das Problem, meiner nimmt nix an, weil irgendein Großprovider mal wieder nen Spammer als Nutzer hatte und daher auffer Blacklist gelandet ist… Das ist dann halt so.

  6. Martin B sagt:

    Versand an gmail stoppen, Empfang ebenso -> best practice!

    • Daniel sagt:

      Wenn du viele Android-Nutzer verärgern willst kannst du das ja machen. Aber viele technisch unbedarfte Nutzer nutzen eben die Email-Adresse die beim Einrichten des Smartphones eingerichtet wird eben weil es geht.

      Ja ich bin auch kein Freund von Gmail aber es ist eben so.

    • gigabernie sagt:

      Wenn man 30.000 Kunden mit @gmail.com hat-> worst practice!

  7. Hendrik Jan Boven sagt:

    Oh, warum bin ich nicht überrascht? Die hier erwähnte 40.107.20.44 löst bei mir bereits Allergien aus. Und gerade als ich dachte, dass ich nach Dutzenden von Mailheader-Analysen von Microsoft nicht noch tiefer sinken könnte, sah ich dies:

    Received: from SmtpServer.Submit by ZR0P278MB1249 with Microsoft SMTP Server id 15.20.7316.41; Fri, 1 Mar 2024 09:33:23 +0000

    Microsoft verwendet in seinem produktiven MS365 Service einen Server mit einem höchstwahrscheinlich Default Hostname, der dann an einen Host ohne Fullqualified Hostname weiterleitet. Aaarrrcch welcher Lernende hat hier gefummelt????

    Na ja MS ich hatte irgendwie besseres erwartet :-(

  8. Pau1 sagt:

    Es sei gestattet daran zu erinnern, dass Google die Dkim Prüfung erst oberhalb einer gewissen Email-Anzahl macht.
    Das erschwert natürlich eine Fehlersuche.

    Anyway.
    Welchen Grund gibt es seine Domain und eMails nicht mit DKIM zu schützen?
    Faulheit? Unwissenheit? Wurstigkeit?

    • Gigabernie sagt:

      Bei großen Providern gebe ich dir recht. Die haben wahrscheinlich aber weniger Probleme.
      Aber es gibt zig-tausend kleine Unternehmen, deren Provider oder Einrichter, entweder nicht mehr existieren, in Rente oder tod sind.
      Bis vor 1 Jahr hat ja noch alles (meistens) ohne DKIM und SPF funktioniert.
      Die wissen nichtmal, wie sie auf ihre DNS-Zone kommen, geschweige denn, was dort zu tun ist.
      Erzähl mal ner Buchhändlerin, dass sie diese Einstellungen machen soll…

    • Stefan sagt:

      Exchange kann schon mal von sich aus kein DKIM, oder eben die Probleme von Gigabernie beschrieben.

      • Pau1 sagt:

        Was ist Exchange denn für eine Schrott Software die kein DKIM macht?

        Sollte Microsoft tatsächlich auf dem Ttipp sein, das , Antispam schlecht für das Geschäft ist?
        Immer könnte man dann ja den Kunden nicht mehr für Spam-Filter auswaiden?

        Anyway, es gibt natürlich Addons für Exchange um Nachtichten für DKim zu signieren.
        Klar das Betrügerische (klein) Unternehmen nicht wollen, dass ihr E-Mails Gerichtsfest werden. Und klar das deren "klicki-bunti Admins unfähig oder zu feige sind ein nicht teuer dazu gekauftes Tool zu installieren.
        Wenn's Probleme gibt, dann könnte es das Dkim Tool sein. Und da das derzeit noch nicht allgemein zwingend ist lässt man es natürlich weg, funktioniert doch auch ohne,…

        Traurig.

      • Pau1 sagt:

        zum Einrichten von Spf und dkim, genauer dmarc gibt's hilfreiche Webseiten.

        Das ist eine Unsinnige Argumentation.
        Das ist so wie früher wohl alle SMTP Server Default als offenes Relay nstallierten, weil das einst zum guten Ton gehörte und man great hätte:
        Die Buchhändlerin kann doch ihrem Smtp Server das relayen angewöhnen. Die Konsequenz war klar:
        Sie hatte eine gewaltige IP Rechnung und stand irgendwann auf allen RBLs.
        Mit Dkim sieht man das jetzt auch so kommen.
        kein dkim, keine Email.

      • Anonymous sagt:

        Hier scheint es sich ja um Microsoft 365 bzw. Exchange Online zu handeln und natürlich lässt sich dort DKIM einrichten.
        https://www.cloudkaffee.ch/microsoft-365/einrichten-von-spf-dkim-und-dmarc-in-exchange-online/#DKIM_Domain_Keys_Identified_Mail

  9. gigabernie sagt:

    Für alle Faule und Unwissende: auf MxToolbox.com kann man kostenlos herausfinden, wo man Probleme hat und wie man auf der DNS-Zone nacharbeiten muss.

  10. Pau1 sagt:

    interessant

    Du wunderst Dich dass Microsoft 5000 IP zum Mail versandt verwenden.
    Das müssen.
    Hotmail war ja mal ein großer Freemail Anbieter.
    Ich weiß nicht mehr wieviele Millionen User.
    Es war gigantisch für damalige Verhältnisse.
    Die E-Mails wurden von ein paar Unix Kisten verwaltet und verschickt.
    Dann hat Microsoft den Laden gekauft.
    Schnell wurde MS lächerlich gemacht, dass sie da doch Unix verwenden, bei Hotmail.
    Also hat MS versucht das auf Exchange umzustellen.
    Die Performance von Exchange kommt bei weitem nicht an die von Unix ran. Also hat MS ein paar tausend Exchange Server aufgestellt um die unixe raus zu bekommen und Hotmail nicht voll gegen die Wand zu fahren.
    Und das ist was Du siehst.
    Natürlich haben keine Übersicht mehr wo was passiert.

    Früher wurde ein Provider der absichtlich seine Outgoing IP wechselte um Spam versenden zu können, komplett in die Blacklist übernommen.
    Heute heißt es : Too big too block.

    Auch macht MS ja das SPF kaputt, wenn da zigtausende an IPs freigeschaltet werden.

    • Martin B sagt:

      das ist natürlich ein stark reduzierte Sichtweise: 70er Jahre Protokolle wie SMTP und POP3 brauchen natürlich weniger Ressourcen, daher vergleichst Du Äpfel mit Birnen. Hotmail bot eine native Outlook Anbindung, so dass Du nicht nur popeligen Mailtransport machen konntest, sondern auch Kalender, Aufgaben, gesendete Mails etc. zentral ablegen und synchronisieren konntest. Das benötigt natürlich ein paar Zeilen Programmcode mehr als old school SMTP.

      Das unterscheidet Groupware von sinnbefreiter Mailschubserei via Pegasus Mail oder Thunderbird, wo am Ende des Tages die Leute nicht mehr wissen, auf wie vielen Systemen ihre Informationen verstreut lagern und der zentrale Kalender in Wahrheit auf Google liegt, nämlich der Kalender auf dem Android Phone.

      • Pau1 sagt:

        Ganz offensichtlich hat MS die Komplexität nicht im Griff, die das Marketing fordert.
        Hey, das Email System muss auch Kalender Daten übertragen können. Das wollen unsere Kunden!

        Es ist ein völliges Unding, seine Outgoing Server in RBLs listen zu lassen und völlig naiv zu versuchen, das Problem mit unseriösen User durch IP Adressen wechsel lösen zu wollen.
        Da nützten keine noch so tollen, Marketing Feateuers nichts, wenn die Grundfunktion nicht erhalten bleibt.

        MS hat natürlich zigtausende IP Adressen als Eigentümer von MSN.
        Aber missbraucht sie.

        • Martin B sagt:

          Die User missbrauchen die MS Mailsysteme, das ist das Problem. Ob outlook.com oder schnell registrierte M365 Tenants – damit wird Missbrauch betrieben.

          Das Dilemma bei mandantenfähigen Systemen. MS hat ein paar Millionen mehr Nutzer als GMX o.ä.

          Alle großen haben ihre Probleme mit Mailfilterung, ob google, yahoo oder eben MS. Es steht jeder Firma frei, eigene Mailserver zu hosten, ist günstiger und man hat den Mailflow unter eigener Kontrolle. Die Erfahrungen sind durchweg besser.

          BTW: nicht nur im geschäftlichen Umfeld ist es unabdingbar, Mails, Kalender u.a. Informationen beisammen zu halten, dass geht nur mit servergestützten Systemen, alles andere ist Unsinn und führt zu niedriger Datenqualität und ist damit ein zweckfreies Unterfangen.

          • Cornelia sagt:

            "Alle großen haben ihre Probleme mit Mailfilterung, ob google, yahoo oder eben MS."
            Ja, das sehe ich genau so.

            "nicht nur im geschäftlichen Umfeld ist es unabdingbar, Mails, Kalender u.a. Informationen beisammen zu halten, dass geht nur mit servergestützten Systemen"
            Servergestützt ja, aber nicht zwingend alles beisammen …
            Persönlich nutze ich für E-Mails, Kalendereinträge, Kontaktverwaltung und Daten jeweils separate Software bzw Apps.

          • Detlef Bracker sagt:

            User können jedoch nur das Mail-System missbrauchen, wenn man sie das lässt! Bereits bei der Anmeldung muß Microsoft / Outlook / XYZ prüfen, wer bei "ihnen" ein Mail-Konto einrichtet! Wenn man dann auf z.B. Server oder Domain-Ebene delegiert, dann ist eben der Delegierte dafür voll verantwortlich und ja, im schlimmsten Fall müssen dann Strafen / Blockings auf breite Ebene / fristlose Kündigungen seitens Microsoft erfolgen!

            Das Internet ist keine Spielwiese!

            Durch missbräuchliche Verwendung von Mail-Systemen kann ein großer Schaden verursacht werden! Im schlimmsten Fall, wird durch eine terroristische Organisation eine Aktion verbreitet, die den Tod von tausenden Menschen verursachen kann!

            Daher verstehe ich nicht, wie ein Unternehmen wie Microsoft, so liderlich mit den Problemen umgehen kann. Heute kommt ein neues Video raus – in meinem Kanal "Supermann Granada" bei YouTube, wo ich aufzeige, daß weitere 745+81 IPs aufgeschlagen sind wegen Spam und in Spamlisten wandern, wegen Spam mit teilweisem Porno-Versand und Microsoft könnte das ganz leicht abfiltern, tut es aber nicht!

  11. Anonymous sagt:

    Kann bestätigen dass das Thema grade wieder aktuell ist, bei uns gehen dazu verstärkt Tickets von Kunden ein deren Mails wir wegen Blacklisting über Spamcop und/oder grauenhafter Reputation auf HAT-Ebene rejecten. Hängt das immer noch mit dem ähnlichen Thema von Januar zusammen?

  12. IT-SERVICE MAX ARTMEIER sagt:

    Hallo Zusammen,

    sorry, falls das schon erwähnt wurde, aber diese Meldung wird schon lange im Azure-Admin-Portal ausgegeben:

    Some users' outbound Exchange Online email messages may be marked as spam and not delivered
    EX719348, Zuletzt aktualisiert: 8. März 2024, 21:13 MEZ
    Voraussichtliche Startzeit: 26. Feb. 2024, 05:26 MEZ

    vg Max Artmeier
    M365 Consulting

  13. Lennart K sagt:

    Moin Zusammen,
    wir haben auch wieder, wie im Januar, die Probleme mit Microsoft 365.

    Aktuellster Fall ist eine Blockade von Microsoft 365 Servern bei NixSpam

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.