Mountain Prophet

Dec 02 2011

Mischbetrieb POP3/IMAP und Office365 Exchange Konten

44 responses so far

44 Responses to “Mischbetrieb POP3/IMAP und Office365 Exchange Konten”

1. # Office 365 im P1 Tarif: Erste Mängel ersichtlich » Mountain Propheton 02 Dec 2011 at 22:32

   [...] Offiziell ist kein Mischbetrieb gehostetes Exchange / andere Konten unter der selben meinedomaene.de möglich. Update 01.12.2011: Einen Workaround, wie es trotzdem geht habe ich hier: POP3/IMAP und Exchange unter der selben Domäne mischen [...]

2. # Benjamin Stormon 10 Jan 2012 at 19:21

   Stephan,
   Deine Anleitungen sind der Hammer. durch diese Anleitung spare ich mir die Kosten von 3 Nutzern im Monat. Wenn Du mal in Hamburg bist, lade ich Dich gerne zum Essen ein.
   Gruß Benjamin

3. # schwarzmediaon 14 Jan 2012 at 13:06

   danke. sehr gute und verständliche anleitung!!!!
   konnte mir von ms keiner so mitteilen
   gruß
   as

4. # Andreason 22 Jan 2012 at 22:22

   Hallo,

   hier sollte im DNS noch ein SPF (Sender Policy Framework) Eintrag angelegt werden, damit ausgehende Mails nicht von anderen Servern als Spam erkannt werden. Da jeder Mailserver theoretisch in Eurem Namen verschicken könnte, fragen die empfangenden Mailserver bei Eurer Domain an, ob z.B. outlook.com überhaupt in Eurem Namen verschicken darf.

   Folgender DNS Eintrag vom Typ TXT (Ändern bzw. erweitern, falsch für Eure Domain schon vorhanden schon vorhanden) löst das Problem

   v=spf1 mx include:outlook.com ~all

   Das MX bedeutet, dass der eingetragene MX Server versenden darf (also im Normalfall Euer Provider selbst), include:outlook.com bedeutet, dass zusätzlich Office365 im Namen Eurer Domain versenden darf.

   Ich habe das nicht getestet, da ich selbst die komplette Delegation verwende. Vielleicht überprüft das der ein oder andere!

   Gruß
   Andreas

5. # adminon 23 Jan 2012 at 02:30

   Hallo Andreas,

   Du hast Recht, ist aber ein bissl komplizierter, drum hab ich das erst mal noch weggelassen (“Lieber kein SPF als ein falscher”)..

   Das “v=spf1 mx include:outlook.com… ” klappt ja eigentlich nur, wenn Posteingangs- und Ausgangsserver identisch sind. Das sind se aber im Shared Hostingbereich nicht immer..

   Ich muss mir da mal noch was gutes “Allgemeingültiges” als Anleitung dazu einfallen lassen. Und wenns nur ein “prüft bei eurem Provider, welcher SMTP Server zuständig ist und includiert ihn hier” oder sowas.. Mal schauen.

   Aber thx fürs vorbeischauen und den Tipp!

6. # Kaion 02 Feb 2012 at 16:25

   hallo,
   zunächst mal vielen dank für die anleitung, hat gut geklappt. allerdings werden jetzt manche emails als spam erkannt und können nicht zugestellt werden. scheint das problem des vorigen eintrags zu sein, was muss ich denn bei meinem provider eintragen lassen? vielen dank.

7. # Andreason 03 Feb 2012 at 10:19

   Hi,

   Du müsstest einmal nachschauen, ob ein SPF Eintrag für Deine Domain vorliegt.
   Z.B. mit http://network-tools.com, Punkt bei “DNS Records” setzen und dann deinen Domainnamen eingeben, den Du als Absenderadresse nutzen möchtest.

   Schaue dann einmal, ob schon ein TXT Eintrag existiert, der mit v=spf1 beginnt.

   Falls er existiert, kopierst Du ihn Dir in ein Textdokument und fügst an die Stelle nach v=spf1 eine Leerstelle, gefolgt von include:outlook.com ein.

   Also wenn vorher da stand
   v=spf1 mx a include:smtp.provider.de ip4:12.23.45.67 ~all
   sollte hinterher
   v=spf1 include:outlook.com mx a include:smtp.provider.de ip4:12.23.45.67 ~all
   da stehen.

   Gibt es noch keinen TXT Eintrag, der mit v=spf1 beginnt, dann benutzt Du im weiteren Verlauf einfach folgenden:
   v=spf1 mx include:outlook.com ~all

   Jetzt musst Du den Eintrag in den Nameservereinstellungen Deiner Domain bei Deinem Provider ändern und den neuen Eintrag als Typ TXT hinzufügen oder ändern. Das geht leider immer unterschiedlich, so dass man hier keine allgemeingültige Erklärung geben kann.

   Solltest Du nicht wissen, wo man das einstellt, einfach den Provider fragen.

   Gruß
   Andreas

