Filtraggio degli SMS A2P: come indagare sui blocchi di contenuti e mittenti
Una guida operativa per distinguere gli errori di invio, gli stati segnalati e le possibili restrizioni, raccogliere prove confrontabili e coordinare un’indagine responsabile senza tentare di aggirare i filtri.

Cosa significa che un SMS A2P potrebbe essere filtrato
Il fatto che un SMS non produca il risultato atteso non dimostra, di per sé, che sia stato bloccato a causa del contenuto o del mittente. Potrebbe esserci un rifiuto in fase di invio, un problema di accettazione o elaborazione, uno stato di consegna non conclusivo oppure una restrizione in un punto successivo della catena. Sulla base delle informazioni disponibili, non è possibile attribuire ogni caso a una fase specifica senza consultare i registri e le definizioni del provider coinvolto.
Perciò è opportuno considerare il «filtraggio» come un’ipotesi da indagare, non come una spiegazione automatica di ogni errore. Iniziate identificando quale sistema ha generato ciascuno stato e quale significato ha esattamente in quel percorso.
- Distinguete i messaggi non accettati per l’invio da quelli che il provider segnala come accettati.
- Registrate gli stati di consegna esattamente come sono stati comunicati e chiedete al provider la definizione applicabile.
- Non concludete che ci sia stato un blocco dovuto al contenuto o al mittente sulla base di un singolo errore o di un codice non interpretato.

Rifiuto, accettazione, DLR e ricezione non sono equivalenti
Un rifiuto in fase di invio indica che, in quel punto del processo, una richiesta non è stata accettata; il motivo va verificato consultando l’errore segnalato. L’accettazione da parte di un provider non conferma che il telefono del destinatario abbia ricevuto il messaggio. Un DLR è uno stato comunicato all’interno della catena, ma la sua portata dipende da come il provider lo genera e lo definisce. Non presentatelo come prova indipendente della ricezione sul dispositivo.
Se avete bisogno di conoscere il significato di uno stato, chiedete la documentazione relativa al percorso e al provider. Quando lo stato non consente di confermare cosa sia accaduto sul dispositivo, dichiarate esplicitamente questa incertezza nei vostri rapporti.
- Conservate separatamente la risposta all’invio, gli stati successivi e ogni eventuale conferma aggiuntiva disponibile.
- Chiedete quale evento rappresenti ciascun DLR e quali sistemi partecipino alla sua generazione.
- Quando non esiste una verifica indipendente sul dispositivo, descrivete il risultato come «DLR segnalato».

