Exchange Online als Nebeneingang für Mailempfang

Wenn Sie Office 365 mit Exchange Online nutzen, aber ihre Mails nicht über Exchange Online Protection leiten, weil Sie z.B. einem anderen Spamfilter vertrauen oder Zusatzfunktionen wie SMIME/PGP u.a. integrieren wollen, dann sollten Sie sicherstellen, dass die generelle Konfiguration in ihrem Tenant ihnen keine Hintertür öffnet.

Siehe dazu auch Hybrid Hintereingang und X-OriginatorOrg und Exchange DirectSend/RejectDirectSend

Ausgangssituation

Aufgefallen ist es mir bei einem Kunden, der gerade erst mit Exchange Online gestartet ist aber die meisten Empfänger immer noch "On-Premisess" sind. In dem Beispiel wurde zudem der Net at Work NoSpamProxy als AntiSpam/Antivirus-Gateway eingesetzt, welches auch noch SMIME/PGP-Verschlüsselung, Dokumentkonvertierung etc. bereit gestellt hat. In diese Umgebung wurde nun auch ein Exchange Online Tenant integriert und per Hybrid-Setup mit Hybrid Centralized Mail Transport. Eine solche Konfiguration sieht daher wie folgt aus:

Technisch bedeutet das:

  • MX Record verweist auf NoSpamProxy
  • Eingehende Mails über NoSpamProxy werden vom On-Premises Exchange Server lokal zugestellt oder über den Connector zu Office 365 geroutet.
  • Ausgehende Mails gehen über NoSpamProxy in das Internet
    Damit können die Empfänger z.B. den SPF-Record überprüfen und wir können natürlich Disclaimer, SMIME/PGP-Verschlüsselung aber auch TLS-Verifikation durchführen
  • Mail von Office 365 ins Internet gehen über den On-Premises Server
    Dazu gibt es einen Connector von Office 365 zur lokalen Umgebung, die entsprechend

Solange nun in Exchange Online keine Benutzer aktiv sind, sollte auch der Exchange Server in Office 365 ziemlich "ruhig" sein.

Ghost-Sender

Diesen Abschnitt habe ich eigentlich nur addiert, weil im Sommer 2026 die Webseite https://ghost-sender.com/ auf eine angebliche Sicherheitslücke in Exchange Online hingewiesen hat, die aus meiner Sicht keine ist. Jeder Exchange Online Server nimmt standardmäßig Mails aus dem Internet an. Das ist bei Mailservern so und Exchange Online hat je nach Lizenz auch Spamfilter und Malwarefilter beim Empfang aktiviert. Wenn eine Firma aber einen 3rd-Party-Filter davor schaltet, dann sollte Exchange Online derart konfiguriert werden, dass Mails aus dem Internet nur noch von diesem System angenommen werden und jede Zustellung dran vorbei unterbunden wird. Dann kann ich auch den Exchange-Filter abschwächen oder ganz abschalten. Wenn ein Admin natürlich den Exchange Filter abschaltet aber den Empfang weiter im Internet erlaubt, hat natürlich ein Problem. Auf der Webseite ist dankenswerterweise auch einfach beschrieben, wie Sie das selbst testen können. Sie müssen den Tenant-Namen erraten und dann einfach eine Mail aus dem Internet zustellen.

Send-MailMessage `
   -SmtpServer <tenantname>.mail.protection.outlook.com `
   -To admin@<tenantdomain> `
   -From noreply@example.com `
   -Subject "EXO Nebeneingang" `
   -Body "Testmail direkt zum tenant" `

Wenn Exchange Online ablehnt, haben Sie viel richtig gemacht. Ansonsten sollten Sie ihre Setup prüfen.

Ich kann hier keinen Fehler bei Exchange Online sehen. Nur eine Fehlkonfiguration des Exchange Online Administrator.
Lesen Sie einfach den nächsten Abschnitt, wenn Sie die technischen Hintergründe verstehen wollen.

Risiko 1: Direktzustellung