8. # Andreason 03 Feb 2012 at 10:22

   Nachtrag zum vorigen Beitrag:
   Wenn bei Eurer Domain kein Eintrag hinterlegt ist, nehmt als allgemeingültige Standardeinstellung statt wie oben beschrieben nicht
   v=spf1 mx include:outlook.com ~all
   sondern
   v=spf1 a mx include:outlook.com ~all

   Damit sollte es für alle Domains klappen.

9. # adminon 03 Feb 2012 at 11:07

   Andreas,

   danke für en Beitrag, ich kopier das mal schnell oben mit den Blogpost, hoffe das ist OK für dich

10. # Andreason 03 Feb 2012 at 11:08

    Klar!

11. # Michaelon 15 Mar 2012 at 11:27

    Hallo Bergprophet,

    vielen Dank für die Anleitung. Was Du hier beschreibst, ist genau was ich benötige. Allerdings hat eventuell MS etwas am Ablauf geändert (?).

    Zur Verifizierung der Domain verlangt MS nun bereits das setzen von MX Einträgen bei Hoster meiner Domain. Du schreibst, dass man bei Punkt 1 und 2 erstmal nichts bei den DNS Einträgen vom Hoster meiner Domain ändern soll. Hat MS da etwas geändert oder kann man den Eintrag auch nur temporär setzen und dann wieder heraus nehmen?

    Kannst Du da eventuell etwas dazu sagen?

    Danke im Voraus!

12. # adminon 15 Mar 2012 at 12:21

    Hi Michael,

    Ja, zum Überprüfen will MS seit ner Weile einen MX Eintrag oder TXT Eintrag (TXT geht auch wenn dein Domänenprovider TXT zulässt)..

    Der Eintrag zur Überprüfung soll ja mit möglichst niedriger Priorität angelegt werden, also MX 90 z.b. der stört im Betrieb nicht. Den kannst du also ruhig mit dazu machen. (Und nach erfolgter Überprüfung kann man den auch gleich wieder löschen)

    Wichtig und was ich mit meinem Satz da oben sagen wollte ist: der MX mit der höchsten Priorität muss dann am Ende im Betrieb dieser Mischlösung weiterhin auf den Mailserver deines Providers zeigen und nicht auf Office 365

13. # Maikon 14 May 2012 at 08:51

    Lieber Bergprophet,

    wir fahre in der Firma zu Testzwecken seit kurzem o.g. Mischbetrieb, allerdings mit dem E1-Plan (Grund ist, dass bisher erst eine Abteilung auf Office 365 migriert werden soll, ohne die anderen Emailkonten beim externen Provider anzufassen).

    Jetzt bemerke ich folgende Unstimmigkeit:

    Die Testkonten sind alle, wie in deiner Anleitung beschrieben, über die Office365-Verwaltungsseite eingerichtet, die Überprüfung positiv, primäre und sekündäre Emailadresse ordentlich gesetzt. Im Outlook des jeweiligen Kollegen (welcher am Testbetrieb teilnimmt) ist sowohl das Office-365, als auch das alte Pop3-Konto eingerichtet, das Office365-Konto als Standard gesetzt.

    Sendet der Kollege X jetzt eine Email an das alte Pop3-Konto eines Kollegen, der NICHT in der Testgruppe ist, kommt die EMail nicht an, benutzt er sein altes Pop3-Konto, wird sie ordentlich zugestellt.

    Verschickt Kollege X eine Email über Office 365 an Kollege Y, welcher sich ebenfalls in der Testgruppe befindet, wird diese ordentlich zugestellt.

    Wir haben also eine Aufteilung in Office365/Exchange- und Pop3-Emailversand. Wie kann es dazu kommen, wenn man sich haarklein an die o.g. Anleitung hält?

    Ich hoffe, du weißt Rat.

    Danke im Voraus!

    Maik

