Microsoft 365 tenant vs Outlook.com: what your integration can and can't do

“Sign in with Microsoft” covers two very different kinds of account, and the difference decides whether your Microsoft integration can work at all.

• Personal Microsoft accounts (often called MSAs): Outlook.com, Hotmail, Live, Xbox, and personal accounts created with any email address.
• Work or school accounts: identities in a Microsoft Entra ID tenant (formerly Azure AD), which is what a company gets with Microsoft 365.

This post covers what each can do with your app, how to tell them apart at sign-in, and how to tell before sign-in, from nothing but an email domain.

What each account type can do

Capability	Work account (Entra ID tenant)	Personal Microsoft account
Sign in to your app	Yes	Yes, if your app allows personal accounts
Read the user’s own mail, calendar, files via delegated Graph permissions	Yes	Partly: Graph supports personal accounts for some APIs, such as Outlook mail, calendar and personal OneDrive
Admin consent for the whole organization	Yes, by an admin	No organization to consent for
Application (app-only) permissions	Yes, after admin consent	No
SharePoint Online sites	Yes	No
OneDrive for Business	Yes	No (personal OneDrive is a different service)
Teams organizational data (teams, channels)	Yes	No organizational tenant
Users, groups, org structure from the directory	Yes	No

If your product syncs a company’s SharePoint, reads Teams channels, or runs a background job with application permissions, a personal account can’t make it work. Not with a setting, not with a workaround. The user needs their work account and, usually, an admin.

Telling them apart at sign-in

When a user signs in through the Microsoft identity platform, you can control and inspect which kind of account it is.

Choose the right authority. The endpoint you sign users in with decides which accounts are allowed:

Authority	Accepts
/common	Work accounts and personal accounts
/organizations	Work and school accounts only
/consumers	Personal accounts only
/{tenant-id}	Only that tenant’s accounts

If your product needs a tenant, /organizations stops personal accounts at the door, with Microsoft’s own error page. That’s effective, but it’s a blunt experience for someone who just clicked the wrong account.

Check the tid claim. Every ID token carries tid, the tenant the account belongs to. Personal Microsoft accounts all report the same, well-known consumer tenant ID, 9188040d-6c67-4c5b-b112-36a304b66dad. Anything else is an organization’s tenant.

Don’t key users on the email claim. In multi-tenant apps, the email claim isn’t a safe identifier on its own (this was the “nOAuth” class of account-takeover issues). Key accounts on tid + oid, and treat the email as a property that needs verification.

Telling them apart before sign-in

Often you only have an email address: on a signup form, in a CRM, on a trial request. The company domain still tells you a lot.

Microsoft’s public discovery document

Every Entra ID tenant publishes an OpenID Connect discovery document, and Microsoft resolves it by domain name:

curl -s https://login.microsoftonline.com/contoso.example/v2.0/.well-known/openid-configuration \
  | jq '{issuer, tenant_region_scope, cloud_instance_name}'

For a domain that belongs to a tenant, the response includes the tenant ID inside URLs such as issuer (illustrative):

{
  "issuer": "https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/v2.0",
  "tenant_region_scope": "EU",
  "cloud_instance_name": "microsoftonline.com"
}

For a domain that isn’t verified in any tenant, you get an error instead. This is a documented, public endpoint about the organization. It doesn’t reveal anything about any individual user.

MX records

Exchange Online and consumer Outlook.com use different mail hosts:

Service	MX looks like
Exchange Online (Microsoft 365)	acme-io.mail.protection.outlook.com
Consumer Outlook.com / Hotmail	*.olc.protection.outlook.com

Microsoft has also introduced newer MX hostnames under mx.microsoft for domains using DNSSEC and DANE, so match patterns rather than exact strings. The MX lookup lists a domain’s hosts by priority and names the provider behind each.

Other DNS breadcrumbs

• TXT MS=ms12345678: Microsoft 365 domain verification
• autodiscover, enterpriseregistration, enterpriseenrollment and lyncdiscover records
• SPF include:spf.protection.outlook.com

None of these are needed when discovery finds a tenant, but they help in odd setups. For example, they distinguish “tenant exists but mail is on Google” from “tenant runs everything”.

Managed vs federated

A tenant either handles passwords itself (managed) or redirects sign-in to another identity provider (federated): Okta, ADFS, Ping and others. Microsoft’s home-realm discovery, which its own login page uses to decide where to send you, reveals which. You can query it with a placeholder username on the domain; you never need the real user’s address.

Federation matters for onboarding. The person who can grant admin consent may sit in an IT or identity team. Some tenants bought through resellers or hosting providers are federated to the reseller’s sign-in, which can make admin tasks awkward for the customer. Knowing this upfront lets you show “Send this link to your IT admin” instead of a dead end.

Pitfalls

• A tenant isn’t a license. The domain having a tenant doesn’t mean this user has Microsoft 365, or the specific service you integrate with.
• A tenant isn’t an admin. Some tenants were created automatically through self-service sign-ups and have no active administrator. Admin consent there can be hard or impossible until someone takes ownership.
• Same address, two accounts. Someone can have a personal Microsoft account and a work account with the same email address. The domain’s tenant tells you what’s possible; tid at sign-in tells you which account they actually used.
• Mixed suites. Entra ID for identity and Google for mail (or the reverse) is common. Check for both.

Putting it into an onboarding flow

1. At signup, classify the domain. If it’s a personal provider and your product needs a tenant, say so now, not at the connect step (how to require a work email at sign-up).
2. On the connect screen, pre-select the Microsoft connector when a tenant is detected.
3. For admin consent, build the consent URL with the tenant ID, so the admin lands on the right organization:

https://login.microsoftonline.com/{tenant_id}/v2.0/adminconsent
  ?client_id={app_id}&scope=https://graph.microsoft.com/.default
  &redirect_uri={redirect_uri}&state={state}

4. At sign-in, verify tid isn’t the consumer tenant before you start syncing.

One API call

isBusinessEmail does the discovery, MX and DNS checks, home-realm lookup and caching for you, and returns it per domain (how detection works):

curl -sG https://api.isbusinessemail.com/v1/check \
  --data-urlencode "email=m365@test.isbusinessemail.com"

Look at workspace.microsoft_365 (detected, tenant_id, tenant_region, auth, identity_provider) and integrations.microsoft_365_ready, described in Response fields. The m365@ test address needs no key and returns a federated tenant with a placeholder tenant ID. Try any domain with the Microsoft tenant lookup, and see the onboarding use case for the full flow.