Teams Login explanations (UPN vs. E-Mail vs. SIP address)

I’ll explain how Microsoft Teams handles SIP addresses, logins, and identities in a hybrid Exchange environment where the user's Primary SMTP and UPN differ.

I'll detail how Teams handles login with UPN, what role the Primary SMTP plays, how SIP addresses are resolved and used (including how this has changed over time), and what happens if the SIP entry is missing from proxy addresses in hybrid identity scenarios.

Teams Sign-in Identity (UPN vs Email)

Teams uses Azure AD for authentication, so users sign in with their Azure AD User Principal Name (UPN) (even if the UI says “enter email”). In practice you enter the UPN (or sometimes just the username portion) and password. For example, if your UPN is user@contoso.com, you log in as user@contoso.com (or just user on domain-less clients). The primary SMTP address (your email) is not used for login by default. (If UPN ≠ SMTP, the user still must use the UPN unless you set up Azure AD’s alternate login ID feature.) Microsoft recommends aligning the UPN with the user’s email/SIP address wherever possible, because having UPN = email/SIP avoids confusion. In short, Teams sign-in expects the Azure AD UPN (not necessarily the primary SMTP), and the UPN is typically what is synced from on-prem AD into Azure AD.

SIP Address Derivation and Usage in Teams

Each Teams user has a SIP (Session Initiation Protocol) address – essentially a URI like sip:user@domain.com – used as their identity for voice, video, IM, presence and federation. In a hybrid environment, the SIP address comes from directory attributes and licensing:

• ProxyAddresses / msRTCSIP: On-premises, a user’s SIP address was stored as msRTCSIP-PrimaryUserAddress (or equivalently as a SIP: entry in proxyAddresses). Azure AD Connect syncs the on-prem msRTCSIP-PrimaryUserAddress and all proxy addresses to Azure AD. Teams (and Skype for Business) will use that SIP URI as the contact address. If no SIP is set on-prem, a SIP entry can still be created in the cloud.
• License-driven creation: In cloud-managed or hybrid users, assigning a Teams (or Skype for Business) license causes Exchange Online to automatically add a SIP: proxy address for the user. In practice, Exchange Online typically makes the SIP address match the UPN (e.g. if UPN is user@contoso.com, it creates SIP:user@contoso.com). This SIP address is what Teams uses for real-time communication (calls and presence).
• Use in presence/calling/federation: The user’s SIP URI is the identity used in Teams for presence and voice. For example, when you call or chat with an external Teams user, Teams routes via that user’s SIP address. (Federation/External Access works by SIP or email address of the other user.) The SIP address is also what Outlook and other clients use to show presence.. Only one SIP address can be primary (only one SIP: entry is allowed).

In summary, Teams derives the SIP identity from Azure AD attributes: either the synced msRTCSIP or a sip: proxy address. If neither existed on-prem, the Teams license will trigger creation of a default SIP (usually the UPN). Teams then uses that SIP URI for presence, calling and federation.

Historical vs Current Handling of SIP: in ProxyAddresses

Historically (in Skype for Business/Lync Hybrid scenarios), the on-prem msRTCSIP-PrimaryUserAddress was the authoritative SIP. If an on-prem SIP existed, that value was synced to Azure and used in Skype/Teams. In that model, any SIP: entry in the Exchange proxyAddresses was essentially redundant: Office 365 would ignore the proxy SIP: if msRTCSIP was present. In other words, Skype Online always used the msRTCSIP attribute.

In contrast, in a Teams-only environment (no Skype hybrid), Microsoft now expects the Azure AD UPN to be the user’s chat identity. After a user is moved to Teams-only, Teams no longer requires or uses the old msRTCSIP value. Microsoft’s guidance is that you can remove the on-prem msRTCSIP-PrimaryUserAddress once you’re in full Teams mode. Instead, Teams will effectively use the user’s UPN/SIP (from Azure) as the chat address.