14. # adminon 14 May 2012 at 09:05

    Hi Maik,

    würde dir liebend gerne helfen, aber ich kenne das Problem nur, wenn vergessen wurde, wie in #7 beschrieben, den Domänentyp auf “Freigegeben” umzustellen.

    Was jetzt kommt ist also nur noch wildes Raten: könnte Kollege X den Test mal nochmal wiederholen, aber zum Versand mal das Outlook Web Interface (OWA) benutzen?

    Bekommt Kollege X nen Bounce als Fehlermeldung?

    Könnt Ihr mal Euren Spamfilter prüfen, ob die eMail eventuell dort blockiert wird?

15. # Maikon 23 May 2012 at 11:21

    Hallo,
    danke für die schnelle Antwort.

    Bei uns sieht es so aus, dass nach dem Einrichten des Mischbetriebes teilweise Emails und Termine “im digitalen Nirwana” verschwinden.

    Hierbei verschickt Kollege H an Kollege I, wobei beide NICHT Teilnehmer in der Office 365-Teilmenge sind. Wie kann das sein?

    Es kommt keien Bouncemessage zurück, vom Sender aus scheint die Mail ordnungsgemäß abgeschickt worden zu sein.

    In der, unter Punkt 7 angegebenen, Exchangeverwaltung ist meinefirma.com mit dem Status “freigegeben” gesetzt, die onmicrosoft.com-Domäne auf “gehostet”.

    Kann es eventuell sein, dass MS die Emailzustellung “übernommen” hat und wir es hier mit einem Relayingproblem zu tun haben? Oder ist eventuell der E-Plan hier der Schuldige, der andere Konfigurationsmuster als der P-Plan aufweist?

    Nachdenklich Grüße,

    Maik

    Gruß,

    Maik.

16. # Maikon 23 May 2012 at 11:23

    Es sei ferner noch zu sagen, dass es scheinbar wahllos geschiet, also unabhängig, wer sich in welcher Mailgruppe (Office365 oder Nicht-Office365) befindet.

    Welchen Spamfilter sollte ich hier zu rate ziehen? Den von Office 365 oder den unseres Emaildienstleisters?

    Danke für jede Hilfe und Grüße

    Maik

17. # Stefanon 26 Jun 2012 at 14:58

    Hi,

    da hab ich auch grad eine Frage. Nebenbei, vielen Dank für diese Anleitung, extrem Hilfreich!!

    Ich habe den Mischbetrieb so eingestellt, wie du es oben erwähnt hast, auch die Domäne auf Freigeben gestellt.
    Jetzt kann ein Externer mir E-Mail schicken und ich kann allen Antworten, auch Internen (Office 365, als auch beim Provider). Nur die Internen können mir keine E-Mail schicken (die beim Provider). Vom Office 365 können mir Problemlos alles E-Mails schicken.

    Liegt das evtl. am spf1 eintrag, muss ich da mein Provider dazunehmen? Momentan ist nur der outlook.com Eintrag drin.

    Vielen Dank!!

18. # adminon 26 Jun 2012 at 22:23

    Ja, liegt mit großer Wahrscheinlichkeit am SPF Eintrag, wenn nur outlook.com drin ist, dann weisst O365 die Mails vom Provider ab.

19. # Stefanon 27 Jun 2012 at 08:46

    Vielen Dank, war die Richtige vermutung.

    Nochmals Danke!

20. # Stefanon 25 Jul 2012 at 11:04

    Achja vielleicht kannst du mir eine Frage beantworten, die im Microsoft Forum nicht beantwortet wird.
    Die Domain (“domain.onmicrosoft.com”), wird die irgendwann gelöscht, oder kann ich die als Alias weiterverwenden?
    In meinem Account steht “Eines Ihrer Testabonnements ist abgelaufen und wird in 69 Tagen deaktiviert”.
    Im Microsoft Forum wurde mir soweit ich verstanden hab gesagt, dass es gelöscht wird nach der Zeit…

21. # adminon 25 Jul 2012 at 12:22

    Stefan,

    Deine domain.onmicrosoft.com bleibt auf jeden Fall bestehen.. Sogar mehrere Monate über den Ablauf der Test-/Abozeit hinaus.

    Ich hab noch nicht erlebt, das jemals ein Konto gelöscht wurde, auch nach zig Monaten ohne gültige Lizenz nicht. Was so nach ca. 30 Tagen nach Ende Abo passiert, ist dass du die Dienste nimmer nutzen kannst, sehr viel später sind dann auch die Daten mal weg, aber dein Admin User kann jederzeit immer ein Abo machen und dann gehts wieder weiter, dazu muss auch dein domain.onmicrosoft.com immer aktiv sein.

    Dieser “Lizenz ist abgelaufen” Hinweis dürfte die Lizenz für den gratis Testzeitraum sein. Office365 weiss nicht, ob parallel schon ein Abo existiert und nörgelt deshalb munter weiter wegen der ablaufenden Testzeit.

