Exchange on Prem - Mailversand an M365

[Hunduster]

Hallo zusammen,

wir haben aktuell leider bei einem Kunden das Problem, dass unsere E-Mails an den Kunden aufgrund einer fehlgeschlagenen SPF Prüfung im SPAM landen.

Wir selber sind, abgesehen von MS Teams, komplett in Premise unterwegs. Unser Exchange Server steht also auch bei uns.
Alle eingehenden und ausgehenden Mails laufen über unsere Firewall. Eingehende MX Einträge zeigen ausschließlich auf unsere IP Adressen, entsprechend sind unsere SPF Einträge auch nur auf diese IP Adressen ausgewiesen.

Besagter Kunde konnte nun anhand der Routing Protokolle aus machen, dass unsere Mails bei MS über 9 Hops geleitet werden. Ab dem dritten Hop fungiert MS als Relay für unsere Domain, wodurch am Ende die SPF Prüfung fehl schlägt.

Der Kunde bittet nun darum unseren SPF Eintrag um die Range von Microsoft zu erweitern, da er der Meinung ist, dass durch unseren MS Teams Tenant (selbe Domain) die Mails von MS automatisch intern über deren Relays laufen und ich meinen SPF erweitern muss.

Der Witz ist nur, dass wir auch zig andere Kunden haben, welche M365 nutzen und hier überhaupt keine Probleme haben.

Leider habe ich hier in meinem Bekanntenkreis keine saubere Aussage zu bekommen, da die einen sagen es macht Sinn, die anderen sagen es macht keinen Sinn.

[Gast Interrupt]

Hallo,

vor 1 Stunde schrieb Hunduster:

Der Kunde bittet nun darum unseren SPF Eintrag um die Range von Microsoft zu erweitern, da er der Meinung ist, dass durch unseren MS Teams Tenant (selbe Domain) die Mails von MS automatisch intern über deren Relays laufen und ich meinen SPF erweitern muss.

Das lässt sich doch einfach nachprüfen, ob tatsächlich manche Mails über einen Relayhost verschickt werden. Schau doch einfach mal im ECP nach, ob es da einen entsprechenden Konnektor gibt.

Ich kenne mich zwar mit MS Teams nicht aus aber das wäre äußerst dubios wenn MS Teams automatisch beim Exchangen einen Mailrelay einrichtet.

[Maniska]

Schon mal MS mit ins Boot geholt?

Die müssten ja sagen können wie dort in der Welt intern der Hase die Mail läuft. Gerade wenn es nur einen Kunden betrifft, scheint es ja erstmal kein generelles Problem auf eurer Seite zu sein?

Wenn es bei "allen anderen" klappt, warum solltet ihr euren SPF aufbohren nur weil der Kunde der Meinung ist dass es daran liegt?

Ich bin eher im Lager "macht keinen Sinn", weil:

• es nur einen Kunden bei M365 betrifft und nicht alle
• das "Austauschen" des ursprünglichen, externen Absenders innerhalb des MS-Universums doch recht dubios wäre.
  • Wenn MS das per Default machen würde, müssten noch viel mehr "O365 ja, Exchange on Prem nein" Kunden betroffen sein, dann würde sich dazu auch einiges im Internet finden

[Hunduster]

Hallo zusammen,

vielen Dank für die prompten Antworten.

Ich befinde mich passenderweise im Urlaub und sitz erst jetzt wieder am Rechner. Parallel hatte ich auch noch zwei Dienstleister aus der M365 Welt mit ins Boot geholt, die mir die Frage auch nicht zu 100% beantworten konnten und eher dazu tendierten, den SPF Record von MS doch einfach zu schalten. Nur das ist ja genau das, was wir nicht wollen.

Ich selber habe MS noch nicht mit ins Boot geholt, der Kunde aber wohl schon. Wobei der Hinweis von MS hier auf das klassische SPF ging und keinen Bezug auf unsere Konfiguration hatte.

 

vor 7 Stunden schrieb Maniska:

Ich bin eher im Lager "macht keinen Sinn", weil:

• es nur einen Kunden bei M365 betrifft und nicht alle
• das "Austauschen" des ursprünglichen, externen Absenders innerhalb des MS-Universums doch recht dubios wäre.
  • Wenn MS das per Default machen würde, müssten noch viel mehr "O365 ja, Exchange on Prem nein" Kunden betroffen sein, dann würde sich dazu auch einiges im Internet finden

Da bin ich eben auch bei dir. Das Problem würde ja generell auch andere Kommunikationspartner von uns betreffen und am Ende müssten ja zig Serveranbieter MS im SPF autorisieren, weil die sich als Relay ausgeben.