Wenn ich einen Pilot oder PoC mit Office 365 in die Produktion überführe, schaue ich vorab, wer mit dem PoC oder Testfeld vielleicht schon unbemerkt produktiv arbeitet. Für den Kunden ist es dann schon mal überraschend, dass es die ein oder andere Mail gab, die sogar von extern gekommen ist. Das überrascht um so mehr, da der Office 365 Tenant so gar nicht "öffentlich" war. Es gab keinen MX-Record der Kundendomains, die auf die Exchange Online Dienste verwiesen hätte. Selbst eine komplett und korrekt durchgeführte Hybrid-Konfiguration ist nicht automatische eine sichere Konfiguration. So passiert es dann doch beim Blick ins Messagetracking, dass sie Mails aus dem Internet finden, die sie nicht erwartet haben. Die gefundenen Mails waren "natürlich" SpamMessages und ist einfach zu erklären:

  • Ein Spammer möchte seinen Müll loswerden
    Das sind nicht nur "Massenspammer" sondern auch gerichtete Angriffe auf einen Kunden mit wenigen Mails sind hier interessant.
  • Gute Sender nutzen MX-Records, Böse suchen Alternativen
    Da die Spamfilter immer ausgereifter werden, suchen die Spammer schwächer gesicherte Türen. Schon früher habe ich beobachtet, dass Spammer bevorzugt den "Backup-MX" nutzen obwohl der primäre Mailserver ebenfalls erreichbar gewesen wäre. Die Überlegung dahinter ist, dass der Backup-MX vielleicht beim Provider steht und einen schlechteren oder gar keinen Spamfilter hat. Mails über diesen Service wird eine Firma aber eher annehmen, denn bei einer Ablehnung würde der Backup-MX die Unzustellbarkeiten (Exchange und NDRs) versenden und zwangsläufig zum NDR-Backscatter werden.
  • Office 365 Hintertür
    Exchange Online Protection ist durchaus ein leistungsfähiger Spamschutz aber auch nicht 100% zuverlässig. Ich kann mir das nur so erklären, dass die Spammer nun auch diesen Weg versuchen, um ihren Schadcode zuzustellen.

Und hier kommt die Domain "<tenantname>.onmicrosoft.com" in Bild, die jeder Tenant hat und Microsoft addiert diese Domain auch an die Benutzer als zusätzliche Domäne. Mit einer Hybrid-Konfiguration kommt sogar noch die "<tenantname>.mail.onmicrosoft.com"-Domain dazu und beide sind per MX-Record auflösbar.

 

Es kann keine Fehlkonfiguration sein, das durch das zentrale Mailrouting über die On-Premises Umgebung und den lokalen NoSpamProxy waren die Office 365 Dienste nie über SPF, DKIM, MX-Records für die Domäne ersichtlich. Für einen Spammer ist es natürlich kein Problem zu einer bekannten Domäne zu ermitteln, ob es einen Office 365 Tenant dafür gibt. Dazu muss er z.B. nur per NSLOOKUP nach einem TXT-Record suchen, der ein "ms=xxxxxxx" enthält. Schon kann der Sender ziemlich sicher sein, dass auch SMTP zu Office 365 möglich ist. Die Mailserver sind ja für alle Tenants identisch und einfach aufzulösen. Herausgekommen ist also folgendes Mailrouting:

Das gilt es natürlich zu verhindern.

Microsoft hat das Thema mittlerweile auch in einem Blog-Artikel thematisiert
Advanced Office 365 Routing: Locking Down Exchange On-Premises when MX points to Office 365
https://techcommunity.Microsoft.com/t5/exchange-team-blog/advanced-office-365-routing-locking-down-exchange-On-Premises/ba-p/609238

Szenario 2: OnPremises Connector

Es gibt aber noch ein weiteres Szenario und das basiert auf einem Missbrauch des Hybrid Connectors. Normalerweise ist Exchange Online hier "dicht", weil es sich auf die Source-IP oder Zertifikat des Exchange OnPremises Servers beschränkt. Wer hier schludert, z.B. weil er eine sehr große IP-Range erlaubt, öffnet einen Nebeneingang der noch viel kritischer ist.

 

Wenn ein fremder Absender es schafft, den eingehenden Organization Connector ihres Tenants zu erreichen, dann haben sie echt ein Problem. Die Mails werden nicht nur ungefiltert in die Postfächer zugestellt, sondern es ist sogar ein Relay ins Internet.

