MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Mailbox Autodetect - Simplified Account Creation

Wussten Sie, dass Microsoft einen Web-Service bereit stellt, mit dem Sie recht zuverlässig die Postfacheinstellungen für eine Mailadresse ermitteln können? Ein Nutzer ist z.B. das Testskript (Test-HMAEAS.ps1) für Hybrid Modern Auth. Vom Namen dürfte auch Outlook Mobile diese URL nutzen. Also war es an der Zeit, die API etwas anzuschauen.

Anscheinend nutzt diese Abfrage auch das aktuelle Outlook 2025 LTS. Ich hatte schon erste Supportanfragen, weil ein OnPremises Outlook nicht mehr zuerst Autodiscover nutzt, sondern diesen neuen Weg. Wenn der dann nicht funktioniert, dann funktioniert die Outlook Profileinrichtung nicht mehr.
Wenn der User das Profil aber über die Systemsteuerung einrichtet, dann wird wieder (Stand Juli 2026) weiter der klassische Autodiscover-Weg genutzt.

Simplified Account Creation

Es obliegt dem Client einen Weg zur automatischen Konfiguration des Profils zu finden. Seit Outlook 2016 hat Microsoft ein "Simplified Account Creation" eingeführt, welches anscheinend noch komplett vor "Autodiscover" erfolgt. Outlook und neuere Clients versuchen über einen neuen WebService die Zugänge zu den verschiedenen Mailsystemen zu ermitteln. Microsoft bedient damit nicht nur Exchange Online und Exchange OnPremises, sondern versucht auch GMail, Yahoo und diverse IMAP4/SMTP-Dienste damit abzufangen.

Der Nachteil dabei ist, dass einige Anfragen vielleicht irreführend sind. Stellen Sie sich vor sie haben Exchange OnPremises und parallel dazu auch ein Postfach bei einem IMAP4-Provider (IONOS, HostEurope, Hetzer etc.) für ihre Domain eingerichtet. Früher hat ihr Outlook eine Anfrage per Autodiscover und SCP im lokalen AD gemacht, um den Exchange Server zu finden oder ist per klassischen Exchange - Autodiscover über DNS und HTTP bei ihrem Exchange Server OnPremises oder Online gelandet. Nun könnte es sein, dass der Mailclient bei einem ISP landet, obwohl es einen lokalen Exchange Server gibt.

Mit Fiddler können Sie auf ihrem Client die ein oder andere Anfrage sehen, die wich wie folgt nachstellen kann

Invoke-RestMethod `
   -Uri 'https://prod-autodetect.outlookmobile.com/detect
            ?services=office365,outlook,google,icloud,yahoo
            &protocols=rest-cloud,rest-outlook,rest-office365,eas,imap,smtp' `
   -Headers @{'x-email'="user@msxfaq.de"}

Die Anfrage erfolgt komplett Anonym und erwartet die Mailadresse im Header-Feld "x-email". Die Anbtwort ist eine JSON-Struktur

 

 

Früher hat sogar noch eine URL zu Acompli.net funktioniert, womit auch klar ist, dass dies keine Microsoft-Erfindung war sondern durch den Merger von Acompli stammen dürfte, aus dem dann Outlook/IOS und Outlook/Android übernommen wurde. 

# Die URL funktioniert nicht mehr. Der Host ist nicht mehr auflösbar
Invoke-WebRequest `
   -Uri 'https://prod15-files.acompli.net/autodetect/detect?
            ?services=office365,outlook,google,icloud,yahoo
            &protocols=rest-cloud,rest-outlook,rest-office365,eas,imap,smtp' `
   -Headers @{'x-email'="user@msxfaq.de"}

Wenn diese neue Auflösung bei ihnen "unerwartete" Werte liefert und damit die initiale Einrichtung des Postfachs über den Assistenten fehlt schlägt, dann können Sie die Nutzung der "Simplified Account Creation zumindest für Outlook abschalten:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\AutoDiscover]
"DisableOffice365SimplifiedAccountCreation"=dword:00000001

Alternativ können Sie auf Windows das MAPI-Profil auch über die Systemsteuerung einrichten. Hier scheint Microsoft noch nicht (Stand Juli 2026) den neuen Assistenten zu nutzen.

Test-HMAEAS.ps1

Mit der URL kann ich natürlich Code und Skripte durchsuchen und wurde z.B. in Test-HMAEAS.ps1 fündig. Dort gibt es eine Funktion "Test-AutoDetect". Sie verrät etwas mehr über den Einsatz und die Rückgabe:

Microsoft stellt eine REST-API bereit, die als Parameter den oder die Services und Protokolle erwartet.

Einstellung Werte

URL

https://prod-autodetect.outlookmobile.com/detect

Parameter "Services"

Ein oder mehrere Werte als Liste

  • office365
  • outlook
  • google
  • icloud
  • yahoo

Parameter "protocols"

Ein oder mehrere Werte als Liste

  • rest-cloud
  • rest-outlook
  • eas
  • imap
  • smtp

Eine Authentifizierung ist anscheinend nicht erforderlich und die Rückgabe ist dann eine JSON-Struktur

Test und Beispiele

Ausgehend mit diesem Wissen habe ich einige Tests mit mir bekannten Mailadressen gemacht: Der Aufruf war (zur Lesbarkeit umgebrochen)