Ich warte hier nun noch auf die Antwort von einem DL und bin gespannt. Halte Euch auf dem Laufenden.

[Maniska]

vor 47 Minuten schrieb Hunduster:

Parallel hatte ich auch noch zwei Dienstleister aus der M365 Welt mit ins Boot geholt, die mir die Frage auch nicht zu 100% beantworten konnten und eher dazu tendierten, den SPF Record von MS doch einfach zu schalten.

Alternativ könnte man auch laut überlegen sich aus der M365 Welt zurückzuziehen. "Ach der Mist passiert wegen Teams.. Naja, so dringend brauchen wir das nicht".

Nur leider weiß jeder, dass das ein hohler Bluff ist und man spätestens wenn MS den Exchange nicht mehr (bezahlbar) für OnPrem anbietet doch wieder um die Ecke kommt (kommen muss).

Ich fände es aber auf jeden Fall gruselig wenn MS den Mail-Header so vergewaltigt dass der ursprüngliche Absender nicht mehr ersichtlich ist, und damit durchkommt. Aber das ist nur meine Meinung.

[Thanks-and-Goodbye]

vor 3 Minuten schrieb Maniska:

Alternativ könnte man auch laut überlegen sich aus der M365 Welt zurückzuziehen. "Ach der Mist passiert wegen Teams.. Naja, so dringend brauchen wir das nicht".

Hilft aber auch nicht... auch mit einem On-Prem-Exchange ohne Teams kann man massive Probleme haben, seine Mails in die EXO-Welt abzuliefern..

[Hunduster]

vor 1 Minute schrieb Maniska:

Alternativ könnte man auch laut überlegen sich aus der M365 Welt zurückzuziehen. "Ach der Mist passiert wegen Teams.. Naja, so dringend brauchen wir das nicht".

Nur leider weiß jeder, dass das ein hohler Bluff ist und man spätestens wenn MS den Exchange nicht mehr (bezahlbar) für OnPrem anbietet doch wieder um die Ecke kommt (kommen muss).

Ich fände es aber auf jeden Fall gruselig wenn MS den Mail-Header so vergewaltigt dass der ursprüngliche Absender nicht mehr ersichtlich ist, und damit durchkommt. Aber das ist nur meine Meinung.

...Teams ist leider alternativlos. Habe mich auch lange dagegen gewehrt...

Dieser Cloud-Zwang geht mir halt auf die Nüsse. Frei nach Tolkien: „Ein Dienst sie zu finden, ins Dunkel zu treiben und ewig zu binden.“

Anbei mal das Log des Kunden:

Received
Hop: 1
From: mail.das-sind-wir.de

Hop: 2
From: mail.das-sind-wir.de (unser.schoene.ip.adresse)
By: AM5EUR02FT020.mail.protection.outlook.com (10.152.8.125)
With: Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)
Id: 15.20.4909.7
Via: Frontend Transport
Date: 1/21/2022 12:40:48 PM
Delay: 27379420 minutes 48 seconds
Percent: 99.99999908690546

Hop: 3
From: AM5EUR02FT020.eop-EUR02.prod.protection.outlook.com (2603:10a6:20b:31f:cafe::db)
By: AS8P189CA0016.outlook.office365.com (2603:10a6:20b:31f::7)
With: Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)
Id: 15.20.4909.12
Via: Frontend Transport
Date: 1/21/2022 12:40:49 PM
Delay: 1 second
Percent: 6.087296965202508e-8

Hop: 4
From: AS8P189CA0016.EURP189.PROD.OUTLOOK.COM (2603:10a6:20b:31f::7)
By: AS1PR01MB9081.eurprd01.prod.exchangelabs.com (2603:10a6:20b:4db::14)
With: Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)
Id: 15.20.4909.8
Date: 1/21/2022 12:40:49 PM
Delay: 0 seconds

Hop: 5
From: EUR05-AM6-obe.outbound.protection.outlook.com (40.107.22.55)
By: VE1EUR02FT044.mail.protection.outlook.com (10.152.13.51)
With: Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)
Id: 15.20.4909.7
Via: Frontend Transport
Date: 1/21/2022 12:40:54 PM
Delay: 5 seconds
Percent: 3.043648482601254e-7

Hop: 6
From: VE1EUR02FT044.eop-EUR02.prod.protection.outlook.com (2603:10a6:208:69:cafe::cf)
By: AM0PR03CA0085.outlook.office365.com (2603:10a6:208:69::26)
With: Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)
Id: 15.20.4909.12
Via: Frontend Transport
Date: 1/21/2022 12:40:54 PM
Delay: 0 seconds

