MENU
  1. Accueil
  2. Microsoft 365
  3. SIP et SPO dans Exchange Online : rôles, bonnes pratiques et pièges à éviter (Teams, SharePoint, OneDrive, ProxyAddresses)

SIP et SPO dans Exchange Online : rôles, bonnes pratiques et pièges à éviter (Teams, SharePoint, OneDrive, ProxyAddresses)

Microsoft 365

Dans Exchange Online, vous voyez parfois des adresses SIP et SPO à côté des adresses SMTP. À quoi servent‑elles, pourquoi n’apparaissent‑elles pas partout et faut‑il les supprimer ? Voici une explication claire, des scénarios et des bonnes pratiques.

Sommaire

Qu’est‑ce que les adresses SIP et SPO dans Exchange Online, et pourquoi ne figurent‑elles pas sur tous les comptes ?

Vue d’ensemble de la question

Dans le Centre d’administration Exchange (EAC), un même objet (utilisateur, boîte partagée, ressource, groupe) peut exposer plusieurs adresses dans la propriété ProxyAddresses. Les plus courantes :

  • SMTP (en majuscules) : adresse primaire de messagerie.
  • smtp (en minuscules) : alias de messagerie supplémentaires.
  • SIP : identité temps réel (héritage Skype Entreprise) utilisée par Microsoft Teams.
  • SPO : identifiant interne géré par SharePoint Online / OneDrive.

Les questions fréquentes : que signifient exactement SIP et SPO, pourquoi n’apparaissent‑elles pas sur tous les comptes, et peut‑on les supprimer ?

Réponse & Solution

Rappels essentiels

  • SMTP / smtp : seule la casse a une valeur fonctionnelle pour SMTP (majuscule = adresse primaire ; minuscule = alias). Pour les autres préfixes (SIP, SPO), la casse n’a aucune signification de « primaire/secondaire ».
  • Chaque entrée de ProxyAddresses commence par un préfixe (SMTP:, SIP:, SPO:, …) qui indique quel service consomme cette valeur.

SIP (Session Initiation Protocol)

  • Rôle : identité temps réel utilisée par Microsoft Teams (héritage Skype Entreprise) pour la présence, la signalisation d’appels et les réunions.
  • Forme habituelle : elle correspond souvent à l’adresse SMTP primaire (ex. SIP:prenom.nom@domaine.tld), mais ce n’est pas une obligation.
  • Pourquoi sur certaines boîtes partagées ? Des délégués peuvent planifier des réunions Teams au nom d’une boîte partagée. La présence d’un identifiant SIP facilite alors le routage interne, certains scénarios de compatibilité et les invitations.
  • Recommandation : ne pas supprimer l’adresse SIP. La retirer peut casser des fonctionnalités Teams (présence, invitations de réunion, routage d’appels) et elle sera souvent recréée par les processus de Microsoft 365 si une licence ou un scénario Teams existe.

SPO (SharePoint Online proxy)

  • Rôle : identifiant interne utilisé par SharePoint Online / OneDrive pour des corrélations techniques (provisionnement, synchronisation d’objets, liens de partage, intégrations entre services).
  • Forme habituelle : souvent une chaîne « technique » (parfois proche d’un GUID) qui peut ressembler à SPO:SPO_3fbb0a….
  • Cycle de vie : créée et maintenue automatiquement par les processus Cloud (provisionnement de SPO/OneDrive, évolutions d’objets, etc.).
  • Recommandation : ne jamais modifier ni supprimer l’adresse SPO. C’est un identifiant interne ; le retirer peut perturber des liens SharePoint/OneDrive, et le service le rétablira généralement.

Pourquoi tous les comptes ne l’ont pas ?

  • SIP apparaît lorsque l’objet est provisionné/licencié pour Teams (ou impliqué dans des scénarios de réunions/appels).
  • SPO apparaît quand SharePoint Online / OneDrive est provisionné pour l’objet, ou quand un processus SPO a dû lier l’objet (création d’un site, d’un OneDrive, appartenance à des sites, etc.).
  • En pratique, selon les licences, l’état de provisionnement et l’usage réel, certains objets ont SIP et/ou SPO, d’autres non ; c’est attendu.