Invoke-RestMethod `
   -Uri 'https://prod-autodetect.outlookmobile.com/detect
            ?services=office365,outlook,google,icloud,yahoo
            &protocols=rest-cloud,rest-outlook,rest-office365,eas,imap,smtp' `
   -Headers @{'x-email'="user@msxfaq.de"}

Je nach Antwort kommen denn Wert bei "Services" und "Protocols" zurück

Test Rückgabe

Exchange Online Postfach

Dieser Benutzer hat ein reines Exchange Online Postfach

 

Exchange OnPremises mit Hybrid

Wenn ein Postfach auf einen OnPremises-Server liegt aber die Domain schon im Exchange Hybrid Mode konfiguriert ist, dann liefert der Service bei mir nur den ActiveSync-Endpunkt (EAS) unter "protocols" aber keine Eintrag "Services". Ich würde dies so interpretieren, dass für das OnPremises Postfach kein Service für "new Outlook" angeboten wird. Das neue Outlook kommuniziert immer mit einem Cloud Service und unterstützt aktuell nur Exchange Online oder IMAP4/SMTP aber keinen lokalen Exchange Server.

Ich sehe aber, dass der Cloud-Service sehr wohl eine Anfrage an den lokalen Autodiscover-Endpunkt macht. Mit IIS Failed Request Tracing konnte ich einen anonymen Zugriff sehen:

Der User-Agent ist "OutlookMobileCloudService-Autodetect/1.0.0". Das ist eine Autodiscover V2 Anfrage.

Exchange Online aber ungültige Mailadresse

Wenn ich die Daten für eine ungültige Mailadresse einer Domain frage, die in einem Microsoft 365 Tenant registriert ist, dann verweist "Autodiscover" auf den lokalen Exchange Server. Wenn Sie also beim Hybrid-Betrieb mit ADSync nicht alle OnPremises-Benutzer auch in Exchange Online bekannt gemacht haben, dann sollte die Funktion dennoch möglich sein

 

Exchange OnPremises ohne Hybrid

In dem Fall verweist "Autodiscover" auf den lokalen Exchange Server und es gibt keinen Tenant. Entra ID und Exchange Online wissen also nichts von der Domain, außer dass Sie per DNS einen Autodiscover auf einen lokalen Server finden können.

 

Wenn die Domain nicht in Microsoft 365 bekannt ist, dann kann der Service keine Antwort liefern. Auf HTTP-Level kommt ein "204 NoContent" zurück und der Body ist leer:

 

GMX

Auch eine Anfrage nach einer Domain bei GMX liefert die korrekte Zugangspunkte.

IONOS (nicht in EXO)

Da ich historisch noch ein Webhosting bei IONOS mit einer Domain habe, habe ich den Test dort wiederholt.

SelfHosted Unix (all-Inkl)

Ich glaube eine Firma gefunden zu haben, deren Domain nicht in EntraID hinterlegt ist und einen Autodiscover-Eintrag auf ein lokales System hatte. Dahinter war aber kein Exchange Online sondern ein NGINX. Der Microsoft Cloud Service hat aber dennoch die richtigen IMAP/SMTP-Server ermittelt

Strato?

Dies ist noch eine andere Antwort bei der Anfrage nach dem Mailsystem einer Stadtwerke. Interessant ist hier, dass es mir für EAS einen "autoconfogure"-Eintrag zu Strato liefert aber bei IMAP4 dann ein anderes Gateway. Das sieht eher so aus, als wenn der Service hier einfach den MX-Record der Domain nutzt und die Hostnamen einsetzt. Unter der Adresse meldet sich zwar ein IMAP4-Server, der aber im Label ein "Trainingsystem" hat. Per SMTP meldet sich ein EXIM.

 

Die Ergebnisse sind nur tauglich, wenn Sie mit einem 200OK geliefert werden. Manchmal habe ich einen "204 NoContent" erhalten. Nach einigen Wiederholungen kam dann aber doch die Information

Bewertung

Microsoft stellt hier wohl einen WebService (REST) für Outlook Mobile aber auch andere Clients bereit, der ohne Authentifizierung genutzt wird. Ich habe aber den Eindruck, dass der Service immer zuerst in Exchange Online nachschaut und dann auch die Cloud-Postfächer liefert. Ich habe z.B. eine Domain "carius.de", für die ich zwar Benutzer in einem Microsoft 365 Tenant habe, aber deren primäres Mailsystem nicht Exchange Online sondern ein klassischer IMAP4-Hoster ist. Der WebService liefert hier dennoch das Exchange Online Postfach. Das ist aber wohl eher ein Sonderfall.

Die URL kann aber schon einmal nützlich sein, um z.B. weitere Details über ein Postfach zu ermitteln, auch wenn das Postfach nicht in Exchange Online liegt. Dann allerdings sollten Sie die Ergebnisse kritisch prüfen, denn wenn wirklich nur der MX-Record als IMAP4-Server geliefert wird, dann dürfte die Verbindung nicht zustande kommen. Da aber Anbieter wie GMX oder IONOS passend aufgelöst werden, bedeutet entweder eine funktionierende Autodiscover/Autoconfigure-Konfiguration oder eine manuelle Vorgabe durch Microsoft.

Weitere Links