Domainless SAML Federation in Entra External ID

External SAML federation no longer needs the user's email domain to match a preconfigured IdP domain — which quietly kills a whole category of 'why can't this partner sign in' tickets.

What's new — a short, independent summary. Read Microsoft's original: Microsoft Learn →

SAML federation for external users used to carry an assumption that didn’t survive contact with the real world: that a user’s email domain matched the identity provider you’d federated with. Fine in theory. In practice, partners use shared mailboxes, vanity domains, aliases, and personal-looking addresses that route to corporate IdPs — and every mismatch was a sign-in that failed for reasons nobody could see.

What domainless federation changes

Domainless SAML federation removes the requirement for domain matching between the user’s email and the preconfigured IdP domains, during both sign-in and invitation redemption. The user authenticates against their IdP-managed credentials regardless of what their email domain says.

Why it’s more useful than it sounds

The old model turned onboarding a partner into a domain-mapping exercise: enumerate every domain they might sign in from, configure each one, and still get caught out by the address you didn’t know about. Domainless federation collapses that into “federate with the IdP, done” — the domain stops being the thing that has to line up.

If you run any kind of B2B collaboration with federated partners, this removes a recurring, hard-to-diagnose failure mode. The user who “definitely has an account but can’t get in” was very often a domain that didn’t match a mapping nobody remembered creating.

Source: Microsoft Learn. Summarised independently — check the source for the latest detail.