Dieser Hintereingang existiert nur, wenn sie absichtlich den Hybrid-Connector oder einen anderen manuell angelegten "OnPremises Connector" nicht streng genug konfiguriert haben. Sie sollten hier nur Systeme erlauben, denen Sie vertrauen und die sie eindeutig anhand der IP-Adresse oder Zertifikat identifizieren können.

Lösung: Eingehendes Routing erzwingen

Die aus meiner Sicht sicherste Lösung  ist in dem Fall, dass man den Exchange Online Tenant den direkten Empfang aus dem Internet verbietet. Mails aller externen Domains sollte prinzipiell nur über eigene "bekannte" Hosts kommen. Dazu legen wir einen eingehenden Partner Connector an, welcher für die Remote Domain "*" nur explizit angegebene IP-Adressen oder ein Zertifikat erzwingt. Die absendenden Server könnten die lokalen Exchange Server (Hybrid) oder vorgelagerte Spamfilter sein.

Wenn ich dann von einem anderen System eine Mail direkt an den Tenant senden will, der nicht in der IP-Liste erscheint oder nicht das passende Zertifikat vorweisen kann und auch nicht durch eine andere RBL-Liste von Office 365 schon blockiert wird, dann sehe ich folgendes im SMTP-Protokoll:

SMTP error from remote server for RCPT TO command, host: fcarius.mail.protection.outlook.com (216.32.181.106) 
reason: 550 5.7.51 TenantInboundAttribution; There is a partner connector configur ed that matched the message's 
recipient domain. The connector had eith er the RestrictDomainsToIPAddresses or RestrictDomainsToCertificate 
set [DM3NAM05FT043.eop-nam05.prod.protection.outlook.com]

Der Mailserver, welche diese Mail zustellen will, kann dann einen NDR erstellen. Hier am Beispiel von 1und1.

Beachten Sie noch folgende Randbedingungen:

  • EOP ist weiter aktiv
    Allein die Einrichtung eines Partner Connectors ändert nichts an der Spamfilter-Funktion von Exchange Online. Wer so einen vorgelagerten Spamfilter eine bevorzugte Behandlung geben möchte, muss weitere Einstellungen vornehmen. Siehe auch EXO mit NoSpamProxy und EXO mit 3rd Party Service.
  • Mails an "<tenantname>.onmicrosoft.com
    Nach dieser Einrichtung kann niemand mehr anonym an ihren Exchange Online Tenant senden. Das gilt insbesondere für Adressen mit einer "onmicrosoft.com"-Domain. Diese Domain sollten Sie sowieso nicht nutzen und den Versand damit können und sollten Sie sogar abschalten. Über den Organization-Connector der Hybrid-Konfiguration kommen solche Mails weiterhin an. Sie können aber nicht den MX-Record für die OnMicrosoft.com-Domains ändern. (Siehe auch B2B Mail und Default Domain)
    Ändern Sie daher am besten ihre Default-Domain und senden/empfangen Sie keine Mails mit der
    Wer also z.B. von SharePoint oder Teams Channel eine Mail versendet oder empfangen will, kann diesen Weg so nicht gehen
  • Centralized Mailtransport
    Die Besonderheiten des Hybrid Centralized Mail Transport sind dann auch einfacher, wenn keine anonymen Mails mehr eine Ehrenrunde über OnPremises laufen müssen.
  • Shared Cloud-Services
    Beachten Sie die Besonderheiten von "Shared Cloudservices". Wenn Sie z.B. ihren Spamfilter als Service aus der Cloud einkaufen, dann sollten Sie genau prüfen, dass der Service einen Missbrauch durch eines anderen Kunden auf dem gleichen Service unterbindet. Bei ausgehenden Mails erlebe ich es immer wieder, dass auch Spammer einen Vertrag mit einem Massensender wie Mailgun, SendGrid o.ä. abschließen und dann eine Absenderdomain eines anderen Kunden missbraucht, der diesen Massensender im SPF-Eintrag als "erlaubt" eingebunden hat und damit ein SPF:PASS erreicht.