Puis‑je supprimer SIP et SPO ?

  • Non recommandé. Ce sont des adresses gérées par les services. Les retirer peut générer des comportements inattendus (Teams/SPO) et sera souvent annulé par une resynchronisation de Microsoft 365.
  • Bon principe : laissez Microsoft 365 gérer SIP et SPO ; n’éditez manuellement que les adresses SMTP selon vos besoins métiers.

Comprendre en profondeur la propriété ProxyAddresses

ProxyAddresses est la collection d’identités utilisées par différents services Microsoft 365 pour joindre un objet. Chaque entrée commence par un préfixe qui indique le protocole ou le service consommateur :

  • SMTP: / smtp: : messagerie Exchange Online (primaire/alias).
  • SIP: : identité signalisation temps réel (Teams).
  • SPO: : identifiant interne SharePoint Online / OneDrive.
  • On peut rencontrer d’autres préfixes (UM:, MSOID:, etc.) selon l’historique et les fonctionnalités.

Bon à savoir : Seule l’entrée SMTP: en majuscules détermine l’adresse primaire d’envoi. Les autres entrées ne sont pas « primaires » ou « secondaires » ; elles sont simplement présentes ou non pour le service concerné.

Exemples de listes ProxyAddresses

SMTP:alice.dupont@contoso.com
smtp:a.dupont@contoso.com
SIP:alice.dupont@contoso.com
SPO:SPO_3fbb0a093c2e4a5c9b...  
SMTP:boite.partagee@contoso.com
smtp:support@contoso.com
SIP:boite.partagee@contoso.com
SPO:SPO_9c1e...  </code></pre>

<h3>Tableau récapitulatif</h3>
<table>
  <thead>
    <tr>
      <th>Préfixe</th>
      <th>Service</th>
      <th>Rôle</th>
      <th>Qui l’ajoute ?</th>
      <th>Peut‑on le modifier ?</th>
      <th>Impact si supprimé</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><strong>SMTP</strong></td>
      <td>Exchange Online</td>
      <td>Adresse primaire d’envoi</td>
      <td>Admin (ou politiques)</td>
      <td>Oui (avec prudence)</td>
      <td>Risque de NDR, perte de réception</td>
    </tr>
    <tr>
      <td>smtp</td>
      <td>Exchange Online</td>
      <td>Alias de messagerie</td>
      <td>Admin (ou politiques)</td>
      <td>Oui</td>
      <td>Perte de réception sur l’alias</td>
    </tr>
    <tr>
      <td><strong>SIP</strong></td>
      <td>Microsoft Teams</td>
      <td>Présence, appels, réunions</td>
      <td>Service (provisionnement)</td>
      <td><strong>Déconseillé</strong></td>
      <td>Présence/Meetings/VoIP dégradés</td>
    </tr>
    <tr>
      <td><strong>SPO</strong></td>
      <td>SharePoint Online / OneDrive</td>
      <td>Identifiant technique interne</td>
      <td>Service (provisionnement)</td>
      <td><strong>Interdit</strong> (ne pas toucher)</td>
      <td>Liens SPO/OD perturbés, recréation forcée</td>
    </tr>
  </tbody>
</table>

<hr />

<h2>Scénarios typiques où SIP et/ou SPO apparaissent</h2>

<h3>Boîte aux lettres utilisateur</h3>
<ul>
  <li><strong>SIP</strong> est ajouté lorsque l’utilisateur est <strong>licencié pour Teams</strong> (ou inclus dans des flux Teams : réunions, appels, délégations).</li>
  <li><strong>SPO</strong> apparaît généralement après la création ou l’activation du <strong>OneDrive</strong> de l’utilisateur, ou lorsqu’il est ajouté à des sites SharePoint.</li>
</ul>

<h3>Boîte aux lettres partagée</h3>
<ul>
  <li>Si des <strong>délégués planifient des réunions Teams</strong> au nom de la boîte, un <strong>SIP</strong> peut être provisionné pour assurer la compatibilité de certaines opérations de calendrier/meeting.</li>
  <li><strong>SPO</strong> peut apparaître si la boîte partagée intervient dans des scénarios liés à SharePoint (par exemple, réception de notifications, appartenance à des sites, automatisations).</li>
</ul>

<h3>Boîtes ressources (salles/équipements)</h3>
<ul>
  <li>Dans des environnements avec équipements Teams Rooms ou des scénarios de réservation intégrés, un <strong>SIP</strong> peut être nécessaire pour la <em>signalisation</em> liée aux réunions.</li>
  <li><strong>SPO</strong> peut être présent selon les intégrations de calendriers et de sites (moins fréquent mais possible).</li>
