ExchangeOnline Phish/Spam Flag - ThirdParty via AppRegistration

[MGR 2]

Hallo Zusammen, 

Kurz zum Szenario:

Ursprünglich hatten wir einen SAP Report Server on premises, welcher via dem OnPrem Hybrid Exchange, anonym E-Mails  (exklusiv intern) versendet hatte. 
-> realisiert wurde das via dediziertem Receive Connector.

Diesen SAP Report Server haben wir jetzt mit einer SAP-Cloud Lösung (SAC) abgelöst.
Die neue SAC Lösung haben wir via AppRegistration und SecretKey an unser Azure bzw. ExchangeOnline angebunden. 

Die AppRegistration haben wir entsprechend SMTP spezifisch berechtigt und das versenden klappt auch soweit. 
Allerdings werden verschiedene E-Mails als Spam/Phishing erkannt, da hier durch die Anwendung die Displaynamen verändert werden -> ähnlich wie bei Send on Behalf.

Warum ist das so?

Für mein Verständnis ist doch der erste MTA der genutzt wird Exchange Online, da wir die ThirdPartyApp. ja via modern Authentication angebunden haben?
Weiter dachte ich, dass durch die Anbindung via AppRegistration ein SPF CheckUp nicht stattfindet -> trotzdem wird die E-Mail mir als SPF-SoftFail angezeigt (SAC ist nicht im SPF Record da ich mir das durch die AppReg sparen wollte)
Ich meine bei einer MAPI Verbindung bspw. meiner Workstation und ExOn findet doch auch keine SPF Prüfung statt, wenn ich via Outlook eine E-Mail versende, oder? und wenn doch, ist meine dynamische ip ja auch nicht im SPF...?

Wir haben bereits die Absender E-Mailadresse gehwhitelistet und auch auch schon mit dem Hersteller Support kontakt aufgenommen. 
Aber da es sich hier mal wieder um eine ThirdParty auf einer MS Platform handelt, sind deren Aussage meistens echt für die Füße....

Vom logischen Verständnis, müsste doch die AppRegistration als Backdoor fungieren, wenn ich dieser die entsprechenden API-Permissions gebe?
Wenn ich jetzt noch die Zugangsdaten (SecretKey oder CRT) der ThirdParty gebe, sollte diese entsprechend der AppPermissions auch E-Mails versenden dürfen-> bspw. auch anonym wie ursprünglich OnPrem via dediziertem Receive Connector, oder nicht?

 
Ich hoffe ich konnte die Situation einigermaßen verständlich schildern.... Freitag 20h und mein Hirn ist schon etwas strapaziert von der Woche 
ggf. editiere ich das morgen nochmal  


Vielen lieben Dank schon einmal vor etwaiges Feedback!







 

[MGR 2]

Übergangsweise habe ich mir jetzt mit einer Antispam Bypass MailFlow Rule beholfen, die die Absender Adresse sowie den Displayname als Voraussetzung abfragt.
Leider kann ich in der MailFlow-Rule keine DNS-Lookup Zone als Condition definieren, sondern nur IP Adressen/Ranges. 

Den öffentlichen SPF Record zu ergänzen halte ich nicht für zielführend, da hier ja lediglich an intern versenden werden soll und man den SPF nicht unnötig "zumüllen" sollte. 

Parallel dazu bin ich noch mit Hersteller sowie Microsoft in der Root Cause Analysis dran -> sobald ich hier was neues habe ergänze ich den Beitrag. 

Mega wäre es, wenn ich mit der AppRegistration was in den Header eingehender E-Mails schreiben könnte, um die E-Mails, welche durch die AppReg. laufen, in der MailFlow-Rule identifizieren zu können. 
Hat da jemand eine Idee?  

Beste Grüße!

[NorbertFe 2.013]

vor 6 Minuten schrieb MGR:

Parallel dazu bin ich noch mit Hersteller sowie Microsoft in der Root Cause Analysis dran -> sobald ich hier was neues habe ergänze ich den Beitrag. 

Viel Erfolg und gute Nerven. ;)

vor 7 Minuten schrieb MGR:

Mega wäre es, wenn ich mit der AppRegistration was in den Header eingehender E-Mails schreiben könnte, um die E-Mails, welche durch die AppReg. laufen, in der MailFlow-Rule identifizieren zu können. 

Nimm doch für die Appregistration einfach eine Subdomain. Dann sollten die doch eindeutig  identifizierbar sein.