Skip to main content
Identity Authority
Category: Directory Services

User Principal Name

Also known as: UPN, Internet-style login name
Simply put

A User Principal Name (UPN) is a username written in email address format, combining a user name, the "@" symbol, and a domain name. In Microsoft Active Directory and Microsoft Entra ID environments, it typically serves as the login name that identifies a user when they sign in.

Formal definition

In Windows Active Directory, the UPN is an attribute containing an Internet-style login name for a user, formatted per the RFC 822 (Internet standard) address style as a concatenation of a username, the "@" symbol, and a domain name. It functions as a user identifier used during the identification/authentication step, for example, Microsoft Entra ID uses the UPN to allow users to log in, though the UPN itself is an identifier rather than a credential and does not by itself authenticate the user. Which UPN a user can present typically depends on deployment context, such as whether the associated domain is verified in Microsoft Entra ID.

Why it matters

The UPN is the identifier most users type when they sign in to Microsoft Active Directory and Microsoft Entra ID environments, which makes it a foundational element of the identification step in those ecosystems. Because it is formatted like an email address, it provides a familiar, Internet-style login name that can remain consistent across on-premises and cloud contexts. This consistency matters for administrators managing hybrid deployments, where the UPN often serves as the anchor identifier that ties an on-premises Active Directory account to its Microsoft Entra ID representation.

It is important to keep the UPN in its correct place within an access flow: it is an identifier presented during identification and authentication, not a credential and not an authorization decision. The UPN alone does not authenticate a user or grant any access; it names the principal so that a separate authentication step (verifying a credential such as a password or a passkey) and a subsequent authorization step can proceed. Treating the UPN as if it were secret or as if presenting it constitutes proof of identity is a category error that can lead to flawed assumptions in system design.

Which UPN a user can actually present is not arbitrary, in Microsoft Entra ID it typically depends on deployment context, such as whether the associated domain is verified. This dependency means that UPN planning is a real operational concern during directory synchronization and hybrid identity projects, where a mismatch between an intended UPN suffix and the set of verified domains can prevent users from logging in as expected.

Who it's relevant to

IAM engineers and system administrators
Those operating Microsoft Active Directory and Microsoft Entra ID rely on the UPN as the primary sign-in identifier for users. Understanding that the presentable UPN depends on domain verification is essential when configuring accounts and troubleshooting login failures.
Hybrid identity and directory synchronization teams
For teams synchronizing on-premises Active Directory to Microsoft Entra ID, the UPN often acts as the anchor identifier linking accounts across environments. Ensuring UPN suffixes align with verified domains is a common planning consideration in these projects.
Security architects
Architects designing access flows benefit from placing the UPN correctly as an identifier used during identification and authentication, not as a credential or an authorization mechanism. This distinction informs how sign-in, credential verification, and access decisions are separated in a design.

Inside UPN

Prefix (username portion)
The part of the UPN that appears before the @ symbol, typically representing the user's login name or alias within the identity system.
@ separator
The @ character that divides the prefix from the suffix, giving the UPN its email-address-like, RFC 822-style format.
Suffix (UPN suffix/domain)
The portion following the @ symbol, typically a routable or configured domain name that scopes the identifier to a particular namespace or directory.
Uniqueness scope
The UPN is intended to be unique within its directory or federation namespace, serving as a stable identifier used during the identification and authentication steps of an access flow.

Common questions

Answers to the questions practitioners most commonly ask about UPN.

Is a User Principal Name the same as a user's email address?
Not necessarily, even though they often share the same format (user@domain). A UPN and an email address (typically the mail attribute in a directory) are distinct attributes that can hold different values. Many organizations align them for usability, but a UPN may use a routable domain suffix that differs from the primary SMTP address. Treating them as guaranteed equivalents can cause sign-in failures when they diverge, so verify how each attribute is populated in your specific directory configuration.
Does the UPN identify who a user is for authentication, or does it determine what they can access?
A UPN is an identifier used in the identification and authentication steps, it names the principal presenting credentials, but it does not by itself grant any permissions. Authorization decisions are made separately, typically by evaluating roles, attributes, or policies associated with the account after authentication succeeds. Presenting a valid UPN establishes which account is being authenticated; it says nothing about what that account may do.
How does the UPN relate to the userPrincipalName attribute in an LDAP or Active Directory context?
In directory environments that use it, the UPN is typically stored as the userPrincipalName attribute on the user object and generally must be unique within the directory or forest. Its format is usually a prefix and a UPN suffix separated by an @ symbol. Uniqueness enforcement and which suffixes are permitted depend on directory configuration, so confirm the constraints in your particular deployment before relying on UPN as a lookup key.
What should we consider when choosing UPN suffixes for a hybrid or federated environment?
In many hybrid deployments, the UPN suffix is used to route or match users to a federated identity provider or a synchronized cloud tenant, so suffixes typically need to correspond to verified, routable domains rather than internal-only namespaces (for example .local). Misaligned or non-routable suffixes can break federation and sign-in. Because behavior varies by synchronization tool and identity provider configuration, validate suffix requirements against the specific federation or provisioning setup you use.
How does the UPN appear in tokens issued after authentication?
Depending on the protocol and profile, the UPN or a value derived from it may be surfaced in claims within an ID token, an access token, or a SAML assertion, for example as an upn claim or as part of the subject identifier. The exact claim name and whether the UPN is present at all depend on the identity provider, the requested scopes, and claim-mapping configuration. Do not assume a upn claim exists without confirming it in your issued tokens.
What happens to sign-in if a user's UPN changes, such as after a name change or domain migration?
Changing a UPN typically changes the identifier a user signs in with, and it can affect downstream systems that cached or matched on the prior UPN value. Some services key account matching on an immutable identifier rather than the UPN precisely to avoid breakage on such changes, while others may rely on the UPN directly. Because the impact depends on how each connected system performs account matching and provisioning, assess the change against your directory synchronization, federation, and application configurations before renaming.

Common misconceptions

A UPN is the same thing as the user's email address because it looks like one.
Although a UPN uses an email-like format with a prefix, @ separator, and domain suffix, it is a directory login identifier and does not necessarily match a user's actual email address. In many deployments the UPN suffix and the mail domain differ, depending on configuration.
Presenting a valid UPN authenticates the user.
A UPN is an identifier used in the identification step; it names the principal but does not verify identity. Authentication still requires a separate step in which the principal proves possession, knowledge, or inherence factors.
A UPN determines what resources a user can access.
A UPN identifies the principal but does not by itself convey permissions. Authorization is a distinct step, typically evaluated by access control models and enforcement points separate from the identifier used to name the user.

Best practices

Keep the UPN unique within its namespace and avoid reusing a retired UPN for a different principal, to prevent identity collisions across the directory or federation.
Decide deliberately whether UPN suffixes should match your mail domains; document the choice so operators do not incorrectly assume the UPN equals the email address.
Use routable, verified domain suffixes where the UPN participates in federation, so the identifier resolves consistently across trusting parties.
Treat the UPN as an identification value only, and ensure authentication and authorization remain separate, explicitly enforced steps in your access flows.
Establish a governed process for UPN changes (for example on name changes or domain migrations) so downstream systems relying on the identifier stay consistent.
Validate UPN formatting and namespace rules at provisioning time to catch malformed or out-of-namespace identifiers before they reach runtime.
Promotional banner highlighting failures found in PCI audits and how to spot the gaps