</ul>

<h3>Groupes Microsoft 365 (Groupes unifiés)</h3>
<ul>
  <li>Ils possèdent toujours des adresses <strong>SMTP</strong>, mais on peut également y voir des entrées <strong>SPO</strong> utilisées par le site SharePoint du groupe.</li>
</ul>

<div style="border-left:4px solid #f59e0b;padding:12px 16px;background:#fff8e6;">
  <strong>Important</strong> : L’absence de SIP et/ou de SPO n’est pas un problème en soi. C’est un <em>indicateur</em> de ce qui a été provisionné/licencié et utilisé. Évitez toute « normalisation » consistant à supprimer ces entrées pour “faire propre”.
</div>

<hr />

<h2>Procédure d’audit : vérifier et interpréter les adresses</h2>

<h3>Vérifier ce que contient ProxyAddresses (lecture seule conseillée)</h3>
<pre><code class="language-powershell"># Voir toutes les adresses (SMTP, SIP, SPO, etc.)
Get-EXORecipient -Identity user@domaine.tld | Select-Object -ExpandProperty EmailAddresses
</code></pre>

<h3>Lister les objets qui possèdent un SIP</h3>
<pre><code class="language-powershell">Get-EXORecipient -ResultSize Unlimited |
  Where-Object { $_.EmailAddresses -match '^SIP:' } |
  Select-Object DisplayName,PrimarySmtpAddress,
                @{n='SIP';e={ ($_.EmailAddresses | Where-Object {$_ -match '^SIP:'}) -join '; '}}
</code></pre>

<h3>Identifier les entrées SPO</h3>
<pre><code class="language-powershell">Get-EXORecipient -ResultSize Unlimited |
  Where-Object { $_.EmailAddresses -match '^SPO:' } |
  Select-Object DisplayName,RecipientTypeDetails,
                @{n='SPO';e={ ($_.EmailAddresses | Where-Object {$_ -match '^SPO:'}) -join '; '}}
</code></pre>

<h3>Repérer les boîtes partagées utilisées pour des réunions Teams</h3>
<pre><code class="language-powershell">Get-EXORecipient -RecipientTypeDetails SharedMailbox -ResultSize Unlimited |
  Where-Object { $_.EmailAddresses -match '^SIP:' } |
  Select DisplayName,PrimarySmtpAddress,
         @{n='SIP';e={ ($_.EmailAddresses | Where-Object {$_ -match '^SIP:'}) -join '; '}}
</code></pre>

<h3>Bonnes pratiques d’administration</h3>
<ul>
  <li>Gérez vos <strong>adresses SMTP</strong> (primaire/alias) selon votre politique de nommage.</li>
  <li><strong>N’éditez pas</strong> les entrées <strong>SIP</strong> et <strong>SPO</strong>. Si un comportement semble anormal, vérifiez :
    <ul>
      <li>Les <strong>licences</strong> (Teams, SharePoint/OneDrive).</li>
      <li>L’<strong>état de provisionnement</strong> (laisser le temps de propagation ; relancer un provisioning si nécessaire).</li>
      <li>Les <strong>délégations</strong> (ex. calendrier d’une boîte partagée utilisé pour planifier des réunions Teams).</li>
    </ul>
  </li>
  <li>Documentez vos flux : qui planifie des réunions <em>au nom de</em> qui ? quels objets disposent d’un OneDrive ou d’un site SharePoint ?</li>
</ul>

<hr />

<h2>FAQ &amp; cas particuliers</h2>

<h3>Une boîte partagée a un SIP alors qu’elle n’a pas de licence Teams : normal ?</h3>
<p>Oui, possible. Un <strong>SIP</strong> peut être généré si la boîte est impliquée dans des scénarios de <em>meetings</em> via des délégués ou des intégrations. Ce SIP aide à assurer le routage et la compatibilité de certaines opérations de réunion. Ne le supprimez pas.</p>

<h3>Je ne veux pas que des utilisateurs « se connectent » à Teams avec une boîte partagée ; le SIP est‑il dangereux ?</h3>
<p>Non. La présence du <strong>SIP</strong> ne rend pas une boîte <em>authentifiable</em> dans Teams comme un compte utilisateur. Elle sert de pointeur interne. Les authentifications restent gouvernées par Azure AD, le type d’objet et la licence.</p>