Microsoft hat diesen Weg mittlerweile auch beschrieben
How to block direct delivery to email address with the suffix as domain.onmicrosoft.com or domain.mail.onmicrosoft.com https://blogs.technet.Microsoft.com/rrajan/2018/05/08/how-to-block-direct-delivery-to-email-address-with-the-suffix-as-domain-onmicrosoft-com-or-domain-mail-onmicrosoft-com/

Die Härtung ihres Tenant können Sie einfach über das Exchange Online Admin Center per Maus konfigurieren. Ich habe hier z.B. die IP-Adresse 80.66.20.20 als Muster genutzt, um alle Mails mit der Absenderdomain "*" anzunehmen.

Wer mag, kann es auch per PowerShell einrichten:

# Verbinden mit Exchange Online
Connect-ExchangeOnline

# Connector anlegen
New-InboundConnector `
   -Enable $True `
   -Name "Inbound only from Antispamrelay" `
   -SenderDomains * `
   -RestrictDomainsToIPAddresses:$true `
   -RequireTls:$true `
   -SenderIPAddresses 80.66.20.20/32

Alternative Transport-Regel

Exchange Online erlaubt auch die Abfrage der einliefernden IP-Adresse über eine Transport-Regel. Damit kann ich noch viel feiner, also z.B. nach einzelner Mailadresse und IP-Adresse das Verhalten steuern.

Diesr Weg hat aus meiner Sicht aber den großen Nachteil, dass die Regeln erst nach dem Empfang der Mail angewendet werden. Der Absender kann also nachweisen, dass er die Mail in den Hoheitsbereich des Empfängers übergeben hat. Ich bin ein Freund eine Mail besser direkt abzulehnen. Das kann eine Transportregel nicht

Lösung: Eingehendes Routing über Hybrid

Wenn Sie eingehende Mails weiterhin über ihren lokalen Exchange Server routen, dann haben Sie "Hybrid" eingerichtet und ein OrganizationConnector sorgt dafür, dass die Mails innerhalb ihrer Firma zuverlässig und formattreu ankommen. Das gilt aber nicht für externe Mails. Der "Inbound Organization Connector" wird nur angewendet, wenn die Absenderdomain aus ihren Domain kommt (Siehe auch OnPremises Connector Attribution) Bei Mails aus dem Internet ist der Absender natürlich "extern". Ohne entsprechenden Connector würde auch hier der "Default Inbound Connector" von Exchange Online angewendet. Dessen Funktion wollten wir aber gerade nicht nutzen, um Zustellungen am MX-Record vorbei zu verhindern.

Wir müssen also auch immer einen parallelen Partner-Connector für Mails einrichten, bei denen der Absender aus dem Internet kommt aber die Mails über den lokalen Exchange Server geroutet werden. Der folgende Code liest z.B. den Hybrid-Connector aus um einen Partner-Connector mit den gleichen Parametern anzulegen.

$onpremiseorg = Get-OnPremisesOrganization | Select-Object organizationguid,inboundconnector | where {$_.inboundconnector -ne $null}

New-InboundConnector `
   -Name 'Restrict Direct Delivery to Initial and Hybrid Co existence domain' `
   -ConnectorType Partner `
   -SenderDomains * `
   -TlsSenderCertificateName (Get-InboundConnector $onpremiseorg[0].InboundConnector).TlsSenderCertificateName `
   -RestrictDomainsToCertificate $true `
   -RequireTls $true

Das ist z.B. die Konfiguration, wenn Mails aus dem Internet nur über den OnPremises Server kommen dürfen. Der Organization-Connector reicht hier nicht, da er anhand der "FROM"-Adresse gewählt wird. Siehe auch OnPremises Connector Attribution.

Feintuning: Spamfilter anpassen

