SIP e SPO sono due indirizzi “nascosti” ma fondamentali in Microsoft 365: il primo abilita autenticazione, instradamento e presenza in Microsoft Teams; il secondo è un identificatore interno usato da SharePoint Online. Capire come funzionano evita incidenti e ore di troubleshooting.
Che cosa sono gli indirizzi SIP e SPO
Nel mondo Microsoft 365 ogni oggetto abilitato alla posta o alle funzionalità collaborative (utenti, cassette postali, risorse, talvolta gruppi) possiede una collezione di proxy addresses archiviati nell’attributo proxyAddresses. Tra questi, oltre agli alias SMTP, compaiono anche altri “prefissi” che svolgono ruoli specifici per i vari servizi cloud. SIP e SPO sono due di questi.
| Tipo | Scopo principale | Formato tipico | Chi li genera |
|---|---|---|---|
| SIP | Autenticazione e instradamento delle chiamate/riunioni di Microsoft Teams (in passato Skype for Business) e visualizzazione dello stato di presenza. | SIP:nome@dominio (normalmente coincide con l’SMTP primario). | Creato automaticamente da Exchange Online/Azure AD quando l’oggetto deve poter partecipare a funzioni di comunicazione in tempo reale. |
| SPO | Proxy address interno usato da SharePoint Online per identificare un utente o una cassetta postale nei processi di People Picker, profilo utente, condivisione e ricerca. | SPO:<stringa casuale>@<tenant>.onmicrosoft.com (stringa alfanumerica o GUID). | Generato da processi di back‑end di Microsoft 365; non è destinato all’uso interattivo. |
Nota terminologica. A differenza di SMTP:/smtp: dove il maiuscolo indica l’indirizzo primario, per SIP: e SPO: non esiste il concetto di “primario”: sono valori funzionali e non rappresentano un alias e‑mail.
Perché non compaiono su tutti gli oggetti
Gli indirizzi SIP e SPO non sono obbligatori per definizione: vengono creati on‑demand quando il relativo servizio ne ha bisogno. Di seguito le logiche più comuni.
SIP
- È aggiunto solo quando l’oggetto (utente, gruppo idoneo, cassetta condivisa, account risorsa) è abilitato o potrebbe dover essere abilitato per Teams.
- Le cassette postali condivise possono riceverlo se:
- sono state convertite da utenti che avevano licenza Teams, oppure
- hanno delegati che pianificano riunioni Teams a loro nome (ad esempio l’assistente che invia inviti dal calendario della shared mailbox).
- Gli account risorsa usati per stanze/attrezzature o per Auto Attendant/Call Queue in Teams in genere hanno un SIP, anche se non sono “utenti” tradizionali.
SPO
- Viene creato dinamicamente dall’infrastruttura SharePoint quando l’oggetto interagisce con SharePoint (accesso a un sito, assegnazione di permessi, sincronizzazione del profilo utente, creazione/gestione di una OneDrive, partecipazione a un Team collegato a SharePoint, ecc.).
- Se l’oggetto non ha mai “toccato” SharePoint, l’indirizzo potrebbe non esistere ancora. Questo è normale e non indica errori.
Come riconoscerli e dove vederli
Gli indirizzi SIP e SPO vivono insieme agli alias SMTP nell’insieme Email addresses dell’oggetto. Esistono diversi modi per ispezionarli.
Interfaccia amministrativa
- Exchange admin center (EAC) → Recipients > Mailboxes → seleziona la cassetta → Email addresses: qui vedrai
SMTP:, eventualismtp:secondari, e – se presenti –SIP:eSPO:. - Microsoft 365 admin center mostra principalmente gli alias SMTP: per l’elenco completo dei proxy addresses, EAC resta la vista più affidabile.
PowerShell (consigliato per inventario)
Esempi pratici in Exchange Online PowerShell per estrarre rapidamente SIP/SPO.
# Connessione
Connect-ExchangeOnline
Visualizza gli indirizzi di un utente specifico
Get-Recipient -Identity "[nome.cognome@contoso.com](mailto:nome.cognome@contoso.com)" |
Select-Object Name,PrimarySmtpAddress,
@{Name='SIP';Expression={($.EmailAddresses | Where-Object {$ -like 'SIP:*'}) -join ';'}},
@{Name='SPO';Expression={($.EmailAddresses | Where-Object {$ -like 'SPO:*'}) -join ';'}}
Esporta l’inventario di tutti i destinatari abilitati alla posta
Get-Recipient -ResultSize Unlimited |
Select-Object Name,RecipientTypeDetails,PrimarySmtpAddress,
@{Name='SIP';Expression={($.EmailAddresses | ? {$ -like 'SIP:*'}) -join ';'}},
@{Name='SPO';Expression={($.EmailAddresses | ? {$ -like 'SPO:*'}) -join ';'}} |
Export-Csv .\ProxyAddressesSIPSPO.csv -NoTypeInformation -Encoding UTF8 Ambienti ibridi
Se sincronizzi gli oggetti da Active Directory on‑premises (Entra Connect), ricorda che l’attributo proxyAddresses è governato on‑prem. Aggiunte/eliminazioni fatte solo nel cloud verranno sovrascritte dalla successiva sincronizzazione. In ogni caso, non rimuovere manualmente SIP/SPO (vedi sezione successiva).
Posso eliminare SIP o SPO?
In breve: no. Sono indirizzi gestiti dai servizi. Rimuoverli tende a rompere flussi critici e spesso vengono ricreati automaticamente – talvolta con valori diversi – generando inconsistenze.
| Indirizzo | È consigliabile eliminarlo? | Possibili conseguenze |
|---|---|---|
| SIP | No. | Teams non riuscirà ad autenticare l’utente/la cassetta; potrebbero fallire chiamate, riunioni, deleghe o visualizzazione presenza. |
| SPO | Assolutamente no. | Interruzione di processi SharePoint/OneDrive (People Picker, profili, condivisione, ricerca); rigenerazione automatica con potenziali problemi di sincronizzazione. |
Best practice: lasciare che Microsoft 365 gestisca autonomamente gli indirizzi proxy. L’unico caso in cui si interviene manualmente è per aggiungere o modificare alias SMTP; SIP e SPO non vanno toccati.
Esempi e casi d’uso reali
Utente con Teams
Un utente con licenza per Teams riceve un indirizzo SIP: che, nella maggior parte dei casi, coincide con la sua e‑mail primaria (SMTP:). Questo consente a Teams di risolvere presenza, chat, riunioni e chiamate. Se l’utente non usa mai SharePoint/OneDrive, è normale non vedere alcun SPO:.
Shared mailbox con delega
Una cassetta condivisa a cui diversi assistenti hanno accesso di Send As e Full Access può ricevere SIP: quando gli assistenti pianificano riunioni Teams “da” quella casella. Senza il SIP alcune integrazioni di calendario/riunione falliscono o non mostrano correttamente lo stato di presenza nel contesto degli inviti.
Account risorsa per Sale Riunioni
Le sale riunioni e le attrezzature usate nei calendari Teams ottengono tipicamente un SIP: così che l’oggetto possa essere invitato e gestito dalle policy di Teams Rooms/Calling. Lo SPO: può apparire quando la sala viene mappata a un sito SharePoint per file o quando un Team utilizza quella sala in modo esteso.
Oggetti mai entrati in SharePoint
Utenti di sola posta o account di servizio che non accedono a siti/OneDrive spesso non hanno SPO:. Non c’è nulla da “sistemare”: SharePoint lo genererà quando servirà.
Domande frequenti (FAQ)
Il SIP è uguale all’UPN o all’SMTP?
Spesso sì, ma non è una regola rigida. In tenant con più domini, l’indirizzo SIP: deve appartenere a un dominio accettato per Teams. Per alcuni account (ad esempio risorse) può usare il dominio onmicrosoft.com. Evita di forzare allineamenti manuali. Gli indirizzi SIP/SPO sono indirizzi e‑mail validi?
No. Sono proxy addresses tecnici. In genere la posta non viene recapitata a SIP: o SPO:; il trasporto e‑mail usa SMTP:/smtp:. Posso cambiarli manualmente?
Sconsigliato. Le modifiche manuali possono disallineare la configurazione tra servizi (Teams, Exchange, SharePoint) e creare problemi difficili da diagnosticare. Lascia che i servizi li mantengano. Le distribuzioni o i gruppi Microsoft 365 hanno un SIP?
Di norma i gruppi abilitati alla posta non richiedono SIP:. Gli indirizzi SIP sono tipici di utenti, shared/resource mailboxes e account usati da funzionalità di comunicazione in tempo reale. Se un oggetto non partecipa a chiamate/riunioni/presenza, non avrà un SIP. SPO viene creato anche per gli utenti esterni (Guest)?
Gli utenti guest B2B non hanno una cassetta postale in Exchange Online e non seguono le stesse regole dei mailbox‑enabled recipients. SharePoint gestisce identità e mapping dei guest con logiche dedicate; non aspettarti un SPO: nel loro proxyAddresses come per gli utenti interni. Che differenza c’è tra proxyAddresses e mail?
mail è un singolo valore informativo (spesso la posta primaria). proxyAddresses è una collezione multivalore che contiene tutti gli alias/identificatori (SMTP, SIP, SPO, X500, ecc.). Le maiuscole hanno significato?
Solo per SMTP: SMTP: indica l’indirizzo primario, smtp: un alias secondario. Per SIP: e SPO: il case non distingue priorità.
Buone pratiche di gestione
- Non rimuovere né modificare
SIP:eSPO:. Se qualcosa “non torna”, indaga la causa applicativa (licenze, policy, sincronizzazione), non intervenire sugli indirizzi. - Gestisci gli alias SMTP dove previsto: in cloud per oggetti nativi cloud, on‑prem per oggetti sincronizzati. Mantieni coerenti UPN, SMTP primario e domini di appartenenza ma senza forzare SIP/SPO.
- Automatizza verifiche periodiche (reporting) per individuare outlier:
- utenti con licenza Teams ma privi di
SIP:(in genere transitorio o licenza assegnata da poco); - shared/resource mailboxes con deleghe di calendario ma senza
SIP:; - utenti heavy‑SharePoint privi di
SPO:(può indicare che non hanno mai effettuato il primo accesso).
- utenti con licenza Teams ma privi di
- Documenta eccezioni note (ad esempio account di servizio senza accesso a SharePoint) per evitare false segnalazioni.
Troubleshooting mirato
Teams: presenza o riunioni non funzionano
- Verifica che l’utente sia licenziato per Teams e che il dominio dell’indirizzo SIP sia un dominio accettato nel tenant.
- Controlla lo state del servizio Teams e le policy applicate all’utente (Calling/Meeting/Voice). Se si tratta di cassetta condivisa o risorsa, conferma il tipo di account previsto dal modello di licenza.
- Ispeziona gli indirizzi:
Get-Recipient -Identity utente@contoso.com | Select -ExpandProperty EmailAddressesAccertati che esista unSIP:coerente con le aspettative.
SharePoint: People Picker o profili “impallati”
- Conferma che l’utente abbia effettuato almeno un accesso a SharePoint/OneDrive o che sia stato invitato/assegnato a un sito.
- Controlla la presenza dell’indirizzo
SPO::Get-Recipient -Identity utente@contoso.com | % EmailAddresses | ? {$_ -like 'SPO:*'}L’assenza non è un problema se l’utente non ha mai interagito con SharePoint; in caso contrario potrebbe indicare che i processi di provisioning non si sono completati. - Evita “pulizie” manuali degli indirizzi: SharePoint può rigenerare
SPO:con un valore diverso, causando duplicati logici o disallineamenti nei profili.
Ambienti ibridi e sovrascritture inattese
- Se usi sincronizzazione directory, gestisci gli indirizzi a valle dell’origine (on‑prem). Le modifiche fatte solo nel cloud verranno annullate.
- Verifica che regole e script on‑prem (ad es. processi di provisioning) non stiano rimuovendo prefissi non‑SMTP per “ripulire” gli oggetti.
Linee guida durante migrazioni e cambi dominio
Quando cambi domini o migri oggetti tra tenant, le tentazioni di “forzare” gli indirizzi sono forti. Ecco come evitare danni:
- Non rinominare manualmente il
SIP:per farlo combaciare a un nuovo SMTP/UPN: lascia che Teams aggiorni i mapping in base alle policy e licenze. - Non toccare
SPO:: SharePoint ricrea i mapping interni durante il provisioning nel nuovo tenant o dopo il primo accesso. - Conserva gli alias SMTP storici quando possibile: aiutano il recapito post‑migrazione ma sono indipendenti da SIP/SPO.
Modello decisionale rapido
| Situzione | Che cosa aspettarsi | Azione consigliata |
|---|---|---|
| Nuovo utente con licenza Teams | Presenza di SIP:; SPO: solo dopo uso di SharePoint/OneDrive | Nessuna azione: monitorare e non modificare manualmente |
| Shared mailbox usata per inviti Teams | Può comparire SIP: | Lasciare che il servizio gestisca gli indirizzi; evitare rimozioni |
| Utente che non usa SharePoint | Nessun SPO: | Nessuna azione necessaria |
| Ambiente ibrido con script di hardening | Possibili rimozioni accidentali di SIP:/SPO: | Escludere SIP:/SPO: da qualsiasi routine di “pulizia” |
Checklist operativa per amministratori
- Prima di intervenire: chiarisci quale servizio è impattato (Teams o SharePoint) e quale sintomo osservi (riunioni, presence, condivisione, People Picker, profili).
- Osserva, non toccare: verifica gli indirizzi con EAC/PowerShell. Se mancano, verifica licenze, domini e policy; evita modifiche manuali agli indirizzi.
- Automatizza il controllo: mantieni uno script di inventario periodico che esporti SIP/SPO per oggetti critici (utenti C‑level, sale riunioni, shared mailboxes centrali).
- Documenta: registra eccezioni e casi speciali per il tuo tenant (ad esempio sale “offline” o account senza SharePoint per policy di sicurezza).
- In ibrido: applica ogni variazione all’origine (on‑prem) e rimuovi job che eliminano prefissi non‑SMTP.
Errori comuni da evitare
- Eliminare SIP/SPO per “fare pulizia”: sembra innocuo, ma può interrompere presence, scheduling e risoluzioni utenti.
- Uniformare forzosamente SIP a SMTP/UPN: non è necessario e può violare regole di dominio per Teams.
- Considerare SPO un alias e‑mail: non lo è; non inviare posta a
SPO:. - Ignorare l’ibrido: modifiche in cloud su oggetti sincronizzati vengono sovrascritte; potresti perdere traccia di cosa sia successo.
Riepilogo operativo
- SIP = telefonia/presenza Teams.
- SPO = identificatore interno SharePoint Online.
- Entrambi sono creati in base alle necessità del servizio; l’assenza su un account è normale finché quel servizio non viene invocato.
- Non eliminare né modificare questi indirizzi: potrebbero rompersi funzionalità critiche.
Appendice: script di verifica rapida
Per un controllo spot di un set di caselle strategiche:
$targets = @(
"direzione@contoso.com",
"segreteria@contoso.com",
"sala-riunioni-1@contoso.com",
"it-support@contoso.com"
)
$report = foreach($t in $targets){
$r = Get-Recipient -Identity $t -ErrorAction SilentlyContinue
if(-not $r){ [pscustomobject]@{ Identity=$t; Found=$false; SIP=$null; SPO=$null; Note="Recipient not found" } ; continue }
$sip = ($r.EmailAddresses | ? {$_ -like "SIP:*"}) -join ";"
$spo = ($r.EmailAddresses | ? {$_ -like "SPO:*"}) -join ";"
[pscustomobject]@{
Identity = $t
Found = $true
SIP = $sip
SPO = $spo
Note = if($sip -and $spo){"OK"} elseif($sip){ "No SPO (non ancora usato in SharePoint?)" } elseif($spo){ "No SIP (non abilitato per Teams?)" } else { "Nessuno dei due (verificare esigenze)" }
}
}
$report | Format-Table -AutoSize Integra lo script nei tuoi controlli periodici e annota i motivi per cui un oggetto non necessita di SIP/SPO, così da evitare falsi positivi in audit successivi.
In conclusione, gli indirizzi SIP: e SPO: sono “ingranaggi” di basso livello che abilitano rispettivamente la collaborazione in tempo reale di Teams e i processi identitari di SharePoint. Non sono alias e‑mail, non sono pensati per essere gestiti manualmente e compaiono solo quando servono. Trattarli come parte dell’infrastruttura – e non come campi da “ripulire” – è la scelta più sicura per mantenere stabile il tuo ambiente Microsoft 365.