Managing external identities to enable secure access for partners, customers, and other non-employees
The successful invitation to another domain shows that the app-only User.Invite.All flow is operational; use a real, controlled recipient domain for testing because Microsoft does not document example.com as a supported or specially blocked Entra B2B domain.
example.com is a reserved example namespace intended for documentation, not a normal production mail domain. However, the available Microsoft Entra documentation does not state that the invitation API deliberately rejects reserved example domains. Therefore, the observed result should not be treated as a documented Entra rule.
What the successful test establishes
For app-only calls, User.Invite.All is the least-privileged application permission for POST /invitations. A successful request should return 201 Created and create a guest user in PendingAcceptance state. Application permissions still cannot override a tenant-wide setting that disables B2B invitations. ^1^
Because ******@xyzabcdefghi.com succeeds:
- The application credential and Graph permission are sufficient.
- Guest invitations are not disabled tenant-wide.
- The failure is recipient/domain-specific rather than a general inviter-role problem.
- Changing Guest invite settings from admin-only to members-and-admins was not required to establish app-only access. Those choices define which organizational users can invite; app-only authorization is governed by the application permission and the tenant-wide invitation state. ^2^
Test with a usable address
Run the same request against an actual mailbox on a domain you control:
POST https://graph.microsoft.com/v1.0/invitations
Authorization: Bearer <app-only-token>
Content-Type: application/json
{
"invitedUserEmailAddress": "[Email]",
"inviteRedirectUrl": "https://myapp.contoso.com",
"sendInvitationMessage": false
}
With sendInvitationMessage: false, inspect the returned inviteRedeemUrl rather than relying on email delivery. The invitation API supports returning this URL so the application can deliver it through another mechanism. ^1^
Expected result:
- HTTP
201 Created - A guest object is created
- Invitation status is
PendingAcceptance - The response contains
inviteRedeemUrl
If a real domain also fails
Check only the controls that can produce domain-specific behavior:
- Go to Microsoft Entra admin center → Entra ID → External Identities → External collaboration settings.
- Under Collaboration restrictions, verify that the effective mode is Allow invitations to be sent to any domain, or that the recipient domain is not denied.
- Go to External Identities → Cross-tenant access settings and inspect the default configuration and any organization-specific entry for the recipient organization.
Entra checks both the collaboration allow/block policy and cross-tenant access settings when an invitation is created; the most restrictive applicable setting wins. ^3^ ^4^
Also capture the complete Graph failure response, especially:
- HTTP status
-
error.code -
error.message -
innerError.request-id -
innerError.date
The displayed text alone is insufficient to distinguish domain-policy enforcement from undocumented service-side validation. If a real, controlled domain fails while other real domains succeed and neither policy contains a matching restriction, open a Microsoft support request with those correlation details. A tenant security block is less likely here because documented cases of that condition normally state that invitations are blocked for the directory due to suspicious activity and affect invitation attempts broadly, not just one domain. ^5^
In short: the behavior is reproducible, but special handling of example.com is not documented as an Entra B2B contract. Avoid reserved example domains when validating invitation permissions and use a mailbox/domain capable of completing redemption.
References