22. # Stefanon 25 Jul 2012 at 15:04

    Das ist auf jedenfall eine Erleichterung. Muss ich mich nicht mit Subdomains rumschlagen beim DNS Anbieter.

    Wiedermal vielen Dank für die Ausgezeichnete Hilfe!

23. # Thorstenon 02 Aug 2012 at 12:25

    Hallo,
    eine Rückfrage zu Punkt 3. Deiner Anleitung. Wo muss denn diese eine Einstellung
    für autodiscover vorgenommen werden? Beim Provider, also in meinem Fall bei 1&1?
    Ist das dieses Geschichte mit subdomain anlegen etc.?

    Danke & Gruß, Thorsten

24. # adminon 02 Aug 2012 at 12:36

    Thorsten,

    ja, richtig.. diesen CNAME Eintrag machst du im 1&1 Admin Interface (also login.1und1.de ). Und bei 1&1 üblich richtet man sich zuerst eine Subdomäne autodiscover.meinedomain.de ein, dann ändert dort den CNAME.. Ich hab das Prozedere mit Subdomain und Co bei 1und1 in dem Post hier: http://www.mountainprophet.de/2011/12/31/ofice-365-domanen-bei-1und1-einrichten/ mit Bildern beschrieben, für dich gilt erstmal nur der Teil mit Autodiscover..

25. # pottron 19 Sep 2012 at 15:32

    Da ich leider nicht genau weiß, welche Technik hinter den Funktionen “Kalendertermine, Termine abgleichen mit Mitarbeitern, Kalender freigeben, Räume belegen,..” steckt, stellt sich mir die Frage ob die hier vorgestellte Lösung irgendwelche Beschränkungen in irgendeiner Form bei dieser Art von Aufgabentypen haben? Wäre nämlich echt nicht schlecht, wenn ich das wie oben genannt umsetzen könnte :-)

26. # dlon 22 Sep 2012 at 00:20

    also ich habe alle einstellungen so gemacht, wie im artikel beschrieben, allerdings kommt beim anmelden im owa dann folgende mitteilung:

    A mailbox couldn’t be found for alias@domain.onmicrosoft.com. If the problem continues, contact your helpdesk.

    Request
    Url: https://am2XXXXXXX.outlook.com:443/owa/auth/error.aspx?wa=wsignin1.0
    User host address: xx.xx.xx.xx
    OWA version: 14.16.190.8

    habt ihr eine idee?

27. # adminon 22 Sep 2012 at 00:30

    DL,

    Ich bin etwas verwirrt, weil da in der Fehlermeldung alias@domain.onmicrosoft.com auftaucht. Die passt mir grad überhaupt nicht ins Bild. Der Login im OWA kann ja nur für eines der Postfächer erfolgen, die auf O365 lizenziert und eingerichtet sind und die müsste schon das Muster name@meinefirma.de sein (da Login im O365 Portal oder OWA mit der Primäradresse erfolgen muss)

28. # adminon 22 Sep 2012 at 00:38

    Pottr,

    Sorry für die späte Antwort. Im Prinzip drehen wir hier nur am eMail Routing, externe Konten unterliegen weiterhin den üblichen Beschränkungen, die Funktionalität innerhalb der O365 User darf vom geänderten Domänentyp und dadurch Routing eigentlich nicht negativ beeinflusst werden. Konkrete Erfahrungswerte hab ich aber nicht, wenn man mal vom Fehlen von Problemreports absieht..

    Ich schau mal, ob ich das mal in meiner Testumgebung nachstellen kann und würde dann nochmal ganz laut rufen ;-)

29. # dlon 22 Sep 2012 at 10:31

    also, ich habe eine neue email angelegt wie beschrieben mit alias@domain.com, dem nutzer die lizenz vergeben und als alias (sek adresse) alias@domain.onmicrosoft.com angelegt.

    unter verwaltung nutzer stehen jetzt zwei accounts. einer hat keine lizenz und kann auch nicht gelöscht werden (alias@domain.onmicrosoft.com), der andere hat die lizenz.

    wenn ich mich mit dem automatisch vergebenem passwort dann anmelde (mit alias@domain.com):
    https://login.live.com/login.srf?wa=xxxx (redirect)
    kommt passwort falsch. verwende ich die passwort vergessen option wird die mail zugestellt, bei click auf link kommt: Microsoft-Konto

    Anmelden
    Es ist ein vorübergehendes Problem aufgetreten

    Es gibt ein vorübergehendes Problem bei dem Dienst. Bitte versuchen Sie es erneut. Wenn die Meldung weiterhin angezeigt wird, versuchen Sie es noch mal.

    mein gott microsoft?!?!