Hop: 7
From: AM0PR03CA0085.eurprd03.prod.outlook.com (2603:10a6:208:69::26)
By: AM7PR03MB6625.eurprd03.prod.outlook.com (2603:10a6:20b:1b7::16)
With: Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)
Id: 15.20.4909.11
Date: 1/21/2022 12:40:54 PM
Delay: 0 seconds

Hop: 8
From: EUR05-DB8-obe.outbound.protection.outlook.com (104.47.17.109)
By: VE1EUR02FT042.mail.protection.outlook.com (10.152.13.70)
With: Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)
Id: 15.20.4909.7
Via: Frontend Transport
Date: 1/21/2022 12:41:03 PM
Delay: 9 seconds
Percent: 5.478567268682257e-7

Hop: 9
From: VE1EUR02FT042.eop-EUR02.prod.protection.outlook.com (2a01:111:e400:7e1e::45)
By: VE1EUR02HT117.eop-EUR02.prod.protection.outlook.com (2a01:111:e400:7e1e::298)
With: Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)
Id: 15.20.4909.7
Date: 1/21/2022 12:41:03 PM
Delay: 0 seconds

ForefrontAntiSpamReport
Country/Region: NL
Language: en
Spam Confidence Level: 9
Spam Filtering Verdict: SPM
IP Filter Verdict: NLI
HELO/EHLO String: EUR05-AM6-obe.outbound.protection.outlook.com
PTR Record: mail-am6eur05on2055.outbound.protection.outlook.com
Connecting IP Address: 40.107.22.55
Protection Policy Category: HSPM
Spam rules: (4636009)(2616005)(19627235002)(108616005)(36756003)(166002)(66574015)(6666004)(6916009)(966005)(26005)(15974865002)(4001150100001)(7696005)(15650500001)(24736004)(83380400001)(33964004)(7636003)(336012)(54906003)(4326008)(30864003)(8676002)(107886003)(118246002)(45080400002)(8636004)(5660300002)(1096003)(6486002)(53546011)(36736006)(81226003)(16416004)(579004)(559001)
Source header: CIP:40.107.22.55;CTRY:NL;LANG:en;SCL:9;SRV:;IPV:NLI;SFV:SPM;H:EUR05-AM6-obe.outbound.protection.outlook.com;PTR:mail-am6eur05on2055.outbound.protection.outlook.com;CAT:HSPM;SFS:(4636009)(2616005)(19627235002)(108616005)(36756003)(166002)(66574015)(6666004)(6916009)(966005)(26005)(15974865002)(4001150100001)(7696005)(15650500001)(24736004)(83380400001)(33964004)(7636003)(336012)(54906003)(4326008)(30864003)(8676002)(107886003)(118246002)(45080400002)(8636004)(5660300002)(1096003)(6486002)(53546011)(36736006)(81226003)(16416004)(579004)(559001);DIR:INB;
Unknown fields: DIR:INB;

AntiSpamReport
Bulk Complaint Level: 0
Source header: BCL:0;

Other
ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=HWLM3lQ/3z5nVP8XGYrgxvQbDVm31LULLqP9PMsjoCYoTIMowALLBYEht4CJ2gsMgkVvfpgxaYJ1MitHOcHRQcKbi06mzj5k1CnKEMzoj6TKwT7kYATTi5c/NDLziGq0Imdj2Rrtb8I5XMVDRehxdNAgZ1JAICPbAxs0warX+oaQPRoyGgVbHr717sKSqmboKti31sOFTwUQBttmSEHRhB+0GWxNSAH6dvWnaisgHv7f5YBSEB0Zt3cli8LSFBQqYLYXid5n/zyrk4+dkN/ovWkc0I3wmdvCLWnCLCpvvD3a4mlWCPM6vy+js9bJciWAPDQBF/3qsfqekzlX5ZJ1oA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=eqVREp6jx5iDAPjGXNuDkJxSI7OdfeU1w3KCkxANNJI=; b=MUolKrq4lNaexdB5Lk4LqoTMQy7YFShDhKgpQDBKcPTQQpfQv95TOAjI1ylnG78WU0AlViEnJ+4bg0KI5um0QC8uxVoCEdqhAG+IOJGpUl0tEkJulf0qcINLRrPoRnMokWi45Dswv2gNcRNq1EqBc0U2a/kVhdH0w9Ly2IOTVVxvwpXTw9HRv38VnsKhBogzwiASxXEeDoA72KCXNN4dEBh1YSelhw32noWSbwAlzrALYxR8GhmltbLOp1Lei7KWbJk0HpcwZaJX1IUQKZKVPr1tBlZ3bY6Uitffb7u5d6I78DfDwuZqxFL3XMB7us7bz2X14A3EVMHevTV9ZwjK/Q==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=fail (sender ip is 40.107.22.55) smtp.rcpttodomain=acp.de smtp.mailfrom=das-sind-wir.de; dmarc=pass (p=reject sp=reject pct=100) action=none header.from=das-sind-wir.de; dkim=fail (no key for signature) header.d=das-sind-wir.onmicrosoft.com; dkim=pass (signature was verified) header.d=das-sind-wir.de; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=das-sind-wir.de] dkim=[1,1,header.d=das-sind-wir.de] dmarc=[1,1,header.from=das-sind-wir.de])
Authentication-Results: spf=fail (sender IP is 40.107.22.55) smtp.mailfrom=das-sind-wir.de; dkim=pass (signature was verified) header.d=das-sind-wir.de;dmarc=pass action=none header.from=das-sind-wir.de;compauth=pass reason=100
Received-SPF: Fail (protection.outlook.com: domain of das-sind-wir.de does not designate 40.107.22.55 as permitted sender) receiver=protection.outlook.com; client-ip=40.107.22.55; helo=EUR05-AM6-obe.outbound.protection.outlook.com;

  