However, to maintain certain integrations, Microsoft recommends keeping a sip: proxyAddresses entry. The support answer notes that if you delete msRTCSIP, you should populate the proxyAddresses with a SIP: entry (for example, the same address as the UPN). This is because some clients (like Outlook) look at the SIP: proxy address for presence. In practice today, Teams will use whatever SIP address is in Azure AD (from on-prem sync or from Exchange Online). If that is missing, Exchange Online’s license-driven process will create one.

To summarize: Historically, Skype for Business Hybrid prioritized msRTCSIP. Now, Teams relies on the Azure AD UPN and any existing SIP: proxy address. If you clear out the old Skype attributes, ensure a sip: entry exists in proxyAddresses to avoid breaking presence.

Exchange Hybrid and Attribute Synchronization

In a hybrid Exchange + AD Connect environment, the on-premises AD and Exchange remain authoritative for user addresses. Azure AD Connect synchronizes key attributes (UPN, mail, proxyAddresses, etc.) from on-prem AD to Azure AD. This means:

• The userPrincipalName (login) and mail (primary SMTP) flow from AD to Azure AD. Teams signs in on the UPN, and Exchange Online uses the mail for email routing.
• The proxyAddresses (SMTP aliases and any SIP: or SPO: entries) also sync to Azure AD. Exchange Online will show and use these addresses for email and SIP. In fact, the Exchange Online mailbox can add its own SIP entries (and SPO entries for SharePoint) even if none existed on-prem, once the mailbox is in the cloud.

Thus, in a hybrid setup, if you need to set or change the SIP identity, you typically do it on-prem (e.g. setting msRTCSIP-PrimaryUserAddress or adding SIP: in proxyAddresses) and let AAD Connect carry it to Azure. Conversely, you can manage the mailbox in Exchange Online (for example, let the Teams license add the SIP proxy) and those values will propagate back into Azure AD attributes. The key point is that Azure AD (and thereby Teams) will always see the current proxyAddresses for the user (from whatever source).

If you transition fully to cloud-managed, you remove the on-prem Skype attributes and rely on the cloud. In that case, Exchange Online will handle SIP. But in any hybrid scenario, AAD Connect ensures the SIP addresses (and UPN) remain in sync.

Azure AD, Skype (SfBO), and Teams Dependencies

Azure AD is the central store of identities in Office 365/Teams. It holds the UPN and all proxy addresses (SMTP, SIP, etc.) for each user. Teams (and previously Skype for Business Online) use the Azure AD identity to authenticate users and to resolve their contact SIP URIs.

Historically, Skype for Business Online relied on those SIP addresses (and required a Skype license) for federation. In earlier times it was even noted that an SfB license was needed to provision a SipProxyAddress for external access. Today, Skype Online has been retired, and Teams has taken over those functions. Now, a Teams license is enough to ensure a SIP address exists.

In practical terms: Teams authentication does not depend on any SfB Online object; it uses the same Azure AD user. Federation (External Access) is done by SIP or email (the contact must have a Teams/SfB identity in Azure AD). The Global Address List still shows users by SMTP email, but the Teams client will use the SIP address (often the UPN) to chat or call. Thus, if UPN and SMTP differ, Teams internally uses the UPN/SIP for the session, though users see each other’s display names or email in the UI.

In summary, Azure AD provides the user’s UPN and proxyAddresses (including SIP) for Teams. Skype for Business Online (legacy) used the same source but required its own license in the past. Teams now uses these attributes directly (UPN for login and as default SIP, and sip: proxy entries for calling). The transition over time has moved from on-prem Skype attributes to cloud-based Teams attributes, but the dependency on Azure AD as the identity source remains constant.

References: Microsoft documentation and community answers describe how Teams sign-in and SIP addresses work. For example, Teams sign-in uses the Azure AD UPN; Teams licenses trigger creation of SIP proxy addresses; and after moving to Teams-only, the on-prem msRTCSIP can be dropped (with a SIP: proxy address used instead). These behaviors are consistent in hybrid Exchange+Azure AD setups.