30. # adminon 22 Sep 2012 at 19:39

    Klingt als ob der Login seitens Microsoft nen Hau weg hat.

    Nochmal der Vollständigkeit halber, du hast nun 2 Nutzer:
    - den Admin der beim Einrichten des O365 Konto automtisch eingerichtet wurde mit name@firma.onmicrosoft.com, ohne Lizenz, darf nie gelöscht werden.
    - und dann ein neuer Benutzer mit Lizenz, mit name@firma.de als Primäradresse.

    Beide müssen in der Lage sein, sich zumindest mal direkt am O365 Portal einzuloggen also da: https://login.microsoftonline.com
    Der Nutzer name@firma.de sollte zusätzlich auch noch direkt beim outlook.com/owa einloggen können.

    Paar Hinweise noch dazu:

    - was MS bis heute noch nicht sauber hinbekommen hat, ist der Wechsel der Anmeldung, also Abmeldung mit User X und dann Neu anmelden mit User Y innerhalb der selben Browsersitzung, gerade beim MS InternetExplorer ist das besonders nervig. Am besten macht macht man dazwischen alle Browserfenster zu, damit die Sitzung beendet wurde.

    - wenn es schonmal einen Nutzer user.name@.. gab und wird dieser gelöscht und dann ein neuer user.name@.. angelegt, kriegst du mit dem neuen kein erfolgreiches Login hin, weil der alte noch 30 im “Papierkorb” liegt und stört. Dabei spielt es keine Rolle, ob das vorher user.name@xyz.de war und es nun user.name@wasanderes.de ist, der Teil vor dem @ ist auschlaggebend (und kann pro Office365 Konto auch nur einmal in einer Primäradresse verwendet werden)

    Ich hoffe, das hilft dir etwas weiter…

31. # Claudioon 29 Sep 2012 at 17:09

    Hallo Bergprophet, danke für die Anleitung (gerade das mit dem spf-Eintrag).

    Ich sehe aber generell Probleme mit dem Mischbetrieb.
    Meine Einrichtung entspricht Deiner Anleitung. Aber: Ich habe z.B. eine lange und eine kurze Alias-Emailadresse (nur die Initialen). Beide werden entsprechend an die O365-Adresse weitergeleitet. In O365-Exchange hatte ich nur die lange eingerichtet (meine Domäne ist entsprechend in O365 eingerichtet und überprüft). Wenn ich dann eine Testmail an die kurze Adresse senden wollte, kam diese zurück und in Outlook wird diese Adresse beim Eingeben einer neuen Email als not valid gekennzeichnet. Richte ich dann die ALIAS-Adresse als zusätzliche Adresse in O365 ein, fkt. es.

    Meine Erklärung ist: Emails, die man an Adressaten seiner eigenen, in O365 eingerichteten Domäne schickt, werden immer “intern” zugestellt. Existiert das Postfach nicht, gibt es eine Fehlermeldung.

    Weiterhin: In O365 eingerichtete User bekommen wiederum beim Versand innerhalb von O365 diese Email in ihr “internes” Postfach zugestellt. Sie müssen daher dieses verwenden, über ihren alten POP3-Account bekommen sie sonst nie wieder von Emails von Kollegen, die bereits über O365 versenden.

    Wenn man genau darüber nachdenkt, erscheint das ganze auch logisch, denn man hat “seinen” Exchange-Server (wenn auch geshared in der Cloud) und interne Emails werden nunmal nicht “nach draußen” geschickt.

    Prinzipiell ist das auch das Problem von Maik (siehe oben).

    Was ist Deine Meinung dazu?
    Grüße,Claudio

