How to know if your number or Sender ID is blacklisted in Morocco

This silent phenomenon is the developer’s nightmare. It is the number one symptom of a Sender ID blacklisted or a blocked routing at the operators firewall level (Maroc Telecom, Orange, inwi).

Here’s a reproducible test protocol to diagnose if you’re on a blacklist, and how to get out of it.

Telecom operators (IAM, inwi, orange) do not send you emails to notify you that your Sender ID has been banned.

Here are the 3 signs that should alert you: 1. Vertical drop in the rate of DLR "Delivered": If you suddenly switch from 95% delivery to less than 20%, it is not a network failure. It is a targeted blocking. 2. Massive "Unknown" or "Rejected" status: If your webhooks DLR receive thousands of 'Rejected' events with a massive network error code, the operator formally rejects your Sender ID.

Don’t rely only on the console. You have to test the “last mile”.

Step 1: Create the test fleet Bring together 3 physical phones, connected to the Moroccan cellular network (not Wi-Fi): 1 IAM subscription, 1 Orange, 1 inwi.

Step 2: Exact Message Test (A/B Test) Send the exact message that causes the problem (same Sender ID, same text, same links) to 3 phones via the API. - If no phone receives it (but API = 200): Your Sender ID is blacklisted at the global level of the gateway or you trigger a hard anti-spam filter. - If only the IAM phone does not receive it: Your Sender ID has lost its whiteling at Maroc Telecom specifically.

Step 3: Isolate the Sender ID vs. Content Replace your usual Sender ID (e.g. MY MARK) with the default Sender ID provided by your gateway (e.g. ENVISMS). Keep the same text and return. - If the message comes, the problem comes exclusively from your Sender ID (administrative blacklist). - If the message does not arrive still not, the problem comes from the content (bit.ly link blocked, spam keywords).

Being on a blacklist is not a fatality, it is usually linked to an abnormal rise in user complaints to the operator or the CNDP.

1. Immediately freeze promotional mailings. Focus on solving the problem to avoid further degrading your “Trust Score”.
2. Open a ticket with the API support. Provide the report of your test protocol (e.g.: "The X message with the Sender ID Y no longer passes on the Inwi network since [Date]").The provider can escalate the case to the operators' Network Operations Centers (NOC).
3. Prove your good faith. If the blocking follows a spam complaint, you will need to provide the provider (who will forward it to the operator) with proof of opt-in (user consent) for the numbers concerned.

In order for a Sender ID to maintain an excellent Trust Score, you must implement these 3 rules in your code:

1. Automatic hard error deactivation: If a number returns a DLR Failed (Number Not Allocated), your application must exclude it from your future campaigns.
2. Opt-Out Management: The famous “STOP SMS”. Allow your customers to easily unsubscribe via a secure web link built into the SMS. A customer who properly unsubscribes is a customer who will not complain to the operator.
3. Channel Separation (Segmentation): Never mix streams. Use a Sender ID MARK_OTP for your critical validation codes, and MARK_PROMO for your marketing campaigns. If your promotional channel is blacklisted, your OTP authentication streams will not be affected.