B2B guest invitations blocked tenant-wide - "Invitations are blocked for this directory due to suspicious activity" - request Entra ID team review

All outbound B2B guest invitations from our tenant fail with:

Invitations are blocked for this directory due to suspicious activity. Please contact Microsoft support for help.

The Entra portal additionally surfaces "User's properties could not be updated after invitation."

What we've confirmed

• Reproduced across multiple surfaces: Entra admin center, Microsoft Graph, and SharePoint sharing.
• External collaboration settings reviewed and correct; guest invite permissions allow invitations.
• Cross-tenant access settings are at defaults and do not restrict outbound invitations.
• No conditional access policy blocks the flow.
• The failure is identical for a brand-new invitee address with no prior guest object.

This is clearly the backend anti-abuse hold rather than a tenant configuration issue.

Support history Microsoft O365 Support case #2607220040005632, opened 2026-07-22. The case was closed the same day as out of scope for the O365 team, with instructions to open a ticket with the Entra ID team via the Entra admin center Help blade. We hold Basic support with no paid Azure support plan, so a technical ticket cannot be submitted through that blade.

Environment / context We are a small Canadian national not-for-profit. Guest invitations are used to give board and committee members - who are volunteers using their own organizational or personal email addresses - access to a SharePoint site containing board materials. Invitation volume is low and infrequent: approximately a dozen invitations were individually sent shortly after we first registered the tenant and as we onboarded the board to SharePoint. We believe a small burst of invitations to mixed external and consumer domains triggered the automated heuristic.

Request Could a moderator please engage the Entra ID team to review and lift the invitation block on our tenant? I can provide the tenant ID, Graph request-id and client-request-id, and exact timestamps by private message.