Azure Communication Services Call Automation outbound PSTN call blocked with 403 / 510403 "marked as spam"

Chandra User 0 Reputation points
2026-09-12T11:24:24.0966667+00:00

I am testing outbound PSTN calling using Azure Communication Services Call Automation with an ACS trial toll-free phone number.

The outbound call previously worked to the same verified recipient, although the recipient's carrier displayed the incoming call as "Spam Risk." Subsequent Call Automation attempts are now being rejected by ACS.

The webhook diagnostics consistently report:

  • HTTP/provider code: 403
  • ACS subcode: 510403
  • Provider message: "marked as a spam and got blocked"
  • Event: Microsoft.Communication.CreateCallFailed
  • Also followed/preceded by Microsoft.Communication.CallDisconnected
  • Correlation ID: df425cd6-5389-482f-84a5-71dc2968ae24
  • Call Connection ID: 0e005780-9357-48ce-b330-c14c7ee025e1

I have verified the following:

  • The source phone number belongs to the same ACS resource.
  • Azure Portal shows Make calls enabled for the trial number.
  • The trial still has outbound calling minutes available.
  • The destination number is listed as a Verified trial recipient.
  • The source caller ID is explicitly supplied as source_caller_id_number using PhoneNumberIdentifier.
  • Both source and destination use E.164 format.
  • The application uses azure-communication-callautomation Python SDK 1.6.0.
  • The ACS webhook callback is public HTTPS and is receiving the ACS events successfully.
  • The Create Call request reaches ACS, but no CallConnected event occurs.
  • The same ACS trial number successfully reached the same recipient earlier.I am testing outbound PSTN calling using Azure Communication Services Call Automation with an ACS trial toll-free phone number. The outbound call previously worked to the same verified recipient, although the recipient's carrier displayed the incoming call as "Spam Risk." Subsequent Call Automation attempts are now being rejected by ACS. The webhook diagnostics consistently report:
    • HTTP/provider code: 403
    • ACS subcode: 510403
    • Provider message: "marked as a spam and got blocked"
    • Event: Microsoft.Communication.CreateCallFailed
    • Also followed/preceded by Microsoft.Communication.CallDisconnected
    • Correlation ID: df425cd6-5389-482f-84a5-71dc2968ae24
    • Call Connection ID: 0e005780-9357-48ce-b330-c14c7ee025e1
    I have verified the following:
    • The source phone number belongs to the same ACS resource.
    • Azure Portal shows Make calls enabled for the trial number.
    • The trial still has outbound calling minutes available.
    • The destination number is listed as a Verified trial recipient.
    • The source caller ID is explicitly supplied as source_caller_id_number using PhoneNumberIdentifier.
    • Both source and destination use E.164 format.
    • The application uses azure-communication-callautomation Python SDK 1.6.0.
    • The ACS webhook callback is public HTTPS and is receiving the ACS events successfully.
    • The Create Call request reaches ACS, but no CallConnected event occurs.
    • The same ACS trial number successfully reached the same recipient earlier.
    Could Microsoft please check the correlation ID and confirm whether this ACS trial phone number has been blocked by ACS/Microsoft spam or fraud protection? If it has been blocked, can the block/reputation status be cleared for continued Call Automation development/testing, or can you advise the appropriate remediation for an ACS trial number? I can provide additional timestamps or diagnostic information if required.
Azure Communication Services
0 comments No comments

1 answer

Sort by: Oldest
  1. Allan Solomon Mejia 8,175 Reputation points
    2026-09-12T19:34:27.5466667+00:00

    Hello @Chandra User

    Based on the information you provided, this doesn't look like a Call Automation implementation issue.

    The important combination is:

    Microsoft.Communication.CreateCallFailed

    HTTP/provider code: 403

    ACS subcode: 510403

    "marked as spam and got blocked"

    Your CreateCall request reaches Azure Communication Services, but the call is rejected before a CallConnected event is generated. That matches the Call Automation lifecycle: a successful outbound CreateCall ultimately results in CallConnected, while an unsuccessful attempt produces CreateCallFailed.

    You've also already ruled out most of the common configuration issues:

    • the ACS number has outbound calling enabled;
    • trial minutes remain available;
    • the destination is a verified trial recipient;
    • source and destination are in E.164 format;
    • source_caller_id_number is explicitly provided;
    • your callback endpoint is successfully receiving Call Automation events; and
    • the same source/destination combination previously completed successfully.

    Given the explicit spam/block response, I don't recommend changing the SDK code, recreating the callback endpoint, retrying with different E.164 formatting, or repeatedly placing test calls. Those changes aren't likely to resolve a reputation/fraud-control rejection.

    There are actually two related but different possibilities here:

    1. Carrier spam labeling: the destination carrier previously displaying “Spam Risk” can be related to caller-ID reputation at the terminating carrier.
    2. ACS/provider blocking: the subsequent CreateCallFailed with 510403 and “marked as spam and got blocked” indicates that the current call attempt is being actively rejected in the outbound calling path.

    Because the second condition happens before CallConnected, this needs Microsoft/ACS backend investigation rather than application-level troubleshooting.

    Open an Azure Support request for Azure Communication Services > Voice/Calling > Call Automation/PSTN calling and provide:

    Correlation ID: df425cd6-5389-482f-84a5-71dc2968ae24

    Call Connection ID: 0e005780-9357-48ce-b330-c14c7ee025e1

    ACS error:403 / 510403

    Provider message: marked as spam and got blocked

    Also provide the UTC timestamps of several failed calls, your ACS resource/phone number privately, the destination country/carrier (if known), and mention that the same number successfully completed calls earlier.

    Ask ACS support to confirm whether Microsoft/ACS fraud or spam controls have restricted the ACS trial toll-free number/resource, whether 510403 represents a temporary or persistent restriction, and whether the number's outbound calling eligibility/reputation can be reviewed or reset.

    Don't post the full source/destination telephone numbers publicly.

    Also, avoid repeatedly retrying the call while the number is being rejected. If this is an anti-abuse/reputation control, repeated automated attempts aren't a useful troubleshooting step.

    This is also relevant because this is a trial toll-free number. Trial numbers have additional restrictions compared with fully provisioned production telephone numbers, including calling only verified destination numbers. You've already satisfied that requirement, so the explicit 510403 response still warrants backend review rather than another trial-recipient configuration change.

    Unfortunately, I don't see a public Microsoft document that maps ACS subcode 510403 to a customer-remediable configuration setting or provides a self-service mechanism for clearing this specific spam block. Because of that, I wouldn't claim that deleting/reacquiring the number or changing the configuration will clear it without Microsoft first confirming the backend state.

    References:

    Call Automation overview

    Make an outbound call using Call Automation

    Create Call REST API

    Handle Call Automation events

    =============================================================================

    Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.

    Was this answer helpful?

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.