<h3>Pourquoi certaines boîtes utilisateurs n’ont‑elles aucun SPO ?</h3>
<p>Souvent parce que <strong>OneDrive</strong> n’a pas encore été initialisé (première connexion ou provisionnement déclenché), ou que l’utilisateur n’a pas été impliqué dans des opérations nécessitant la corrélation SharePoint.</p>

<h3>Je peux techniquement supprimer un SIP/SPO avec PowerShell. Dois‑je le faire ?</h3>
<p>Évitez‑le. Même si c’est <em>possible</em> sur le plan technique, vous risquez d’introduire des problèmes transitoires ou permanents. De plus, les processus de Microsoft 365 peuvent <strong>recréer</strong> l’entrée plus tard, rendant l’opération inutile.</p>

<h3>En environnement hybride (AD On‑Prem + AAD Connect), où agir ?</h3>
<p>Dans un environnement hybride, <em>ProxyAddresses</em> est généralement <strong>maîtrisé par l’annuaire local</strong>. Toute modification doit être effectuée <em>on‑premises</em> puis synchronisée vers le Cloud. Là encore, ne retirez pas <strong>SIP</strong> et <strong>SPO</strong>.</p>

<h3>Que se passe‑t‑il si je remplace l’adresse SMTP primaire (majuscule) ?</h3>
<p>Exchange Online mettra à jour l’adresse d’expéditeur par défaut. Les entrées <strong>SIP</strong> et <strong>SPO</strong> ne sont pas automatiquement modifiées ; elles continueront d’exister si le service qui les consomme en a besoin. Adaptez vos alias <code>smtp:</code> si nécessaire.</p>

<hr />

<h2>Guide pas‑à‑pas : audit, interprétation, décisions</h2>

<h3>1) Auditer</h3>
<ol>
  <li>Collectez un export des destinataires avec leurs <em>ProxyAddresses</em> :
    <pre><code class="language-powershell">Get-EXORecipient -ResultSize Unlimited |
  Select-Object DisplayName,RecipientTypeDetails,PrimarySmtpAddress,EmailAddresses |
  Export-Csv .\exo-proxyaddresses.csv -NoTypeInformation -Encoding UTF8

Repérez les entrées SIP: et SPO: et confrontez‑les aux licences et à l’usage (Teams / SharePoint / OneDrive).

2) Interpréter

  • SIP présent : l’objet est ou a été utilisé dans des scénarios temps réel (Teams). Action : laisser en place.
  • SPO présent : l’objet est corrélé côté SharePoint/OneDrive. Action : laisser en place.
  • Absence de SIP/SPO : pas de besoin actuel. Action : ne rien faire.

3) Décider

  • Limiter vos modifications à SMTP et smtp selon les exigences métiers.
  • Éviter toute « mise au carré » consistant à effacer SIP / SPO.
  • Documenter les cas où des boîtes partagées sont utilisées pour planifier des réunions Teams (souvent la source d’un SIP inattendu).

Erreurs fréquentes et signes d’alerte

  • Suppression manuelle d’une entrée SIP : apparition de problèmes de présence Teams, d’organisation de réunions, ou de renvois d’appels. Parfois, l’entrée réapparaît plus tard.
  • Suppression d’une entrée SPO : risques de désynchronisation SharePoint/OneDrive (liens de partage, identités de membres, automatisations). Récréation probable côté service, avec une fenêtre d’incohérence.
  • Confusion casse SMTP : oublier que SMTP: (majuscule) détermine la primaire et que smtp: (minuscule) est un alias.
  • Hybridation non prise en compte : modification dans le Cloud alors que l’attribut maître est on‑premises ; la synchro écrase le changement.

Exemples de commandes utiles

Ajouter un alias SMTP (recommandé)

Set-Mailbox -Identity user@domaine.tld -EmailAddresses @{add='smtp:alias@domaine.tld'}

Changer l’adresse primaire SMTP

Set-Mailbox -Identity user@domaine.tld -PrimarySmtpAddress 'nouveau.primaire@domaine.tld'

Afficher les adresses d’un objet précis

Get-EXORecipient -Identity boite.partagee@domaine.tld |
  Select-Object DisplayName,PrimarySmtpAddress,EmailAddresses |
  Format-List

