Microsoft Entra External ID guest invitations repeatedly blocked due to suspicious activity

We are experiencing a recurring tenant-wide block when creating external users through the Microsoft Graph invitations API.

Our Azure Function uses application authentication and the Microsoft Graph POST /invitations endpoint to invite external users. The App Registration has the required application permission with administrator consent.

The process initially works successfully. However, after a period of normal use, all subsequent invitations start returning the following response:

{
  "error": {
    "code": "Forbidden",
    "message": "Invitations are blocked for this directory due to suspicious activity. Please contact Microsoft support for help."
  }
}

Once this happens:

• New invitations through Microsoft Graph return HTTP 403.

Manual invitations from the Microsoft Entra admin center also fail.

The problem affects all administrators, including Global Administrators.

External collaboration settings are configured to allow guest invitations.

Waiting and retrying does not remove the block.

The tenant must apparently be reviewed and unblocked by the Microsoft backend team.

We have reproduced this behaviour across multiple newly created Microsoft Entra External ID tenants. Each tenant works initially and is then blocked after using the same legitimate onboarding process.

We previously observed that attempting to invite an email address that already existed could be followed by the tenant-wide block. We have since implemented the following controls:

Check whether the email address already exists before creating an invitation.

Do not resend an invitation for an existing or pending user.

Do not retry HTTP 400 or 403 responses.

Process invitations sequentially rather than concurrently.

Stop invitation processing immediately when the suspicious-activity response is received.

Despite these changes, newly created tenants are still eventually blocked.

We also noticed several medium-risk Anomalous token detections for the administrator account in Microsoft Entra ID Protection. We are investigating these detections separately. We cannot confirm whether they are related to the invitation restriction.

Could Microsoft please clarify the following?

Is this a known issue or false positive affecting new Microsoft Entra External ID tenants?

Are there unpublished anti-abuse limits for POST /invitations, particularly for new tenants?

Can the same application, administrator account, Azure subscription, or Azure Function outbound IP cause multiple tenants to be risk-flagged?

Can a duplicate invitation attempt trigger a tenant-wide invitation restriction?

Is there a supported invitation rate or daily limit that applications should follow?

Is POST /invitations the recommended approach for application-controlled customer onboarding in an External ID tenant, or should a sign-up user flow be used instead?

How can we prevent the tenant from being blocked again after Microsoft Support removes the restriction?

This is a legitimate business onboarding process, not bulk marketing or unsolicited email. We need a supported long-term solution because requesting a separate backend unblock for every affected tenant is not operationally sustainable.

We can provide tenant IDs, timestamps, Graph request IDs, application IDs, administrator UPNs, and Azure Function outbound IP addresses privately to Microsoft Support if required.We are experiencing a recurring tenant-wide block when creating external users through the Microsoft Graph invitations API.

Our Azure Function uses application authentication and the Microsoft Graph POST /invitations endpoint to invite external users. The App Registration has the required application permission with administrator consent.

The process initially works successfully. However, after a period of normal use, all subsequent invitations start returning the following response:

{
  "error": {
    "code": "Forbidden",
    "message": "Invitations are blocked for this directory due to suspicious activity. Please contact Microsoft support for help."
  }
}

Once this happens:

New invitations through Microsoft Graph return HTTP 403.

Manual invitations from the Microsoft Entra admin center also fail.

The problem affects all administrators, including Global Administrators.

External collaboration settings are configured to allow guest invitations.

Waiting and retrying does not remove the block.

The tenant must apparently be reviewed and unblocked by the Microsoft backend team.

We have reproduced this behaviour across multiple newly created Microsoft Entra External ID tenants. Each tenant works initially and is then blocked after using the same legitimate onboarding process.

We previously observed that attempting to invite an email address that already existed could be followed by the tenant-wide block. We have since implemented the following controls:

Check whether the email address already exists before creating an invitation.

Do not resend an invitation for an existing or pending user.

Do not retry HTTP 400 or 403 responses.

Process invitations sequentially rather than concurrently.

Stop invitation processing immediately when the suspicious-activity response is received.

Despite these changes, newly created tenants are still eventually blocked.

We also noticed several medium-risk Anomalous token detections for the administrator account in Microsoft Entra ID Protection. We are investigating these detections separately. We cannot confirm whether they are related to the invitation restriction.

Could Microsoft please clarify the following?

Is this a known issue or false positive affecting new Microsoft Entra External ID tenants?

Are there unpublished anti-abuse limits for POST /invitations, particularly for new tenants?

Can the same application, administrator account, Azure subscription, or Azure Function outbound IP cause multiple tenants to be risk-flagged?

Can a duplicate invitation attempt trigger a tenant-wide invitation restriction?

Is there a supported invitation rate or daily limit that applications should follow?

Is POST /invitations the recommended approach for application-controlled customer onboarding in an External ID tenant, or should a sign-up user flow be used instead?

How can we prevent the tenant from being blocked again after Microsoft Support removes the restriction?

This is a legitimate business onboarding process, not bulk marketing or unsolicited email. We need a supported long-term solution because requesting a separate backend unblock for every affected tenant is not operationally sustainable.

We can provide tenant IDs, timestamps, Graph request IDs, application IDs, administrator UPNs, and Azure Function outbound IP addresses privately to Microsoft Support if required.