Cercate schemi ricorrenti prima di attribuire una causa
Confrontate i casi in base alla destinazione, all’operatore se questa informazione è disponibile, al mittente, al contenuto e al periodo di invio. Uno schema ricorrente può aiutare a circoscrivere l’indagine, ma non dimostra da solo la causa. Possono incidere anche differenze di percorso, configurazione o interpretazione degli stati: verificate questi aspetti con il provider.
Usate per i confronti messaggi autorizzati e legittimi. Se il problema si presenta solo in un gruppo ben definito, circoscrivete l’indagine a quel gruppo prima di apportare modifiche generali che potrebbero compromettere il traffico funzionante.
- Stabilite se il problema riguarda tutte le destinazioni o solo alcune.
- Verificate se il problema coincide con un mittente specifico o una famiglia di modelli.
- Confrontate intervalli temporali equivalenti e annotate i cambiamenti operativi noti.
- Non interpretate una correlazione isolata come conferma di un filtraggio.
Raccogliete prove confrontabili
Preparate una serie di esempi che consenta al provider di esaminare gli eventi specifici. Le prove di consegna, i dettagli degli errori, il registro del mittente e il contenuto sono elementi utili per l’indagine; documentarli insieme evita di basarsi su descrizioni generiche come «non arriva».
Proteggete i dati personali e condividete solo le informazioni necessarie attraverso canali autorizzati. Conservate un riferimento interno che permetta di associare ogni messaggio ai relativi eventi, senza esporre credenziali né dati sensibili in comunicazioni non sicure.
- Identificativo del messaggio o della richiesta, secondo quanto fornito dal sistema.
- Marche temporali con fuso orario e destinazione in formato normalizzato.
- Mittente utilizzato e testo esatto inviato, conservandone una copia controllata.
- Risposta iniziale, stati successivi, codici e descrizioni degli errori.
- Provider o percorso coinvolto ed eventuali cambiamenti rilevanti noti.
Isolate la causa con test controllati
Un test utile mantiene costanti le variabili che non sono oggetto dell’indagine. Definite innanzitutto una popolazione autorizzata e un campione limitato; poi confrontate un elemento alla volta, per esempio il mittente o il modello, mantenendo destinazione, periodo e percorso il più possibile comparabili. Se non potete controllare una variabile, documentate questa limitazione.
Non inviate messaggi di prova a destinatari senza autorizzazione e non generate volumi superflui. Prima di avviare un confronto, concordate con il provider come identificare i messaggi e quali stati sarà possibile osservare.
- Formulate un’ipotesi concreta, per esempio: «lo schema si presenta solo con questo mittente».
- Definite cosa manterrete invariato e quale variabile confronterete.
- Utilizzate traffico legittimo, autorizzato e limitato; registrate ogni invio e il relativo risultato.
- Interrompete il test se l’impatto aumenta o emergono segnali di rischio operativo.
Coordinate l’indagine con il provider e l’operatore
Inviate al provider una selezione rappresentativa di identificativi, marche temporali, destinazioni, mittente, contenuto e stati ricevuti. Chiedete di confermare quale fase sia coperta da ciascun registro, chi generi il codice di errore e se siano disponibili altre informazioni sul percorso che possano circoscrivere il caso. Se l’indagine richiede il coinvolgimento di un operatore, chiedete al provider di indicare il canale e i dati necessari.
Evitate di chiedere una conclusione netta quando i dati consentono solo di formulare un’ipotesi. Se non è possibile confermare che il messaggio sia arrivato al dispositivo, la risposta deve mantenere esplicita questa distinzione.
- Condividete esempi specifici e confrontabili, non solo tassi aggregati.
- Chiedete la definizione documentata degli stati e degli errori rilevanti.
- Chiarite quali verifiche possa svolgere il provider e quali dipendano da terzi.
- Concordate un aggiornamento successivo e registrate conclusioni e limiti.
Applicate modifiche sicure e tracciabili
Verificate che l’uso del mittente e il contenuto rispettino i requisiti applicabili alle destinazioni e alla finalità del messaggio. I requisiti possono dipendere dal Paese, dal percorso e dal tipo di traffico: non date per scontato che una regola sia universale. Verificate le condizioni con il provider e, se opportuno, consultate la documentazione ufficiale applicabile.
Se una modifica viene autorizzata, applicatela in modo controllato e registrate cosa è stato modificato, quando e per quale traffico. Confrontate i risultati con la situazione di riferimento e conservate una versione approvata del modello. L’obiettivo è mantenere il messaggio legittimo e chiaro, non mascherarlo per superare i controlli.
- Verificate che mittente e contenuto corrispondano alla finalità legittima dell’invio.
- Convalidate i requisiti applicabili prima di modificare un mittente o un modello.
- Modificate una variabile per test e tracciate versioni e risultati.
- Valutate l’impatto sulle consegne riuscite prima di estendere una modifica.
Cosa evitare e come chiudere l’incidente
Non modificate i messaggi per eludere i filtri e non apportate cambiamenti che nascondano l’identità o la finalità dell’invio. Evitate anche di aumentare i tentativi di invio alla cieca: senza conoscere la causa dell’errore e le regole di nuovo tentativo del percorso, potreste generare traffico ripetuto senza risolvere il problema. Consultate il provider prima di modificare la politica dei tentativi.
Chiudete l’indagine quando la causa è stata circoscritta a sufficienza oppure documentate quali informazioni mancano. Registrate l’ambito interessato, le prove, le azioni approvate, il risultato osservato e le incertezze ancora aperte. Continuate a monitorare gli stati senza presentare un DLR come ricezione verificata.
- Non utilizzate variazioni ingannevoli del testo o del mittente per aggirare i controlli.
- Non reinviate automaticamente i messaggi senza aver verificato l’errore e la politica concordata.
- Non garantite la ricezione sul dispositivo quando è disponibile solo uno stato segnalato.
- Conservate un riepilogo dell’incidente che permetta di confrontare eventuali casi futuri.
Domande frequenti
Un SMS che non arriva è necessariamente stato filtrato?
No. Un errore può dipendere da diverse fasi o condizioni. Esaminate la risposta all’invio, gli stati successivi e i dettagli dell’errore prima di attribuirlo a un filtro.
Un DLR conferma che il messaggio è stato visualizzato sul telefono?
Non va considerato automaticamente una conferma indipendente della ricezione sul dispositivo. Il suo significato dipende dalle definizioni e dai sistemi del provider; chiedete queste informazioni e descrivete lo stato con precisione.
Quali dati servono per aprire un’indagine con il provider?
Preparate identificativi, marche temporali, destinazione, mittente, testo inviato, risposte e stati, oltre agli errori segnalati e, se disponibile, al percorso coinvolto.
È consigliabile cambiare il testo per verificare se si evita un blocco?
Non modificate i messaggi con l’obiettivo di eludere i controlli. Se c’è un motivo legittimo per rivedere il contenuto, verificate i requisiti applicabili e apportate modifiche autorizzate, controllate e tracciabili.
Devo aumentare i tentativi di invio quando si verificano errori?
Non in modo automatico o alla cieca. Prima identificate l’errore e consultate il provider sulle regole di nuovo tentativo previste per il percorso.
Fonti consultate
- 3GPP specifications3GPP
- ITU-T E.164International Telecommunication Union
- GSMA resourcesGSMA
- SMS filtering investigation guidanceBird