Astuce : privilégiez toujours un -WhatIf et un export CSV avant toute modification massive. Et ne touchez pas aux entrées SIP et SPO.

Études de cas rapides

Cas A : boîte partagée « Support » avec SIP inattendu

Contexte : l’équipe Support planifie des sessions Teams depuis le calendrier de la boîte partagée. Observation : présence d’un SIP:support@domaine.tld. Décision : laisser en place ; cela contribue au bon fonctionnement des invitations et du routage.

Cas B : utilisateur sans OneDrive et sans SPO

Contexte : compte nouvellement créé, licence M365 sans activation OneDrive. Observation : aucune entrée SPO:. Décision : normal ; la valeur apparaîtra si/et quand OneDrive ou SPO sera provisionné.

Cas C : groupe M365 avec SPO

Contexte : groupe d’équipe associé à un site SharePoint. Observation : une ou plusieurs entrées SPO:. Décision : laisser en place ; elles servent aux corrélations internes du site du groupe.

Bonnes pratiques de gouvernance

  • Standardisez les règles de nommage : définissez comment sont composées les adresses SMTP: et les alias smtp:.
  • Séparez la gestion protocolaire : SMTP (vous), SIP/SPO (services). Cette séparation évite les régressions.
  • Inventoriez les délégués : identifiez les boîtes partagées utilisées pour la planification Teams.
  • Surveillez les licences : un changement de licence peut déclencher la création/suppression logique de besoins côté services.
  • Documentez les exceptions : cas où un SIP existe sans licence directe, ou où un SPO est apparu sans OneDrive activé (processus SPO indirects).

Checklist rapide (à imprimer mentalement)

  • SIP = Teams (présence/appels/réunions) → ne pas supprimer.
  • SPO = identifiant interne SharePoint/OneDrive → ne pas modifier/supprimer.
  • Leur présence dépend des licences, du provisionnement et de l’usage.
  • Ne modifiez manuellement que SMTP / smtp selon vos besoins métiers.

Questions d’examen (auto‑validation)

  1. À quoi sert un SIP: dans ProxyAddresses ? À l’identité temps réel pour Teams.
  2. Doit‑on conserver un SPO: même si on pense ne pas en avoir besoin ? Oui.
  3. La casse a‑t‑elle une signification pour SIP: et SPO: ? Non.
  4. Quelle entrée détermine l’adresse d’expéditeur par défaut ? SMTP: en majuscules.

Conclusion

Dans Exchange Online, SIP et SPO ne sont pas des « alias d’e‑mail » comme les autres : ce sont des identifiants de service. SIP sert la signalisation temps réel dans Microsoft Teams, tandis que SPO relie les objets au tissu SharePoint Online/OneDrive. Leur présence ou absence dépend des licences, du provisionnement et de l’usage. La règle d’or : ne pas les supprimer ; concentrez‑vous sur la gestion des adresses SMTP (primaire/alias). Vous éviterez ainsi les régressions subtiles et les incohérences entre services, tout en gardant un annuaire sain et prévisible.

Résumé opérationnel

  • Ne jamais supprimer SPO:.
  • Éviter de supprimer SIP: (risques Teams).
  • Gérer SMTP:/smtp: selon la stratégie de messagerie.
  • Contrôler les licences et le provisionnement avant toute analyse d’anomalie.
  • En hybride, effectuer les modifications on‑premises sur l’attribut maître.
# Récapitulatif PowerShell utile
# 1) Voir les adresses d'un objet
Get-EXORecipient -Identity user@domaine.tld | Select -Expand EmailAddresses

# 2) Lister les objets avec SIP
Get-EXORecipient -ResultSize Unlimited | ? { $_.EmailAddresses -match '^SIP:' } | Select DisplayName,PrimarySmtpAddress

# 3) Lister les objets avec SPO
Get-EXORecipient -ResultSize Unlimited | ? { $_.EmailAddresses -match '^SPO:' } | Select DisplayName,RecipientTypeDetails

# 4) Ajouter un alias SMTP (OK)
Set-Mailbox -Identity user@domaine.tld -EmailAddresses @{add='smtp:alias@domaine.tld'}

En respectant ces principes, vous laissez Microsoft 365 assurer la cohérence inter‑services et vous concentrez vos efforts là où ils apportent le plus de valeur : la stratégie d’adressage SMTP et l’expérience utilisateur.

Microsoft 365
Sommaire