--- title: "Come inviare milioni di SMS al giorno: guida al grande volume" description: "Inviare milioni di SMS al giorno: calcolo del TPS, bind e finestra SMPP, code, throttling, gestione dei DLR, mittenti, fasce di silenzio e KPI di monitoraggio." canonical: "https://omnichannels.ai/it/blog/high-volume-sms-sending-guide/" language: "it" updated: "2026-11-02" publisher: "BroadNet Technologies" brand: "OmniChannels.ai" category: "sms" primaryQuery: "send millions of sms per day" keywords: ["invio sms massivo", "inviare milioni di sms", "throughput sms tps", "finestra smpp window size", "invio sms grandi volumi", "bind smpp", "gestione dlr sms"] published: "2026-11-02" author: "OmniChannels.ai Editorial Team" reviewer: "BroadNet Messaging Solutions Team" readingMinutes: 11 answer: "Per inviare milioni di SMS al giorno, dimensionate il throughput sul picco e non sulla media giornaliera: dividete i segmenti per i secondi della finestra di invio, aggiungete margine per gli OTP e impostate la finestra SMPP ad almeno TPS per il tempo di andata e ritorno. Usate più bind, code per operatore e un limitatore che rallenta in caso di throttling, elaborate a parte i rapporti di consegna e separate OTP e traffico promozionale." takeaways: ["Dieci milioni di messaggi al giorno hanno una media di soli 116 al secondo circa, ma una promozione concentrata in una finestra di quattro ore richiede circa 694 al secondo, e ogni segmento in più moltiplica il valore.", "La specifica SMPP permette a un mittente di emettere molte richieste senza attendere le risposte; il numero di richieste in sospeso è lasciato all'implementazione, quindi la finestra va concordata e regolata. Una buona regola di partenza è una finestra di almeno TPS moltiplicato per il tempo di andata e ritorno in secondi.", "Il throttling (ESME_RTHROTTLED, 0x58) e la coda piena (ESME_RMSGQFUL, 0x14) sono segnali per rallentare e riprovare con backoff, non per rinviare subito.", "I rapporti di consegna sono un secondo flusso ad alto volume: pianificate consumer, archiviazione e riconciliazione con la stessa cura riservata agli invii.", "La capacità si concorda per account e per rotta con il vostro provider; chiedete per iscritto i vostri valori di picco e testateli prima del lancio."] faq: - q: "Quanti SMS al secondo servono per inviare un milione di messaggi?" a: "Dividete il numero di segmenti per i secondi della vostra finestra di invio. Un milione di messaggi a segmento singolo in un'ora richiede circa 278 al secondo, in quattro ore circa 69, distribuiti su un'intera giornata circa 12. I messaggi multisegmento contano una volta per segmento sulla maggior parte delle piattaforme, quindi un messaggio da due segmenti raddoppia la frequenza necessaria." - q: "Che cos'è la finestra SMPP (window size) e come si imposta?" a: "La finestra è il numero di richieste submit_sm che potete avere in sospeso, inviate ma non ancora riscontrate. La specifica SMPP ammette richieste asincrone ma lascia il limite all'implementazione. Una regola pratica è una finestra di almeno il TPS obiettivo moltiplicato per il tempo di andata e ritorno in secondi; alzatela poi solo fino al limite concordato con il provider, perché superarlo provoca throttling." - q: "Quanti bind SMPP servono per grandi volumi?" a: "Dipende dalla vostra frequenza di picco, dal limite per bind concordato con il provider e dalle vostre esigenze di ridondanza. Dividete il TPS di picco per la frequenza concordata per bind, arrotondate per eccesso e aggiungete almeno un bind di riserva, così una connessione caduta non ferma l'invio. Tenete il traffico OTP su bind o account propri. I bind vengono attivati per account." - q: "Che cosa devo fare quando ricevo ESME_RTHROTTLED?" a: "Rallentare. La specifica definisce ESME_RTHROTTLED (0x58) come il mittente che supera i limiti di messaggi consentiti. Sospendete o riducete gli invii, riprovate i messaggi rifiutati con backoff esponenziale e jitter e non riprovate mai in un ciclo serrato, che prolunga il throttling. Se accade con regolarità, la vostra finestra o frequenza è superiore al limite concordato." - q: "Come gestisco milioni di rapporti di consegna?" a: "Confermate subito ogni deliver_sm con deliver_sm_resp, mettete il rapporto in coda ed elaboratelo in modo asincrono in un archivio indicizzato per ID messaggio. Rendete l'elaborazione idempotente, perché i rapporti possono ripetersi. Eseguite i consumer dei rapporti separatamente dal percorso di invio e monitorate quanto sono indietro." - q: "Posso inviare SMS promozionali di notte?" a: "Non in diversi mercati. Gli Emirati Arabi Uniti vietano i messaggi di marketing dalle 21:00 alle 07:00 e l'Arabia Saudita dalle 22:00 alle 09:00, e dall'01:00 alle 12:00 durante il Ramadan. Programmate le promozioni secondo l'ora locale di ciascun destinatario e inviate OTP e avvisi a parte, perché non sono promozionali." sources: - title: "SMPP Protocol Specification v3.4, SMPP Developers Forum" url: "https://smpp.org/SMPP_v3_4_Issue1_2.pdf" - title: "3GPP TS 23.040: Technical realization of the Short Message Service (SMS)" url: "https://www.3gpp.org/dynareport?code=23040" - title: "TDRA spam policy, UAE" url: "https://tdra.gov.ae/-/media/About/regulations-and-ruling/EN/cellular-phone-spam-regulatory-policy-English.ashx" - title: "CST Regulations for Curbing SPAM Messages and Calls, Saudi Arabia" url: "https://www.cst.gov.sa/en/regulations-and-licenses/regulations/Document-522" --- # Come inviare milioni di SMS al giorno: guida al grande volume Canonical: https://omnichannels.ai/it/blog/high-volume-sms-sending-guide/ Language: it Publisher: OmniChannels.ai by BroadNet Technologies Questa guida è pensata per ingegneri, responsabili delle operazioni di messaggistica e team acquisti che inviano, o stanno per inviare, da uno a dieci milioni di SMS al giorno. Mostra come trasformare un volume giornaliero in un obiettivo di throughput, come configurare bind e finestre SMPP, come gestire code e limiti di frequenza, come trattare i rapporti di consegna su larga scala e che cosa preparare per ogni Paese. Le cifre degli esempi sono numeri di pianificazione illustrativi, non affermazioni sulla capacità di alcun provider. ## Quanti SMS al secondo servono per milioni di messaggi al giorno? Serve il numero di segmenti diviso per i secondi della finestra in cui potete davvero inviare. Il throughput, misurato in TPS (messaggi o segmenti inviati al secondo), è un valore di picco, non una media giornaliera. Vedete [throughput (TPS)](/it/glossary/throughput-tps/). Calcolate prima la media, poi il picco per la vostra reale finestra di invio: | Messaggi al giorno | Media al secondo su 24 h | Se inviati in 4 ore | Se inviati in 2 ore | |---|---|---|---| | 1.000.000 | 11,6 | 69,4 | 138,9 | | 5.000.000 | 57,9 | 347,2 | 694,4 | | 10.000.000 | 115,7 | 694,4 | 1.388,9 | Due moltiplicatori cambiano la tabella: - **Segmenti.** Un messaggio più lungo di un segmento viene inviato in più parti, e la maggior parte delle piattaforme conta ogni parte. 10 milioni di messaggi con una media di 1,5 segmenti sono 15 milioni di invii. Controllatelo con i [limiti di caratteri degli SMS](/it/blog/sms-character-limits-unicode-arabic/) e il [contatore di caratteri](/it/tools/sms-character-counter/). - **Margine.** Aggiungete il traffico che non fa parte della campagna, come gli OTP, e un margine per i nuovi tentativi e gli operatori lenti. Il trenta per cento è un margine di pianificazione comune, non una regola. ## Come pianificare il throughput sull'ora di punta e non sulla media? Pianificate sull'ora o sulla finestra con più traffico, perché è lì che si formano le code e compare il throttling. Usate questa formula: **TPS richiesto = (segmenti della campagna ÷ secondi della finestra + TPS di picco di OTP e avvisi) × (1 + margine).** ### Esempio pratico: un rivenditore regionale Un rivenditore sintetico invia in una giornata 6 milioni di messaggi promozionali a clienti del Golfo, con una media di 1,4 segmenti ciascuno. Vuole che l'invio finisca in quattro ore entro la fascia diurna consentita. - Segmenti: 6.000.000 × 1,4 = 8.400.000. - Finestra: 4 ore = 14.400 secondi, quindi 8.400.000 ÷ 14.400 = 583 al secondo. - Traffico di picco di OTP e avvisi durante la campagna: 40 al secondo (misurazione propria). - Margine: 30 per cento. - Richiesto: (583 + 40) × 1,3 ≈ 810 al secondo. Questo è il valore che il rivenditore chiede al provider di confermare per rotta, per iscritto, prima del lancio. È un dato di input per la pianificazione; non dice nulla su ciò che una piattaforma può sostenere. ## Che cos'è un bind SMPP e quanti ne servono? Un bind SMPP è una sessione TCP di lunga durata tra il vostro sistema e l'SMSC del provider, autenticata con credenziali e un indirizzo IP autorizzato. SMPP (Short Message Peer-to-Peer) è il protocollo delle telecomunicazioni per scambiare SMS, ed è progettato per volumi sostenuti. Vedete [bind SMPP](/it/glossary/smpp-bind/) e [SMPP o API REST](/it/blog/sms-api-vs-smpp/). Esistono tre tipi di bind: transmitter (solo invio), receiver (solo rapporti e messaggi in entrata) e transceiver (entrambi su una sessione). La maggior parte dei mittenti usa bind transceiver. Quanti bind servono: 1. Prendete il TPS di picco richiesto. 2. Dividetelo per la frequenza per bind che il provider concorda per il vostro account. 3. Arrotondate per eccesso e aggiungete almeno un bind di riserva, così una connessione caduta non blocca l'invio. 4. Mettete il traffico OTP su bind o account propri. I bind vengono attivati per account, quindi chiedete il numero, la frequenza per bind e gli IP di origine consentiti. La pagina del nostro [gateway SMPP](/it/channels/sms/smpp-gateway/) e la [documentazione SMPP per sviluppatori](/developers/smpp/) descrivono la connessione. ## Come funziona la finestra SMPP (windowing)? La finestra è il numero di richieste submit_sm che potete avere in sospeso contemporaneamente. SMPP è asincrono: la specifica afferma che un mittente può inviare più richieste senza attendere le risposte e usa il sequence_number di ogni PDU per associare una risposta alla sua richiesta. Il numero massimo di operazioni in sospeso non è definito dalla specifica; è regolato dall'implementazione di ciascuna parte. La regola che deriva dall'aritmetica delle code è: **Finestra ≥ TPS obiettivo × tempo di andata e ritorno (secondi).** | TPS obiettivo | Andata e ritorno 50 ms | Andata e ritorno 150 ms | Andata e ritorno 300 ms | |---|---|---|---| | 100 | 5 | 15 | 30 | | 400 | 20 | 60 | 120 | | 810 | 41 | 122 | 243 | Una finestra di 1 significa che il mittente attende ogni risposta, il che limita il throughput a uno diviso per il tempo di andata e ritorno. Alzare la finestra aiuta finché non raggiungete la frequenza consentita dal provider; oltre, produce solo throttling. Considerate il valore come qualcosa da concordare con il provider e da testare, non da massimizzare. Ripartite il TPS tra i bind quando ne usate diversi: quattro bind con 810 TPS in totale ne gestiscono circa 203 ciascuno. ## Come gestire code e limiti di frequenza su larga scala? Mettete una coda durevole tra la vostra applicazione e la connessione SMPP e svuotatela con un limitatore di frequenza modificabile a runtime. La coda assorbe i picchi; il limitatore vi mantiene alla frequenza concordata. - **Token bucket per bind e per rotta.** Ricaricate al TPS concordato; prelevate un token per ogni submit_sm, contando ogni segmento. - **Una coda per priorità.** Prima OTP e avvisi, poi transazionali, poi promozionali. - **Backoff in caso di errori.** Con ESME_RTHROTTLED (0x58) o ESME_RMSGQFUL (0x14), fate una pausa e poi riprovate con backoff esponenziale e jitter. Non rinviate in un ciclo serrato. - **Riconnettetevi con backoff** dopo una disconnessione e tenete traccia dei sequence number in sospeso, così potete riconciliare ciò che è stato accettato. - **Mantenete vive le sessioni.** La specifica definisce un timer enquire_link per verificare che l'altra parte abbia ancora una sessione attiva e un timer di inattività dopo il quale una sessione può essere chiusa. Inviate enquire_link quando siete inattivi. - **Invii idempotenti.** Salvate il vostro ID messaggio prima dell'invio, così un nuovo tentativo non può inviare due volte. ## Come instradare per operatore su larga scala? Mettete in coda e limitate la frequenza per operatore di destinazione oltre che per bind, perché un operatore lento non deve bloccare gli altri. Gli operatori possono limitare il traffico A2P per mittente o per rotta, quindi il limite effettivo per un Paese può essere inferiore alla frequenza dell'account. 1. Associate ogni numero al suo operatore. La verifica dei numeri aiuta; vedete [HLR lookup](/it/blog/hlr-lookup-number-validation/). 2. Tenete una coda e un limitatore per operatore o per gruppo di rotte. 3. Osservate il tasso di consegna e il ritardo dei rapporti per operatore e rallentate quelli che peggiorano. 4. Chiedete al provider se si usano rotte dirette; vedete [rotte dirette e grey route](/it/blog/grey-route-vs-direct-route-sms/). ## Come gestire i rapporti di consegna su larga scala? Trattate i rapporti di consegna come un secondo flusso grande quanto il primo. Un rapporto arriva come deliver_sm sul vostro bind e dovete rispondere a ciascuno con deliver_sm_resp. La specifica definisce nel rapporto questi stati finali e intermedi: DELIVRD, EXPIRED, DELETED, UNDELIV, ACCEPTD, UNKNOWN e REJECTD. Vedete [rapporti di consegna](/it/glossary/delivery-receipt/) e [stati di consegna dei messaggi spiegati](/it/blog/message-delivery-status-explained/). Una progettazione affidabile: 1. **Confermate in fretta.** Rispondete con deliver_sm_resp appena il rapporto è in coda. 2. **Elaborate in modo asincrono** con worker che associano il rapporto all'originale tramite l'ID messaggio. 3. **Rendete l'elaborazione idempotente.** I rapporti possono ripetersi ed è possibile la consegna fuori ordine. 4. **Gestite i segmenti.** A seconda della rotta potete ricevere un rapporto per parte o per messaggio; testatelo. 5. **Impostate un timeout** per i messaggi che non ricevono mai uno stato finale e segnateli come sconosciuti. 6. **Tenete i consumer dei rapporti fuori dal percorso di invio**, così un arretrato non rallenta gli invii. ## Che cosa registrare per ogni Paese prima di inviare? Le regole sul mittente (Sender ID) variano da Paese a Paese e, in alcuni mercati, i mittenti non registrati vengono bloccati o sostituiti. Esempi: gli Emirati Arabi Uniti e l'Arabia Saudita richiedono la registrazione presso gli operatori, l'India richiede la registrazione DLT dell'intestazione e di ogni modello, e gli Stati Uniti usano 10DLC o numeri toll-free invece dei mittenti alfanumerici. I tempi vanno da pochi giorni lavorativi a circa un mese nei mercati che seguiamo. Avviate per prime le registrazioni, perché sono sul percorso critico del lancio. Consultate le [regole dell'SMS marketing per Paese](/it/blog/sms-marketing-rules-by-country/), il [verificatore di Sender ID](/it/tools/sender-id-checker/) e la [guida al Sender ID per Emirati Arabi Uniti e Arabia Saudita](/it/blog/sms-sender-id-registration-uae-saudi/). Prepariamo e inoltriamo con voi le registrazioni tramite il nostro [servizio di registrazione](/it/services/registrations/); le approvazioni restano a regolatori e operatori. ## Come rispettare le fasce di silenzio con grandi volumi? Programmate le promozioni secondo l'ora locale di ciascun destinatario e la regola del Paese, e tenete il traffico non promozionale fuori da quella restrizione. Alcuni mercati pubblicano le fasce: gli Emirati Arabi Uniti vietano i messaggi di marketing dalle 21:00 alle 07:00, e l'Arabia Saudita dalle 22:00 alle 09:00 e dall'01:00 alle 12:00 durante il Ramadan. Vedete [fasce di silenzio (quiet hours)](/it/glossary/quiet-hours/). - Raggruppate l'elenco per Paese e fuso orario prima di metterlo in coda. - Rilasciate ogni gruppo nella propria coda all'apertura della sua fascia. - Fermate le code promozionali alla fine della fascia e riportate il resto al giorno successivo. - Pianificate la sequenza con il [pianificatore degli orari di invio](/it/tools/send-time-planner/). Una fascia stretta alza il TPS necessario, quindi verificatelo nella formula di pianificazione. ## Perché separare OTP e traffico promozionale? I messaggi OTP e di avviso sono critici dal punto di vista del tempo, mentre le campagne promozionali sono massive; se condividono una coda o un bind, una campagna può ritardare un codice di accesso. Usate bind o account separati, Sender ID separati dove le regole lo richiedono, code separate con priorità rigorosa e monitoraggio separato. Gli OTP non sono promozionali, quindi le fasce di silenzio non si applicano. Proteggete anche le rotte OTP dagli abusi: vedete la [prevenzione delle frodi SMS pumping](/it/blog/sms-pumping-fraud-prevention/) e la [guida agli OTP](/it/blog/otp-authentication-messages-guide/). ## Quali KPI monitorare? Monitorate la salute degli invii, l'età delle code, gli esiti e i ritardi dei rapporti, suddivisi per Paese e operatore. Allertate sulle variazioni rispetto alla vostra base di riferimento. | KPI | Formula | Che cosa vi dice | |---|---|---| | Tasso di successo degli invii | submit_sm_resp accettate ÷ submit_sm inviate | Salute di bind e account | | Tasso di throttling | Risposte ESME_RTHROTTLED ÷ submit_sm inviate | Frequenza o finestra impostate troppo alte | | Età della coda (p95) | Tempo dall'ingresso in coda all'invio | Carenza di capacità | | Tasso di consegna | DELIVRD ÷ messaggi con stato finale | Qualità di rotta e contenuto | | Quota di falliti e scaduti | (UNDELIV + EXPIRED + REJECTD) ÷ stati finali | Validità dei numeri, Sender ID, filtri | | Ritardo dei rapporti (mediana e p95) | Ora del rapporto − ora dell'invio | Lentezza dell'operatore | | Copertura dei rapporti | Stati finali ÷ messaggi inviati | Rapporti mancanti | | Tasso di disiscrizione | Risposte STOP ÷ messaggi promozionali consegnati | Adeguatezza di pubblico e contenuto | Per la diagnosi, vedete [come migliorare il tasso di consegna degli SMS](/it/blog/sms-not-delivered-improve-delivery-rate/). ## Qual è la checklist di lancio per un invio da milioni di messaggi? 1. TPS di picco richiesto calcolato da segmenti, finestra e carico OTP. 2. Frequenza per bind, numero di bind, finestra e IP di origine confermati per iscritto dal provider. 3. Sender ID registrati per ogni Paese, con i modelli dove richiesti. 4. Test di carico a una frazione del volume, poi crescita a gradini; non partite dal massimo. 5. Code, limitatore, backoff e idempotenza testati, compresa una disconnessione forzata. 6. Pipeline dei rapporti testata al volume pieno di rapporti. 7. Programmazione delle fasce di silenzio verificata per ogni Paese. 8. Traffico OTP separato e monitorato. 9. Dashboard e allarmi attivi, con un responsabile reperibile. 10. Un pulsante di stop che ferma subito le code promozionali. ## Come vi aiuta OmniChannels.ai BroadNet consegna gli SMS tramite connettività diretta agli operatori e supporta SMPP 3.4 su TLS con bind attivati per account, oltre a un'API REST, invio massivo, SMS bidirezionali, Unicode e arabo, HLR lookup e rapporti di consegna. La capacità è dimensionata per account e per rotta: indicateci destinazioni, volume di picco, finestre di invio e Sender ID, e concordiamo con voi throughput, bind e registrazioni. Il nostro team prepara le registrazioni dei Sender ID. [Contattate il team commerciale](/it/contact/) con il vostro piano di volumi, oppure scoprite il [programma wholesale](/it/partners/wholesale/).