32. # adminon 29 Sep 2012 at 17:33

    Claudio,

    >>In O365-Exchange hatte ich nur die lange eingerichtet (meine Domäne ist entsprechend in O365 eingerichtet und überprüft). Wenn ich dann eine Testmail an die kurze Adresse senden wollte, kam diese zurück und in Outlook wird diese Adresse beim Eingeben einer neuen Email als not valid gekennzeichnet. Richte ich dann die ALIAS-Adresse als zusätzliche Adresse in O365 ein, fkt. es.< <

    Korrekt. In Office365 muss jede Adresse einzeln definiert sein, entweder als Primäradresse, als Alias-Adresse einer Mailbox zugeteilt, als Gruppenpostfach, Verteilerliste, etc. Fehlt die Adresse in Office365, dann verweigert das vorgeschaltete Forefront ("FOPE") grundsätzlich jede die Zustellung.

    >>Meine Erklärung ist: Emails, die man an Adressaten seiner eigenen, in O365 eingerichteten Domäne schickt, werden immer “intern” zugestellt. Existiert das Postfach nicht, gibt es eine Fehlermeldung.< <

    Nur wenn der Domänentyp noch auf Gehostet steht (bzw. mehrere Stunden bis die Änderung tatsächlich aktiv wird!) Genau das Problem wird durch die Änderung des Domänentyps auf "Freigegeben" gelöst. Ist der Domänentyp auf "Freigegeben", dann werden diese eMails extern zugestellt. Ohne diese Änderung des Domänentyps passiert genau das, was du beschreibst..

    >>Weiterhin: In O365 eingerichtete User bekommen wiederum beim Versand innerhalb von O365 diese Email in ihr “internes” Postfach zugestellt. Sie müssen daher dieses verwenden, über ihren alten POP3-Account bekommen sie sonst nie wieder von Emails von Kollegen, die bereits über O365 versenden.<<

    Auch das ist korrekt, sobald wir einem User sein Postfach auf Office365 einrichten, muss er auch Office365 verwenden. In seinem alten POP3/IMAP Postfach, wenn alles richtig konfiguriert wurde, kommt dann nie mehr Post an.

33. # Claudioon 01 Oct 2012 at 11:17

    Hi,
    danke für den Tipp (gerade auch mit der zeitlichen Verzögerung, bis die Änderung in Freigegeben aktiv ist). Habe das Ganze nochmal “durchgespielt” und es fkt.
    Nochmals herzlichen Dank,
    Claudio

34. # Holger Batenon 19 Nov 2012 at 13:18

    Das ist mit Abstand die hilfreichste Seite, die ich bisher zum Thema Microsoft Online Dienste gefunden habe.

    Vielen Dank für diesen Beitrag zum Thema “Domain freigeben”. Bei Microsoft habe ich ewig nach dem beschriebenen Szenario gesucht und natürlich nichts gefunden….

35. # Maikelon 04 Dec 2012 at 12:46

    Geiiiiil, danke für die Anleitung. Warum sie bei Google nicht an erster Stelle gelistet wird verstehe ich nicht.

36. # admin_mdon 23 Dec 2012 at 09:51

    Hallo,
    vielleicht könnt ihr mir auch helfen. Ich bekomme leider seit gestern diese Bounce Meldung zurück bei meinem neu eingerichteten Office 365:

    mail151-tx2.bigfish.com #554 5.4.0 Error: too many hops ##

    Original message headers:

    Received: from DB3PRD0710HT002.eurprd07.prod.outlook.com (157.56.253.85) by
    TX2EHSMHS022.bigfish.com (10.9.99.122) with Microsoft SMTP Server (TLS) id
    14.1.225.23; Sun, 23 Dec 2012 08:22:02 +0000
    Received: from mail78-co9-R.bigfish.com (207.46.163.21) by
    DB3PRD0710HT002.eurprd07.prod.outlook.com (10.255.75.37) with Microsoft SMTP
    Server (TLS) id 14.16.245.2; Sun, 23 Dec 2012 08:21:56 +0000
    Received: from mail78-co9 (localhost [127.0.0.1]) by mail78-co9-R.bigfish.com
    (Postfix) with ESMTP id 0EBEEA00FA for ; Sun, 23 Dec
    2012 08:21:55 +0000 (UTC)
    X-Forefront-Antispam-Report: CIP:213.199.154.140;KIP:(null);UIP:(null);IPV:NLI;H:db3outboundpool.messaging.microsoft.com;RD:reserved;EFVD:RES
    X-SpamScore: 7
    X-BigFish: ps7(z5405izc85dhzz1ce5h1202h1e76h1d1ah1cabh1d2ahzzz2ei5fh2a8h683h839h107ah1288h12a5h12bdh137ah13eah1441h1504h1537h153bh15a8h162dh1631h1741h1758hff4m1155h)
    Received-SPF: neutral (mail78-co9: 213.199.154.140 is neither permitted nor denied by domain of gmail.com) client-ip=213.199.154.140; envelope-from=xxxxxx@gmail.com; helo=db3outboundpool.messaging.microsoft.com ;icrosoft.com ;
    X-Forefront-Antispam-Report-Untrusted: CIP:157.56.249.85;KIP:(null);UIP:(null);(null);H:AMSPRD0710HT003.eurprd07.prod.outlook.com;R:internal;EFV:INT
    Received: from mail78-co9 (localhost.localdomain [127.0.0.1]) by mail78-co9
    (MessageSwitch) id 1356250913337297_20097; Sun, 23 Dec 2012 08:21:53 +0000
    (UTC)

    MX Eintrag habe ich jetzt erstmal wieder bei 1&1 gelöscht, damit ich wieder überhaupt E-Mails empfangen kann . . .

    Ich habe ein P1 Konto daher kein FOPE support. Deshalb kann ich diesen weg hier nicht gehen. http://community.office365.com/en-us/forums/160/t/23696.aspx

    Sowie diese Powershell Befehle habe ich auch schon probiert, ohne Erfolg:
    Set-AcceptedDomain domain -OutboundOnly $true
    Set-AcceptedDomain domain -OutboundOnly $false

    Dake schon mal.
    LG admin_md