vor 2 Minuten schrieb Chief Wiggum:

Hilft aber auch nicht... auch mit einem On-Prem-Exchange ohne Teams kann man massive Probleme haben, seine Mails in die EXO-Welt abzuliefern..

Das Problem muss definitiv sauber gelöst werden. Ich will keine temporärer "Bastellösung". Es muss ja möglich sein hier zu klären, was genau MS da macht und warum. Einfach die MS IPs freizugeben ist für mich aber keine Lösung. Allen voran weil wir die Thematik bei keinem anderen unserer M365 Kommunikationspartner haben.

[Hunduster]

Hallo noch einmal,

ich hatte heute Morgen noch einmal unsere Config mit einem M365 Spezi eines externen DLs angesehen.

Er sieht den Fehler auch nicht bei uns.

Unser Exchange ist in keiner Weise mit EXO verknüpft. Alle DNS-Einträge zeigen ausnahmslos auf unsere on Prem Infrastruktur. Wir haben den Mailversand auch noch einmal mit M365 Postfächern getestet und alles geht sauber durch. Es betrifft also wirklich nur diesen einen Kunden.

Ich habe den Ball daher nun einmal zurück gespielt.

[Hunduster]

Hallo nochmal,

so, nachdem meine Recherchen alle ins Leere liefen, hatte ich einen Blog gefunden, der selbiges Problem bei einem einzigen M365 Kunden hatte. Nach 30 Stunden und Hilfe von Microsoft konnte das Problem aber wohl nie gelöst werden.

Unser Kunde hatte in der Zwischenzeit auch noch einmal ein Ticket bei Microsoft eröffnet. Man ist nun wohl an einen Techniker geraten, der das Problem ausfindig machen konnte.

Zur Erinnerung:

Wir haben einen M365 Tenant um MS Teams zu nutzen. Unser Exchange ist NICHT im Hybridmodus und wir haben auch kein Problem E-Mails an andere M365 Kunden zu senden.

Zitat

This situation occurs if both sender and recipient are in the same EOP forest and from the header you can see sender has HE1EUR02FT095 and recipient has VE1EUR02FT072 so both tenants have EOP forest EUR02.

Wir sind mit besagtem Kunden zufällig im selben EOP Forest wodurch dieser Fehler wohl durch das Relay untereinander entsteht.

[Maniska]

vor 6 Minuten schrieb Hunduster:

Unser Kunde hatte in der Zwischenzeit auch noch einmal ein Ticket bei Microsoft eröffnet. Man ist nun wohl an einen Techniker geraten, der das Problem ausfindig machen konnte.

Wir sind mit besagtem Kunden zufällig im selben EOP Forest wodurch dieser Fehler wohl durch das Relay untereinander entsteht.

Ok, damit wäre zwar das Problem identifiziert, aber eine Lösung kann/will/wird MS nicht bieten? Offensichtlich tritt das Problem ja einzig aufgrund deren interner Relaystruktur auf.

[Hunduster]

vor 20 Minuten schrieb Maniska:

Ok, damit wäre zwar das Problem identifiziert, aber eine Lösung kann/will/wird MS nicht bieten? Offensichtlich tritt das Problem ja einzig aufgrund deren interner Relaystruktur auf.

Die Lösung ist, deren SPF Record bei uns zu setzen.

Ich empfinde das auch als Nötigung aber anders geht es wohl nicht.