Ich stelle mal ein Problem hier im Blog ein, welches von einem Leser an mich herangetragen wurde. Dieser stellt seit dem 24. Juli 2023 Probleme mit Microsoft Outlook-Konten fest, weil die Mails plötzlich mit dem Fehler "Recipient address rejected" abgelehnt werden. Vielleicht kann jemand aus der Leserschaft sich einen Reim darauf machen oder ist selbst mit dem Problem konfrontiert.
Anzeige
Wenn von einem Client verschickte E-Mails beim Empfänger abgelehnt werden, stellt sich die Frage nach der Ursache. Im aktuellen Fall beschrieb Blog-Leser Andreas mir das Problem mit dem Versenden von E-Mails unter Microsoft Outlook in einer persönlichen Mail (24. Juli 2023) folgendermaßen:
Hallo Günter,
ich verfolge Deinen Blog nun schon seit längerer Zeit im Stillen und wollte mich nun aber mit einem Problem an Dich wenden bzw. nachfragen, ob Dir ähnliches bekannt ist.
Seit heute Morgen erkenne ich erhebliche Probleme beim Mailverkehr mit Microsoft Outlook Konten. Aufgetaucht ist das Problem, als E-Mail mit dem Hinweis:
Die Antwort vom Remoteserver ist:
550 5.4.1 Recipient address rejected: Access denied.
[DU6PEPF0000A7E4.eurprd02.prod.outlook.com 2023-07-24T12:04:54.399Z 08DB8A3A90A368D4]abgelehnt worden sind.
Für unsere Klienten verwalte ich mehrere Mailserver und hatte das Problem durchgehend bei allen Installationen. Im Zuge des Troubleshootings hatte ich noch alternative E-Mail-Konten ausprobiert, darunter:
- Google Mail Account
- T-Online.de
Vor wenigen Minuten wurde ich das dritte Mal mit dem Problem konfrontiert. In der Summe ist das Problem bei Firmen wie Siemens, Nagel-Group.com und ViveLaCar GmbH aufgetreten.
Liegen Dir zufällig Informationen von anderen Kollegen hierzu vor?
Mir liegt bisher nichts dergleichen an Berichten vor. Ich hatte bei ihm nachgefragt, ob der Artikel 5 Ways to Fix "Recipient Address Rejected Access Denied" Error vielleicht hilft. Dazu kamen folgende Antworten.
Den Artikel: "5 Ways to Fix "Recipient Address Rejected Access Denied" Error" hatte ich ebenfalls recherchiert und soweit möglich als Fehlerquelle ausgeschlossen. Nachdem ich schon seit Tagen immer wieder Probleme beobachte, habe ich für mich einen ersten "Troubleshooting Step" entwickelt um schnell und einfache "hausgemachte Probleme" entlarven zu können.
Ich habe für solche Fälle einen E-Mail-Account bei t-online.de, gmail.com und outlook.com. Sobald Probleme auftreten, schreibe ich die ursprünglich abgelehnte E-Mail auch von diesen Accounts und zwar direkt über den Webmailer um so eventuelle Blocks von meinem VPN ausschließen zu können.
In meinem aktuellen Fall habe ich somit direkt von t-online.de und auch von gmail.com an die besagten E-Mail-Adressen geschrieben. In beiden Fällen erhielt auch hier postwendend die Ablehnung.
Womit ich zumindest auch den zweiten Artikel der "angreifbaren Exchange Server" ausschließen würde. Auf der einen Seite laufen meine eigenen Mailserver ausschließlich über Mailcow, aber selbst wenn ich irgendwo (weil wir alle nur Menschen sind) einen Fehler im System hätte, müssten zumindest meiner Meinung nach die Mails des T-Online.de Webmailers und des GMAIL-Webmailers ankommen.
Und in einer dritten Mail schrieb er dann noch:
ich habe es gerade noch einmal zumindest mit dem Anbieter "vivelacar.de" probiert und sende Dir die Fehlermeldung als Screenshot.
Wie geschildert, die Mail wurde direkt mit bzw. aus dem Webmailer von GMAIL herausgeschickt.
Meine E-Mail-Adresse als Absender habe ich ebenfalls prüfen lassen.
Es liegt kein Blacklisting vor (was allerdings auch unwahrscheinlich ist, weil das Ergebnis beim versenden über meine eigenen Mailserver oder T-Online.de das selbe ist).
Anzeige
Die Fragen, die sich stellen: Hat jemand etwas ähnliches beobachtet oder gibt es eine Erklärung für obiges Verhalten?
Ergänzung: Erste Rückmeldung eines Lesers über Facebook lautete: Eine Erklärung habe ich nicht, allerdings hatte eine Kollegin gestern das Problem. Ich hab ihr geraten es einfach später nochmal zu probieren. Rückmeldung soll erst am Donnerstag (27. Juli) kommen. Ein Leser wies mich noch darauf hin, dass es mit Code Two zusammen hängen könne – was ich aber im Artikel CodeTwo: Auto-Reply-Mails von Microsoft 365-Tenants werden von Microsoft irrtümlich als Spam klassifiziert angesprochen habe.
Anzeige
Das Problem bei mehreren meiner Kunden war der SPF Eintrag, welcher bei den jeweiligen Hostern fehlen oder falsch sind.
https://mxtoolbox.com/spf.aspx
einfach die Domäne eingeben.
Die nicht erreichbaren Firmen telefonisch kontaktieren und darauf hinweisen.
Liebe Grüße aus Österreich,
Joachim
Das betrifft meistens Mails an gmail, da Google mittlerweile bei negativen SPF Check rigourus die Mail ablehnt.
Wenn ich aber mal in unseren Mailempfang gucke wer alles kein korrekt gepflegten SPF Eintrag hat frag ich mich wie man so überhaupt noch G-Mail benutzen kann, eine Bestätigungsmail einer Stadt zu erhalten wird mit SPF Check zum Glückspiel.
bzgl. SPF >> Das mit Google und anderen Providern stimmt. Wobei das interessante war, dass nicht jede Mail abgelehnt wurde. Vor allem bei Google war das eher so sporadisch, Nach SPF setzen ging alles einwandfrei. Die Sache ist aber mind. schon 8 oder 10 Wochen her.
Ergänzung:
Natülich checked gmail nicht nur den SPF dessen der die email sendet, sondern auch den SPF an den gmail emails schicken soll.
Das ist wohl weniger klar, weil SPF ja eigentlich nur für den Absender einer eMail gedacht war.
Das ergibt aber durchaus Sinn:
– Wenn ich per gmail jemanden anschreibe, dann hat der keine Chance mir zu antworten, wenn dessen Admin die Sache mit SPF verschlafen hat, weil gmail ja seine Antwort an mich ablehnen würde.
Und wenn er aus Angst niemals diese kryptischen Fehlermeldungen aufmacht, von einem Mailer Demon,…
Ich würde aber als Anfrager sagen: Wenn der nicht antwortet, dann will der nicht. Dadurch das gmail mir aber jetzt durch den SPF schon vor dem absenden bescheid sagt, weiß ich, das ich besser nicht meinen gmail account nehmen sollte oder das Telefon. Blöd natürlich wenn der andere mit einer anderen Domain antworten möchte, die dann doch keinen SPF hat.
Dann steht er doch mit einer Fehlermelung seines Systems da.
Warum sollte gmail ausserdem den SPF dessen prüfen den ich anschreibe möchte?
– Wenn das anschriebene Mail system kaputt ist und allen Müll erstmal annimmet und hinterher feststellt, dass es den User nicht gibt oder sein Postfach voll ist, und eine Bounce mail erzeugt (das soll es auch 2023 immer noch geben! Z.B. wenn man eMails durch Baracuda o.ae. spam/viren filtern läßt um seinen Exchange zu "schonen" und die amerikanischen Schlangenölverkäufer zu fördern.).
Diese Bouncemail würde mangels SPF von gmail abgelehnt werden, besonders wenn man kein DKIM/DMARC macht und der Absender nicht leer ist, was leider auch oft zu sehen ist.
(Aka: "noreply@domain.tld" anstatt "")
Für den Absender bei gmail wäre die eMail aber "zugestellt", da eMails per definition nicht verloren gehen können, wenn alle System richtig konfiguriert sind…
Somit wirkt das setzten von SPF wahre Wunder.
Natürlich kann ein hohler Admin sein Logfile durchsuchen und feststellen, das er sowieso keine Kunden-Emails mit einer Gmail adresse hat und sich weiterhin den SPF sparen… soll es geben.
Also:
Wer seine User liebt und sein Handwerk versteht:
Die paar Euro investieren und den SPF eintragen und DKIM
nebst DMARC aktivieren (lassen). Tut nicht weh, und ist für alle besser, wenn man sich nicht als totalen Egoist im Netz zeigt.
HTH
SPF korrigieren oder Eintragen hat bei allen unseren Kunden geholfen!
Ja, sowas hatten/haben wir auch sporadisch immer mal wieder und gehen dann genauso vor wie Joachim es beschrieben hat.
LG!
Mit all den letzten Blogmeldungen zum Thema Microsoft 365 im Hinterkopf tippe ich auf temporäre Fehlkonfigurationen in deren Cloud. Es sieht ja so aus, als ob dort am Mailsystem gearbeitet wird.
Für vivelacar und siemens werden übrigens die selben acht IPs als mx-e ermittelt. Vielleicht haben ein paar von denen temporär keinen korrekten Zugriff auf das AAD und weisen daher ankommende E-Mails ab?
Hat der Fragesteller die IPs der abweisenden Server mal genauer betrachtet? Sind alle möglichen betroffen oder ist es nur ein Teil, evtl. nur die "68"er oder nur die "73"er?
das problem dürften die Empfänger Tenants sein. Cloud halt.
(vivelacar.de ist nur ein beliebiges Beispiel)
nslookup vivelacar-de.mail.protection.outlook.com
Server: dns9.quad9.net
Address: 9.9.9.9
Name: vivelacar-de.mail.protection.outlook.com
addresses: 52.101.68.5
52.101.73.1
52.101.73.4
52.101.68.21
52.101.73.2
52.101.73.6
52.101.68.3
52.101.68.0
Diese Werte oszillieren.
Naja, poor man's load balancer oder wie?
Aber natürlich erhöht das die Chance dass einer
der MX falsch konfiguriert ist.
Auch kann just dessen IP Adresse länger im cache stecken.
Aber das kann nicht das Problem sein, weil das ja viele Domains betrift,
die alle spf.protection.outlook.com in ihrem SPF includen (müssen).
Es sieht nach einem DNS problem aus
BTW:
Im Moment bekomme ich stabil nur einen für die Domain spf.protection.outlook.com zuständigen DNS angezeigt,
ns1-gtm.glbdns.o365filtering.com
Wieso wurde
ns2-38.azure-dns.net
als dns für spf.protection.outlook.com verwendet
der keinen SPF record dafür hat?
nslookup -type=all spf.protection.outlook.com ns2-38.azure-dns.net
Server: UnKnown
Address: 150.171.16.38
protection.outlook.com nameserver = ns1-gtm.glbdns.o365filtering.com
protection.outlook.com nameserver = ns2-gtm.glbdns.o365filtering.com
Rein vom der Fehlermeldung her sollte das doch eigentlich heißen, dass der Mailserver keine Mails für die Empfängerdomain annimmt.
Wenn die Adresse wirklich existiert und bei Microsoft Exchange online angesprochen wird, würde ich das als Problem der Empfängerseite, vielleicht verursacht durch das Directory-Based Edge Blocking (DBEB) einstufen.
Vielleicht wackelt da wieder was bei Microsoft oder in der speziellen (Hybrid-) Umgebung.
Ehrlich gesagt, warte ich bei solchen Problemen mit Empfängern bei Microsoft meist nur noch ab. Da ist mir jeder Aufwand zu viel, Probleme dort zu häufig eratisch.
*schulternzuck*
5.7.1: Das passiert auch z.B. bei unzulässigen Attachments – wenn die Fehlermeldung nicht "aufgehübscht" wurde sieht das halt so aus.
Attachments am einfachsten umbenennen in "*.txt" und dem Empfänger sagen, dass er das zurück umbenennen muss. Oder in ein verschlüsseltes(!) ZIP, aber so, dass auch die Auflistung des Inhalts schon das Passwort erfordert.
Peter
Bei solchen Tipps sollte sich keiner wundern warum sich alle Ransomware einfangen.
Ein Benutzer der anfängt die Endungen von Anhängen händisch zu ändern um die Filter zu umgehen würde ich auf Lebzeiten in ein Offlinebüro verbannen.
Und ZIP Dateien gehören jetzt schon seit Jahren in die Quarantäne umgeleitet bis Herkunft und Inhalt als nicht Gefährlich eingestuft sind ;).
| […] bis Herkunft und Inhalt als nicht Gefährlich eingestuft sind […]
Soweit die Theorie. Nur
a) Wer kann die Herkunft (den Absender) in der Regel besser einschätzen als der Empfänger? Die IT dürfte das meistens nicht sein.
b) Ab wann ist ein Attachment denn definitiv als sicher einzustufen?
Aus Erfahrung kann ich berichten, dass Nutzer bei installierter Sicherheitssoftware sich dazu ermutigt fühlen, auch mal was zu riskieren, es kann ja nicht viel passieren, die Sicherheitssoftware wird das schon erkennen und verhindern. Der Auslöser unseres damaligen Befalls, hier die Software, wurde übrigens erst knappe 24 Stunden später auf Virustotal von den ersten vier Scannern als Schädling erkannt. Nach weiteren 24 Stunden dannn von knapp der Hälfte. Blöderweise war unserer immer noch nicht dabei, die haben ärgerlicherweise drei Tage gebraucht. Und das war keine Free- sondern eine bezahlte Pro-Version!
Wenn Du einer der ersten bist, und vielleicht sogar einer von ganz wenigen, kann das ziemlich lange dauern, bis Du sicher sein kannst. Und vielleicht liegst Du doch falsch. Und Deine Sicherheitssoftware gleich noch mit.
Der größte Unsicherheitsfaktor sitzt vor dem PC. Den Usern muss man beibringen, wie man mit E-Mails umzugehen hat. Trotz installierter Sicherheitssoftware! Bei Unklarheiten können Rückfragen an den Absender oder an die IT weiterhelfen. Wird ein 0-Day ausgenutzt und der Empfang und das bloße Anzeigen der E-Mail reicht, bist Du ohnehin am (_|_).
[a) Wer kann die Herkunft (den Absender) in der Regel besser einschätzen als der Empfänger? Die IT dürfte das meistens nicht sein.]
Und jetzt die Praxis.
Die IT kann das definitiv besser, der Anwender liest nur den Absendername und wenn man Glück hat guckt er noch die dahinter liegende Adresse Sinn ergibt. Die IT guckt in den Header, guckt wohin Links führen, vergleicht den technischen Absender mit dem angegeben, die IT kennt den Aufbau der üblichen verdächtigen Mails, kann viel besser einschätzen ob ein Anhang potenziell gefährlich ist, auch ohne Virenscanner und Co.
E-Mail ist für 99% der Anwender nur ein Arbeitsinstrument, es bestehen gar keine Ambitionen sich tiefer damit auseinanderzusetzen, es soll einfach nur funktionieren.
Solche Anhänge grundsätzlich killen ohne wenn und aber.
Fehlermeldung war: 550 5.4.1 Recipient address rejected: Access denied.
Nicht 5.7.1, das ist was anderes.
Aber, die Aufklärung vom Betroffenen ist ja nun unten zu finden.
Wie immer bei Microsoft-Empfängern: Einfach warten, bis die wieder empfangen können.
Hoecker, Sie sind raus! Was sagt eigentliche die IT Deines Arbeitgebers zu solchem Verhalten von Dir an Deinem Arbeitsplatz?
Du wirst lachen, aber der vom Vorredner vorgeschlagene Weg war wenigstens eine zeitlang für mich die einzige Möglichkeit, im Rahmen eines geschlossenen Support-Vertrages(!) einem Sachbearbeiter in einer Behörde(!) per E-Mail auf seine Bitten und Anfragen hin Powershell-Scripte bzw. Applikationen nachträglich anzupassen und diese ihm zukommen zu lassen. Diese Möglichkeit (Fehlkonfiguration) wurde dann irgendwann vom Dienstleister entdeckt und mehr schlecht als recht gekappt.
Bei Behörden und deren Dienstleistern greift man sich so manches Mal an den Kopf. Es kostet halt kein *echtes* Geld.
ja, Google hat seit einigen Tagen / Wochen die Schraube angezogen…Domains ohne SPF Eintrag im DNS haben harte Zeiten Emails an @google.com zu schicken.
SPF Eintrag erstellen und gut ist (wäre ja sowieso schon längst an der Zeit gewesen, ne).
https://de.wikipedia.org/wiki/Sender_Policy_Framework
Schon ein paar Jahre, ja. Wobei der SPF nun wirklich genauso viel Sicherheit gibt wie in https am Anfang eines URL. Aber lasst ruhig weiter Google den Diktator machen, wenn es darum geht, was im Netz Standrad zu werden hat und was nicht. Bei mir im privaten Bereich haben Nutzer einer Mailadresse mit google im Namen halt Pech. Sollen die sich gefälligst einen seriösen Anbieter suchen.
@M.D.
Das was Du da beschreibst nennt sich "Risiko Kompensation".
Radfahrer mit Helm fahren riskanter und auch Autofahrer riskieren mehr. Der Mercedes Chef Sicherheitsingenieur hätte am liebsten eine Sperrspitze in die Mitte des Lenkrades gebaut, weil das mehr Unfälle verhindert hätte als eine Knautschzone…
Und bei Dir halt:
Wir haben einen guten Viren Scanner, was soll da schon passieren. Und wenn habe ich ja keine Verantwortung dafür…
550 5.4.1 Recipient address rejected: Access denied.
Da lese ich, das der Empfänger ein Problem hat, nicht der Absender.
Das wird dadurch bestätigt, daß emails anderer Absender an diesen Empfänger auch abgewiesen werden.
ich gehe davon aus, dass die Versuche als Plain Text emails ohne Anhänger und Einbindungen z.B. via telnet erfolgt sind.
(Das S in SMTP steht ja für "simple", d.h. man kann das manuell machen).
Die Ursache kann einfach sein, das dem Empfänger gekündigt wurde und keine Weiterleitung eingerichtet ist (Datenschutz).
Ich würde mal eine Frage an "postmaster@" oder "abuse@" der entsprechendenden Domains schicken.
Diese Adressen müssen (!) von einem Menschen gelesen werden und dürfen auf keinen Fall irgendwie gefiltert werden.
Keine Sorge: Abuse wird nur von den blödesten der blöden Spanner bespannt. Nur leider habe ich die Erfahrung gemacht, das diese Adressen, die es lt. RFC geben muss nicht eingerichtet werden und oftmals blöderweise über den denselben evtl. kaputten Mailfilter laufen…
Dann hilft nur noch Faxen an die Nummer bei der Domain Registrierung oder im Impressum.
Gleiches Problem bei mehrere Kunden gehabt. DMARC und DKIM Implementierung zusätzlich zum SPF im Online Exchange konfiguriert. Und seitdem Problem nicht mehr aufgetaucht.
"In der Summe ist das Problem bei Firmen wie Siemens, Nagel-Group.com und ViveLaCar GmbH aufgetreten."
Verstehe ich Recht:
All diese Domains und mehr haben alle E-Mails mit 550 5.4.1 rejected? Auch die an Postmaster/abuse? Auch wenn per Web interface des Probiders über das Handy gemailt wurde?
Liegt das evtl. an der Urlaubszeit und alle Postfächer sind voll?
Em, bei unterschiedlichen Empfängern und unterschieden Absendern (T-Online etc.)?
Und nur ein Teilnehmer meldet das Problem?
Funktioniert denn ein CC: an eine eigene Adresse?
vivelacar.de.
…
MX 100 vivelacar-de.mail.protection.outlook.com.
SPF The DNS server has no records associated with this type.
…
Das da kein SPF eingetragen ist sollte keine Rolle spielen,
da ja der Empfang geblockt ist.
Es sei denn Google blockiert jetzt alles was keinen SPF hat, weil ja im Fehler Fall kein Bounce angenommen würde.
Aber die Meldung kommt vom Remote Server.
Vielen Dank für den Input. Als ursprünglicher Fragesteller kann ich mitteilen, dass sich in meinem Fall die Probleme zwar nicht (für mich) nachvollziehbar aufarbeiten ließen, nach einiger Zeit klappte die E-Mailzustellung dann doch. In etwa wie ein Vorredner von Facebook schilderte (einfach mal 24 Stunden warten).
Alles in allem war es rückblickend wahrscheinlich ein seltsamer Zufall. In 2 Fällen gab es keine erkennbaren Probleme (zumindest lt. kurzer/netter Rückinfo der zuständigen Mitarbeiter) und in einem Fall soll es sich um eine Konfiguration der Domain-Alias gehandelt haben.
Wie auch immer. E-Mails kommen wieder an…
OT aber auch ein Problem mit Outlook: abgespeicherte Mails im MSG-Format lassen sich nur einmal öffnen. Schliesst man sie wieder und versucht sie danach wieder zu öffnen kommt die Meldung, dass die Datei "möglicherweise bereits geöffnet ist oder keine Berechtigung besteht diese zu öffnen". Erst wenn Outlook neu gestartet wurde, kann die Datei wieder geöffnet werden – aber auch wieder nur einmal.
Recherche ergab, dass dieses Problem auch 2016/2017 schon mal aufgetreten ist und durch ein späteres Update beseitigt wurde. Und im Forum von Windows-Info gibt es ein paar aktuelle Meldungen des gleichen Problems (aber leider keine Lösung).
Das Problem betrifft bei uns alle Rechner (Version 2306 Build 16529.20182). Verschont wird nur mein Rechner: der läuft mit Version 2308 Build 16717.20000 aus dem Betakanal.
Quelle: MS365 Portal:
Users may be unable to open email messages saved as a file more than once in the Outlook desktop client
EX648854, Last updated: July 24, 2023 at 10:03 PM GMT+2
Estimated start time: July 17, 2023 at 8:53 PM GMT+2
Danke für die Info. Hab so die Ursache gefunden und konnte 'nen Workaround anwenden: Teams-Add-In deaktiviert und jetzt gehts wieder.
Was war denn die Ursache?
Und wieso hilft das Add-in nur als Würgarround?
Verzeih daß ich frage.
Ich hatte gerade den Effekt, das fur
spf.protection.outlook.com
von einem DNS keine Antwort für dessen SPF kam.
Dessen eigentlich sehr umfangreicherb spf wird default bei z.B.
vivalscar.de eingebunden und erlaubt vielen Millionen IP in der MS Cloud E-Mails für diese Domain zu verschicken.
Ein paar 10 Sekunden später kam aber eine richtige Antwort, von einem anderen DNS.
Also was habe ich gemacht:
erstmal bei
https://www.nslookup.io/domains/vivelacar.de/dns-records/
nachgeschaut ergibt, das dort der SPF einen include von
spf.protection.outlook.com
hat
den Link per Doppelklick geöffnet.
gibt manchmal
https://www.nslookup.io/domains/spf.protection.outlook.com/email/spf/
SPF record for spf.protection.outlook.com
An authoritative DNS server (ns2-38.azure-dns.net.) responded with these DNS records when we queried it for the domain spf.protection.outlook.com.
spf.protection.outlook.com does not have any SPF records.
Wie bitte?
DievDomain, die nur für den SPF zuständig ist, hat keinen SPF record?
Etwas später kommt von Einem Anderen DNS für richtige Antwort., aber von einem anderen DNS.
An authoritative DNS server (ns1-gtm.glbdns.o365filtering.com.) responded with these DNS records when we queried it for the domain spf.protection.outlook.com.
This record is valid for 10m.
Pass if the email sender's IP is between 40.92.0.0 and 40.93.255.255.
ip4:40.92.0.0/15
Or else, pass if the email sender's IP is between 40.107.0.0 and 40.107.255.255.
ip4:40.107.0.0/16
Or else, pass if the email sender's IP is between 52.100.0.0 and 52.103.255.255.
ip4:52.100.0.0/14
Or else, pass if the email sender's IP is between 104.47.0.0 and 104.47.127.255.
ip4:104.47.0.0/17
Or else, pass if the email sender's IP is between 2a01:111:f400:: and 2a01:111:f400:ffff:ffff:ffff:ffff:ffff.
ip6:2a01:111:f400::/48
Or else, pass if the email sender's IP is between 2a01:111:f403:: and 2a01:111:f403:7fff:ffff:ffff:ffff:ffff.
ip6:2a01:111:f403::/49
Or else, pass if the email sender's IP is between 2a01:111:f403:8000:: and 2a01:111:f403:bfff:ffff:ffff:ffff:ffff.
ip6:2a01:111:f403:8000::/50
Or else, pass if the email sender's IP is between 2a01:111:f403:c000:: and 2a01:111:f403:dfff:ffff:ffff:ffff:ffff.
ip6:2a01:111:f403:c000::/51
Or else, pass if the email sender's IP is between 2a01:111:f403:f000:: and 2a01:111:f403:ffff:ffff:ffff:ffff:ffff.
ip6:2a01:111:f403:f000::/52
Or else, mark the email as fail.
-all
Mir fehlen die Ressourcen (und die Motivation) das DNS von Microsoft zu debuggen…
Aber sollte MS tatsächlich seine DNS nicht im Griff haben, könnte das natürlich die gemeldeten Email Probleme zwanglos erklären.
Nimmt man 8.8.8.8 als DNS könnte es sein, das der falsch SPF dort sehr lange steht, weil 8.8.8.8 immer fen falschen erwischt.
Aber ich würde mich sehr sehr Wundern, wenn MS so einen Fehler machen würde, wobei der schwierig zu debuggen ist.
Ich bin mir auch nicht sicher was nslookip.io da macht
Kann auch dort ein Problem sein.
Jedenfalls wäre das eine Erklärung für
die beobachteten "Selbstheilungs Effekte"
aber die 550 5.4.1 Meldung passt nicht
Jetzt (Samstag, 1500 ) kommt wieder kein SPF via
https://www.nslookup.io/domains/spf.protection.outlook.com/email/spf/
da als DNS der im Azure net verwendet wird.
Was ist da los?
Wieso wird dieser DNS verwendet?
ich hatte eben ein Posting gemacht bezüglich instabilen DNS.
Das sehe ich aber nicht.auch keinen Hinweis aus Moderation.
Was ist das?
Jetzt ist der Text da. ich hatte neu geladen etc. Naja.
Es scheint niemand bestätigen zu können/wollen ob er auch unterschiedliche Antworten von unterschiedlichen DNS die sich für dieselbe Domain verantwortlich fühlen bekommt. Darf ja auch nicht sein.
Löst das Problem auch nicht, wenn sich herausgestellt, das MS seine DNS nicht mehr im Griff hätte, im Gegenteil. Zeigt wie hilflis abhängig man ist
Irgendwie verschwindet das Problem ja eh immer wie von selbst.
Einfach mal warten bis der Record expired ist und von Einem Anderen DNS korrekt geladen wird…
Nun ja, ich sitze nicht ständig da und schaue, ob was zu moderieren ist. Kommentare mit Links gehen in Moderation oder sogar in den Papierkorb, so dass ich dann prüfen muss, ob das wirklich absichtlich gelöscht wurde (wegen mehrfach Posts). Mache ich grundsätzlich am Desktop, um Fehler am Smartphone zu vermeiden.
ja klar und Danke dafür.
Aber früher kam da doch "wartet auf Moderation"?
Also nochmal.
wenn ich bei
https://www.nslookup.io/domains/spf.protection.outlook.com/email/spf/
nach frage
kommt da manchmal die Antwort, das es keinen SPF record gäbe. Kann ja nicht sein, denn das ist ja Grund für diese Domian.
Entweder kommt ein SPF!
An authoritative DNS server (ns1-gtm.glbdns.o365filtering.com.) responded with these DNS records when we queried it for the domain spf.protection.outlook.com.
This record is valid for 10m.
…
oder es kommt beim Klick auf den Link
SPF record for spf.protection.outlook.com
An authoritative DNS server (ns3-38.azure-dns.org.) responded with these DNS records when we queried it for the domain spf.protection.outlook.com.
spf.protection.outlook.com does not have any SPF records.
Question and response
QUESTION
dig @ns3-38.azure-dns.org. spf.protection.outlook.com. TXT
ANSWER
AUTHORITY
protection.outlook.com. 7200 NS ns2-gtm.glbdns.o365filtering.com.
protection.outlook.com. 7200 NS ns1-gtm.glbdns.o365filtering.com.
ADDITIONAL
. 0 OPT ; payload 1232, xrcode 0, version 0, flags 0
Das ist aber ein anderer DNS!
DNS server (ns1-gtm.glbdns.o365filtering.com.)
DNS server (ns3-38.azure-dns.org.)
Kann das jmd. erklären?
Könnte es sein, das MS seine DNS Struktur nicht mehr im Griff hat oder diese ihr gar nicht mehr gehört?
Das ist doch unvorstellbar.
Andererseits würde das ja die "Selbstheilung" bei Email Problemen erklären.