37. # adminon 23 Dec 2012 at 13:23

    admin_md,

    schick mir doch bitte mal ne eMail übers Kontaktformular, am besten gleich mit dem kompletten Domänennamen. War das eine Mischkonfiguration? Oder eine normale Teildelegation per MX Eintrag?

38. # Romanon 11 Jan 2013 at 18:46

    Hallo,
    vielen Dank für die Hilfestellung zum Mischbetrieb.

    Gibt es einen Vorschlag für folgende Ergänzung:

    Ich habe mehr als eine Domaine und möchte abgehend entscheiden, ob ich mit mustermann@firma1.de oder mit mustermann@firma2.de meine Mails aus Office 365 versende.
    Manchmal möchten wir aber auch nur von support@firma1.de senden.
    Ankommend wäre es mit der Anleitung ja definierbar, alles könnte in mustermann@firma.onmicrosoft.com weitergeleitet werden.

    Nur abgehend habe ich keine Idee.
    Ich hoffe, ich konnte mich verständlich machen.

    Vielen Dank für Eure hilfreichen Meldungen.

    Gruß

39. # adminon 12 Jan 2013 at 19:19

    Fallweise die Absenderadresse zu ändern bei Office365 ist immer etwas tricky. Office365 erlaubt eine Absender-Adresse pro Lizenzpflichtiger Mailbox. Hast du nun firma1.de und firma2.de in deinem Office365 Konto verifiziert, dann könntest du eventuell für firma2.de noch ne kostenlose Shared Mailbox einrichten und dem firma1.de Konto SendAs Berechtigung eintragen. Damit könntest Du nun fallweise über die DropDownliste beim Von: Feld in Outlook2010 die Absenderadresse umstellen. In der Mischkonfiguration würde ich die ankommenden Mails aber direkt an firma1.de leiten lassen..

    Ich hoffe, das war verständlich, sonst mach ch aber auch gerne nochn ausführlicheres Beispiel.

40. # bobon 28 Jan 2013 at 18:55

    Der Beitrag klingt sehr interessant. Vielen Dank für die Informationen.
    Allerdings habe ich noch eine Sorge und zwar das die Mails die dann über Office 365 gesendet werden ggf. als Spam identifiziert werden (auch wenn man den spf Eintrag hinzufügt), da man ja den Absender einfach ändert und dann das RDNS zu Problemen führen könnte. So wie bspw. hier: http://community.office365.com/de-de/forums/118/t/82476.aspx
    Gibt es für dieses Problem wirklich keinen Workaround?

41. # adminon 29 Jan 2013 at 13:24

    Einen Workaround, damit ein RDNS Check der via Office365 versandten eMail zu meinefirma.de auflöst kenne ich nicht. Das tut ein RDNS übrigens sehr oft nicht, normalerweise muss man fast schon froh sein, dass ein RDNS überhaupt zu was auflöst. Der RDNS sollte das HELO bei der Einlieferung auflösen und das tut er ja, aber halt zu messaging.microsoft.com und nicht zu meinefirma.de

    DomainKey-Status: no signature
    Received: (qmail 2176 invoked from network); 29 Jan 2013 13:35:15 +0100
    Received-SPF: pass (ich.de: domain of meinefirma.de designates 216.32.180.30 as permitted sender) client-ip=216.32.180.30; envelope-from=sk@meinefirma.de; helo=va3outboundpool.messaging.microsoft.com;
    Received: from va3ehsobe010.messaging.microsoft.com (HELO va3outboundpool.messaging.microsoft.com) (216.32.180.30)
    by smtp.ich.de with (AES128-SHA encrypted) SMTP; 29 Jan 2013 13:35:13 +0100
    …

    Persönlich halte ich von einem solchen RDNS als Ausschlußkriterium nicht viel. Schön erklärt wird das ganze z.b. hier: http://msexchangefaq.de/spam/filter-rdns.htm.