Die Einrichtung des Partner-Connectors verhindert, dass jemand vorbei an meinem per MX-Record veröffentlichten Servern Mails direkt an Exchange Online sendet. Eine Teil fehlt aber noch: Eingehende Mails, die über den Partner-Connector zu Office 365 gesendet werden, unterliegen immer noch dem Spamfilter von Office 365. Hier sind zwei Dinge wichtig:

  • EXO Enhanced Filtering
    Die Mails aus dem Internet kommen nun nicht mehr von dem eigentliche Absender an. Damit wird jeder SPF-Check fehlschlagen. wenn Sie Exchange Online nicht mitteilen, das er die einliefernde IP-Adresse ignorieren und besser die davor liegenden IP-Adressen bewerten soll.
  • Transportfilter
    Wenn die Mails von EOP nicht mehr direkt abgelehnt werden, dann könnten sie immer noch als Spam klassifiziert und nach Junk-E-Mail verschoben werden. Hier sollten Sie mit einer Transportregel nachsteuern. Idealerweise setzt der davorstehende Spamfilter einen Header, den Sie dann abfragen und basierend darauf den SCL setzen können, z.B.

Eine Transportregel könnte wie folgt eingerichtet werden:

Hybrid Fehlkonfiguration

Eine weitere Quelle solcher Irrläufer kann eine fehlerhafte Konfiguration in einem anderen Tenant sein. Wer Office 365 als Mailserver nutzt, steht fast immer vor der Herausforderung, interne Mailmailserver den Versand über Office 365 zu erlauben. Technisch wird dies durch einen "Inbound Connector" in Office 365 gewährleistet, über den Nachrichten der selbst betriebenen Mailservern eingeliefert werden.

Office 365 nutzt zur Identifizierung dieser Systeme die Source-IP-Adresse oder den CN aus dem TLS-Zertifikat:

Soweit klingt das alles verständlich. Allerdings zeigt es sich immer wieder, dass bei der Konfiguration des "Inbound Connectors" etwas vergessen wird oder beim Versand z.B. die Source-IP auf der Firewall falsch gesetzt wird oder jemand einen neuen Mailserver "On-Premises" installiert und die Konfiguration in der Cloud nicht anpasst.

Wenn dann dieser interne Server seine Mails an die Postfächer in der Cloud senden will, dann wird er nicht über den "Inbound Connector" erfasst, sondern wie ein ganz normaler "anonymer" Absender über Exchange Online Protection geführt und die Mails wird zugestellt, wenn Sie nicht als Spam erkannt wird. Der normale Anwender der Firma in der Cloud erkennt also auf den ersten Blick keinen Unterschied da die Mail angekommen ist.

Wenn dieser Server nun aber über den Tenant auch Mails zu anderen Domänen zu senden, dann kann er dank des Smarthosts auch andere Tenants erreichen, obwohl der MX-Record der Empfängerdomäne vieleicht gar nicht auf Office 365 verweist. In dem Fall empfängt die anderen Firma Mail direkt in Office 365 oder bei Hybrid sogar lokal mit Office 365 als Zwischenstation. Der Admin der Empfängerstation sieht dann eigentlich nur wenige Mails wo er doch gar keine Mails erwartet.

Wenn es aber wirklich so sein sollte, das der Absender diese Systeme Mails an seinen eigenen Tenant senden will und mangels passendem Eintrag die Mails so beim anderen Tenant landen, dann dürfte der Absender zumindest keine Mails an Domains senden können, die nicht in Office 365 gelistet sind. Office 365 ist ja kein „offenes Relay“. Da kann ich nur hoffen, dass der Betreiber auch die Rückmeldungen (NDR) verarbeitet.

Versuch mit Connection Filterung

Diese Konfiguration ist mittlerweile aus dem Exchange Admin Center ins Security Center verlagert worden. Ich nutze die Funktion nicht mehr.

Damit meine Umgebung entsprechend geschützt ist, hatte ich zuerst vor über die Connection Filterung die IP-Adressen zu beschränken. Meine Planumgebung sollte also wie folgt aussehen. Durch eine geeignete Konfiguration legen Sie quasi einen Schutzgürtel um ihren Office 365 Tenant, der dann über die Allowlist nur noch ausgewählte IP-Adressen mit ihrem Tenant kommunizieren lässt:

In der Allowlist sollten sie natürlich alle Server eintragen, die sich mit ihrem Server verbinden dürfen. Dazu gibt es im Exchange Online Admin Center die Funktion entsprechende IP-Blocklisten oder IP-Allowlisten zu aktivieren. Hier ist normalerweise nichts hinterlegt:

Es gibt hier nur genau einen "Default"-Eintrag. Daher fehlt sowohl der "Add"-Button und den Default-Eintrag können sich auch nicht löschen. Ich weiß nicht, ob Microsoft eine Erweiterung plant. Ich würde mir schon wünschen, dass man mehrere Einträge anlegen und entsprechend benennen kann. Es wäre einfach etwas übersichtlicher, wenn ich mehrere IP-Adressen oder Bereiche verwalte. So kann ich nur einen Default-Bereich verwalten und welche IP-Adresse welche Funktion hat, muss ich mir anderweitig dokumentieren. Hier habe ich mir eine IP-Adresse eingetragen:

Damit habe ich nun aber eine "Allowlist" für meinen Server. Dummerweise ist das nicht zugleich eine "Blocklist" für alle anderen IP-Adressen. Es bedeutet nur, dass meine IP-Adressen "durch" darf, also keinen RBL-Filtern o.ä. unterliegt.

Leider funktioniert diese Funktion also nicht für Blocklisting, da sie hier maximal 1273 einzelne "Class-C Netze (/24) eintragen können und das Internet doch recht groß ist.

Natürlich hat mich nun interessiert, wie schnell solche Änderungen aktiv werden und wann der Client letztlich abgelehnt wird. Exchange Online muss ja zumindest warten, bis es den "RCPT TO" hat, um dann abzulehnen. Auf der anderen Seite gibt es auch Connectoren zum Empfang von Mails, die über IP-Adressen oder Zertifikate qualifiziert werden können. Überstimmen diese eine IP-Blocklist oder IP-Allowlist? Es wird Zeit für eine Momentaufnahme

  • Allow überstimmt EOP Blocklist
    Mit der expliziten Angabe von IP-Adressen oder IP-Netzwerken werden die Filterlisten von EOP überschrieben, d.h. auch RBL-Listen und andere Quellen, die unseriöse Absender beschreiben, werden damit für diesen Tenant freigegeben.
  • Allow überstimmt Blocklist
    Wenn Sie also die gleiche IP-Adresse im beiden Feldern eintragen, darf die IP senden. das erlaubt aber auch, dass Sie ein Subnetz z.B. blocken und ausgewählte Adressen darauf dennoch erlauben.
  • Mehr als 1273 Einträge sind nicht möglich
    Aber sie können natürlich komplette Netzwerke (Netzwerk/Subnetzmaske) verwenden
  • Subnetmark 255.2555.255.0 bis 255.255.255.255
    Sie können IP-Adressen und Subnetze angeben. Allerdings muss sich die Subnetmaske im Bereich /24 bis /32 bewegen. Ein 0.0.0.0/0 geht also nicht. Größere Bereichen sollen über Transportregeln möglich sein. Allerdings dürfte es so spät schwer werden, Mails dann noch abzulehnen.
  • Enable Safe List
    Damit verhindern sie, dass "gut bekannte gute Sender" blockiert werden. Dies ist aber eine globale Liste, die Microsoft von anderen "Trusted Sources" übernimmt ohne genauerer Informationen dazu bekannte zu geben
  • Transportregeln
    Sie sollten wissen, dass aufwändigere Filterungen, z.B. IP-Adressen mit Domainnamen auch in Transportregeln verwendet werden können. Allerdings ist dann kein Ablehnen mehr möglich, sondern nur ein Löschen, NDR senden oder SCL setzen.
  • Verzögerung bis zu 1h
    Die Einstellungen müssen innerhalb von Office 365 natürlich erst zu allen Eingangsservern repliziert werden. Das kann laut Microsoft bis zu eine Stunde dauern.

Beachten Sie, dass eine Quell-IP nicht immer nur genau eine Domain beschreibt. Hinter einer Source-IP können sich durchaus mehrere Firmen und Absender verbergen.

Aktuell scheint es aber noch keine IPv6-Unteratützung zu geben. Aktuell lösen aber auch die MX-Records nur auf Hostnamen auf, die per IPv4 Erreichbar sind (Stand Feb 2018)

Testserie: IP Filterung