42. # khoon 25 Apr 2013 at 14:24

    Hallo, wir haben bisher erfolgreich im Mischbetrieb gearbeitet, seit letzter Woche aber werden Emails von Mitarbeitern, die mit Office365 arbeiten nicht mehr zu denen zugestellt, die damit nicht arbeiten (anders herum funktioniert es).
    Es gibt zunächst eine Office365-Meldung, dass versucht wird, die Email zuzustellen, nach ca. 1 Tag kommt dann eine Meldung, dass die Zustellung gescheitert ist.

    Können Sie hier helfen?

    In der Fehlermeldung steht:

    Diagnoseinformationen für Administratoren:

    Generierender Server: bigfish.com

    empfaenger@meinefirma.de
    # #SMTP#

    Ursprüngliche Nachrichtenköpfe:

    Received: from mail209-co9-R.bigfish.com (10.236.132.246) by
    CO9EHSOBE017.bigfish.com (10.236.130.80) with Microsoft SMTP Server id
    14.1.225.23; Thu, 18 Apr 2013 10:32:08 +0000
    Received: from mail209-co9 (localhost [127.0.0.1]) by
    mail209-co9-R.bigfish.com (Postfix) with ESMTP id F2EB6440280 for
    ; Thu, 18 Apr 2013
    10:32:08 +0000 (UTC)
    X-Forefront-Antispam-Report: CIP:157.56.248.85;KIP:(null);UIP:(null);(null);H:AMSPRD0610HT004.eurprd06.prod.outlook.com;R:internal;EFV:INT
    X-SpamScore: 1
    X-BigFish: PS1(zzc85fhdbeehzz1fc6h1d74h1ee6h1d18h1fdah1202h1e76h1d2ahz31iz17326ah18c673h8275bh8275dhz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh34h1155h)
    Received-SPF: pass (mail209-co9: domain of meinefirma.de designates 157.56.248.85 as permitted sender) client-ip=157.56.248.85; envelope-from=sender@meinefirma.de; helo=AMSPRD0610HT004.eurprd06.prod.outlook.com ;.outlook.com ;
    Received: from mail209-co9 (localhost.localdomain [127.0.0.1]) by mail209-co9
    (MessageSwitch) id 1366281125346226_20017; Thu, 18 Apr 2013 10:32:05 +0000
    (UTC)
    Received: from CO9EHSMHS019.bigfish.com (unknown [10.236.132.249]) by
    mail209-co9.bigfish.com (Postfix) with ESMTP id 52965B00047 for
    ; Thu, 18 Apr 2013 10:32:05 +0000 (UTC)
    Received: from AMSPRD0610HT004.eurprd06.prod.outlook.com (157.56.248.85) by
    CO9EHSMHS019.bigfish.com (10.236.130.29) with Microsoft SMTP Server (TLS) id
    14.1.225.23; Thu, 18 Apr 2013 10:32:01 +0000
    Received: from AMSPRD0610MB361.eurprd06.prod.outlook.com ([169.254.3.18]) by
    AMSPRD0610HT004.eurprd06.prod.outlook.com ([10.255.43.39]) with mapi id
    14.16.0293.003; Thu, 18 Apr 2013 10:31:57 +0000

43. # adminon 25 Apr 2013 at 15:00

    Steht da sonst noch irgendwas in der eigentlichen Fehlermeldung? Sowas wie User/Mailbox unbekannt?

    Bist du kürzlich auf Wave15 (blaues Admininterface) upgegradet worden?

    Spontan würde ich sagen, die Einstellung “Domänentyp: Freigegeben” ist rausgefallen, Punkt 7 oben in der Liste.. das würde das Fehlverhalten erklären. In Wave15 “blau” wurde diese Option geändert..

44. # khoon 25 Apr 2013 at 16:53

    in der Fehlermeldung steht sonst nichts.

    letzte Woche wurde der upgrade angekündigt und dann wieder abgesagt, steht jetzt auch so oben auf der administratorseite.

    unsere fremdhomepage ist weiter mit der Einstellung “Domänentyp: freigegeben” eingetragen.

    kann ich sonst noch was prüfen?

Kommentar dazu? (Geht anonym und ganz ohne Anmeldung)

Name

Mail (hidden)

Website

Notify me of follow-up comments by email.

Notify me of new posts by email.