Ich habe eine kleine Testserie gebaut:

  • Zugriff per DSL-IP (Dynamisch)
    Ich habe zuerst von einem PC über einen DSL-Router versucht eine Mail zu senden. Office 365 lehnt nicht sofort ab sondern wartet noch, bis ich den RCPT TO sende. Erst dann kann der SMTP-Service den Zieltenant erkennen und prüfen, ob die IP-Adresse erlaubt ist. Ohne Einstellungen blockt Office 365 natürlich die dynamische IP-Adressen.
  • Freischaltung per Allowlist
    Ich habe dann über das Exchange Online Admin Center die öffentliche IP-Adresse freigeschaltet

    Ich habe dann die TELNET-Tests immer wieder versucht.
  • Verbindung wird angenommen
    In meinem Fall hat es fast die komplette Stunde gedauert, bis ich nun Mails einliefern konnte.
  • IP-Allowlist wieder entfernt
    Dann habe ich den Eintrag wieder entfernt, damit ich wieder die gleiche Ausgangssituation habe.

So konnte ich schon mal eine IP-Adresse zulassen, die ansonsten geblockt wird. Office 365 behandelt diesen Absender aber dennoch wie "aus dem Internet"

Testserie: Empfangsconnector

Sie können in Office 365 nun noch einen anderen Weg wählen. Sie legen einen Connector in Exchange an, der eigentlich dafür gedacht ist, Mails von einem Partner oder eben auch von ihrer On-Premises Umgebung zu empfangen. Wenn Sie hier statt "Zertifikat" auch auf die Source-IP-Adresse gehen, dann ist das Ergebnis erst einmal identisch.

Nun gibt es ja noch die Option, dass ich einen Connector erstelle, der Mails annimmt. Um meine Konfiguration nicht zu stören, habe ich dazu eine andere IP-Adresse genutzt, die aber ebenfalls eine dynamische DSL-Adresse war und damit von Office 365 erst einmal abgelehnt wird. Diesmal war sogar "Spamhaus" die RBL-Liste.

Zuerst wollte ich einen Connector vom "Internet" zu "Office 365" erstellen. Office 365 sagt aber, dass man den gar nicht braucht und unterbindet die weitere Konfiguration.

Ich habe dann einen Connector gebaut, den auch der Hybrid Wizard einrichtet, damit Mails von meiner vertrauenswürdigen "On-Premises"-Umgebung ohne Filterung angenommen werden:

Hier hat es bei mir ca. 30Min gedauert, bis diese Konfiguration aktiv wurde und dieser Client nun auch seine Mails einliefern konnte.

Das Ergebnis durch einen Connector unterscheidet sich aber schon von einer reinen IP-Allowlist, denn über den Connector wird z.B. auch gesteuert, dass bestimmte System-Header erhalten bleiben.

Versuch mit Transportregel

Daher ist ein Connector der bessere Weg die Zustellung von Partnern und der eigenen Umgebung zu erlauben. Die Pflege der IP-Allowlist ist eine mehr oder weniger schnelle Option bestimmte IP-Adressen aus der Blockierung von Microsoft auszunehmen. Allerdings dauert das schoneinige Zeit, bis es aktiv wird und hat das Risiko, dass sich hinter der gleichen IP-Adresse auch andere Absender verbergen können. Es ist kein Vertrauen auf einen Domänennamen.

Beide Einstellungen lösen aber nicht das Problem, dass ich eigentlich alle anderen IP-Adressen blockieren will. Ich habe das dann über Regeln versucht, die aber auch keine große Netzwerke zulassen:

Ergebnis

Es ist möglich aber Sie müssen dran denken, denn allein die Einrichtung des Exchange Hybrid Mode mit "Hybrid Centralized Mail Transport" stellt ihnen dies nicht ein. Es wäre natürlich schön, wenn auch der Inbound Connector, der beim der Einrichtung von Hybrid Centralized Mail Transport angelegt wird um einen zweiten Connector für "Partner"-Systeme ergänzt wird. Mit der von Microsoft beschriebenen Lösung gibt es nun aber einen sauber dokumentierten Weg, den Sie bei Bedarf umsetzen können.

Weitere Links