---
title: "How to Send Millions of SMS Per Day: A High-Volume Guide"
description: "Send millions of SMS per day: TPS planning maths, SMPP binds and windowing, queues, throttling, DLR handling, sender IDs, quiet hours and monitoring KPIs."
canonical: "https://omnichannels.ai/blog/high-volume-sms-sending-guide/"
language: "en"
updated: "2026-11-02"
publisher: "BroadNet Technologies"
brand: "OmniChannels.ai"
category: "sms"
primaryQuery: "send millions of sms per day"
keywords: ["send millions of sms", "sms throughput tps", "smpp window size", "high volume sms", "smpp binds", "sms queueing rate limiting", "dlr handling"]
published: "2026-11-02"
author: "OmniChannels.ai Editorial Team"
reviewer: "BroadNet Messaging Solutions Team"
readingMinutes: 11
answer: "To send millions of SMS per day, size throughput for the peak, not the daily average: divide the segments you must send by the seconds in your sending window, add headroom for OTP traffic, and set the SMPP window to at least TPS multiplied by round-trip time. Use several binds, queues per operator and a rate limiter that backs off on throttling errors, process delivery receipts separately, and keep OTP and promotional traffic apart."
takeaways: ["Ten million messages a day average only about 116 per second, but a promotion squeezed into a four-hour window needs about 694 per second, and every extra segment multiplies it.", "The SMPP specification lets a sender issue many requests without waiting for responses; the number of outstanding requests is left to the implementation, so the window must be agreed and tuned. A good starting rule is window of at least TPS multiplied by round-trip time in seconds.", "Throttling (ESME_RTHROTTLED, 0x58) and queue-full (ESME_RMSGQFUL, 0x14) are signals to slow down and retry with backoff, not to resend immediately.", "Delivery receipts are a second high-volume stream: plan consumers, storage and reconciliation for them as carefully as for submits.", "Capacity is agreed per account and per route with your provider; ask for your peak figures in writing and test them before launch."]
faq: 
  - q: "How many SMS per second do I need to send a million messages?"
    a: "Divide the number of segments by the seconds in your sending window. One million single-segment messages in an hour needs about 278 per second, in four hours about 69, and spread across a full day about 12. Multi-segment messages count once per segment on most platforms, so a two-segment message doubles the rate you need."
  - q: "What is the SMPP window size and how do I set it?"
    a: "The window is the number of submit_sm requests you may have outstanding, sent but not yet answered. The SMPP specification allows asynchronous requests but leaves the limit to the implementation. A practical rule is window of at least target TPS multiplied by round-trip time in seconds, then raise it only up to the limit your provider agrees, because exceeding it causes throttling."
  - q: "How many SMPP binds do I need for high volume?"
    a: "It depends on your peak rate, the per-bind limit your provider agrees and your redundancy needs. Divide the peak TPS by the agreed rate per bind, round up, and add at least one spare so that a dropped connection does not stop the send. Keep OTP traffic on its own binds or accounts. Binds are provisioned per account."
  - q: "What should I do when I receive ESME_RTHROTTLED?"
    a: "Slow down. The specification defines ESME_RTHROTTLED (0x58) as the sender exceeding allowed message limits. Pause or reduce submissions, retry the rejected messages with exponential backoff and jitter, and never retry in a tight loop, which prolongs the throttle. If it happens regularly, your window or rate is higher than the agreed limit."
  - q: "How do I handle millions of delivery receipts?"
    a: "Acknowledge every deliver_sm with deliver_sm_resp immediately, put the receipt on a queue, and process it asynchronously into storage keyed by message ID. Make processing idempotent, because receipts can be repeated. Run receipt consumers separately from the submit path and monitor how far behind they are."
  - q: "Can I send promotional SMS overnight?"
    a: "Not in several markets. The UAE bars marketing texts from 21:00 to 07:00 and Saudi Arabia from 22:00 to 09:00, and from 01:00 to 12:00 during Ramadan. Schedule promotions by each recipient's local time and send OTPs and alerts separately, since they are not promotional."
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"
---

# How to Send Millions of SMS Per Day: A High-Volume Guide

Canonical: https://omnichannels.ai/blog/high-volume-sms-sending-guide/
Language: en
Publisher: OmniChannels.ai by BroadNet Technologies

This guide is for engineers, messaging operations leads and procurement teams who send, or are about to send, between one and ten million SMS per day. It shows how to turn a daily volume into a throughput target, how to configure SMPP binds and windows, how to queue and rate-limit, how to handle delivery receipts at scale, and what to prepare per country. The figures in the examples are illustrative planning numbers, not statements about any provider's capacity.

## How many SMS per second do you need for millions per day?

You need the number of segments divided by the seconds in the window in which you can actually send. Throughput, measured in TPS (messages or segments submitted per second), is a peak figure, not a daily average. See [throughput (TPS)](/glossary/throughput-tps/).

First compute the average, then the peak for your real sending window:

| Daily messages | Average per second over 24 h | If sent in 4 hours | If sent in 2 hours |
|---|---|---|---|
| 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 |

Two multipliers change the table:

- **Segments.** A message longer than one segment is submitted as several parts, and most platforms count each part. 10 million messages averaging 1.5 segments is 15 million submissions. Control this with [SMS character limits](/blog/sms-character-limits-unicode-arabic/) and the [character counter](/tools/sms-character-counter/).
- **Headroom.** Add traffic that is not part of the campaign, such as OTPs, and a margin for retries and slow operators. Thirty per cent is a common planning allowance, not a rule.

## How do you plan throughput from the busiest hour, not the average?

Plan from the hour or window with the most traffic, because that is when queues build and throttling appears. Use this formula:

**Required TPS = (campaign segments ÷ window seconds + peak OTP and alert TPS) × (1 + headroom).**

### Worked example: a regional retailer

A synthetic retailer sends 6 million promotional messages in a day to customers in the Gulf, averaging 1.4 segments each. It wants the send to finish in four hours inside the permitted daytime window.

- Segments: 6,000,000 × 1.4 = 8,400,000.
- Window: 4 hours = 14,400 seconds, so 8,400,000 ÷ 14,400 = 583 per second.
- Peak OTP and alert traffic during the campaign: 40 per second (its own measurement).
- Headroom: 30 per cent.
- Required: (583 + 40) × 1.3 ≈ 810 per second.

That figure is what the retailer asks its provider to confirm per route, in writing, before launch. It is a planning input; it says nothing about what any platform can carry.

## What is an SMPP bind, and how many do you need?

An SMPP bind is a long-lived TCP session between your system and the provider's SMSC, authenticated with credentials and an allowed IP address. SMPP (Short Message Peer-to-Peer) is the telecom protocol for exchanging SMS, and it is built for sustained volume. See [SMPP bind](/glossary/smpp-bind/) and [SMPP vs REST API](/blog/sms-api-vs-smpp/).

There are three bind types: transmitter (submit only), receiver (receipts and inbound only) and transceiver (both on one session). Most senders use transceiver binds.

How many binds you need:

1. Take your required peak TPS.
2. Divide by the rate per bind that your provider agrees for your account.
3. Round up and add at least one spare bind so a dropped connection does not halt the send.
4. Put OTP traffic on its own binds or account.

Binds are provisioned per account, so ask for the number, the rate per bind and the allowed source IPs. Our [SMPP gateway](/channels/sms/smpp-gateway/) page and the [SMPP developer docs](/developers/smpp/) describe the connection.

## How does SMPP windowing work?

The window is the number of submit_sm requests you can have outstanding at once. SMPP is asynchronous: the specification says a sender may send multiple requests without waiting for the responses, and uses the sequence_number in each PDU to match a response to its request. The maximum number of outstanding operations is not defined by the specification; it is governed by the implementation on each side.

The rule that follows from queueing arithmetic is:

**Window ≥ target TPS × round-trip time (seconds).**

| Target TPS | Round trip 50 ms | Round trip 150 ms | Round trip 300 ms |
|---|---|---|---|
| 100 | 5 | 15 | 30 |
| 400 | 20 | 60 | 120 |
| 810 | 41 | 122 | 243 |

A window of 1 means the sender waits for every response, which caps throughput at one divided by the round trip. Raising the window helps until you reach the rate your provider allows; beyond that you only produce throttling. Treat the number as something to agree with your provider and test, not to maximise. Divide the TPS across binds when you use several: four binds at 810 TPS in total each carry about 203.

## How do you queue and rate-limit at scale?

Put a durable queue between your application and the SMPP connection, and drain it with a rate limiter that you can change at runtime. The queue absorbs bursts; the limiter keeps you at the agreed rate.

- **Token bucket per bind and per route.** Refill at the agreed TPS; take a token for every submit_sm, counting each segment.
- **One queue per priority.** OTP and alert traffic first, then transactional, then promotional.
- **Backoff on errors.** On ESME_RTHROTTLED (0x58) or ESME_RMSGQFUL (0x14), pause, then retry with exponential backoff and jitter. Do not resend in a tight loop.
- **Reconnect with backoff** after a disconnect, and keep track of outstanding sequence numbers so you can reconcile what was accepted.
- **Keep sessions alive.** The specification defines an enquire_link timer for checking that the peer still has an active session and an inactivity timer after which a session may be dropped. Send enquire_link while idle.
- **Idempotent submits.** Store your own message ID before submitting so a retry cannot send twice.

## How do you route per operator at scale?

Queue and rate-limit per destination operator as well as per bind, because a slow operator should not block the others. Operators may cap A2P traffic per sender or per route, so the effective limit for a country can be lower than the account rate.

1. Resolve each number to its operator. Number lookup helps; see [HLR lookup](/blog/hlr-lookup-number-validation/).
2. Keep a queue and a limiter per operator or per route group.
3. Watch the delivery rate and receipt delay per operator, and slow the ones that degrade.
4. Ask your provider whether direct routes are used; see [direct vs grey routes](/blog/grey-route-vs-direct-route-sms/).

## How do you handle delivery receipts at scale?

Treat delivery receipts as a second stream as large as the first. A receipt arrives as a deliver_sm on your bind, and you must answer each one with deliver_sm_resp. The spec defines these final and intermediate states in the receipt: DELIVRD, EXPIRED, DELETED, UNDELIV, ACCEPTD, UNKNOWN and REJECTD. See [delivery receipts](/glossary/delivery-receipt/) and [message delivery status explained](/blog/message-delivery-status-explained/).

A reliable design:

1. **Acknowledge fast.** Answer deliver_sm_resp as soon as the receipt is on a queue.
2. **Process asynchronously** with workers that match the receipt to the original by message ID.
3. **Make processing idempotent.** Receipts can be repeated, and out-of-order delivery is possible.
4. **Handle segments.** Depending on the route you may get a receipt per part or per message; test it.
5. **Set a timeout** for messages that never get a final status and mark them unknown.
6. **Keep receipt consumers off the submit path** so that a backlog does not slow sending.

## What must you register per country before you send?

Sender ID rules differ by country, and in some markets unregistered senders are blocked or replaced. Examples: the UAE and Saudi Arabia require registration with the operators, India requires DLT registration of the header and every template, and the US uses 10DLC or toll-free instead of alphanumeric senders. Lead times range from a few business days to about a month in the markets we track.

Start registrations first, since they are on the critical path for launch. Check [SMS marketing rules by country](/blog/sms-marketing-rules-by-country/), the [sender ID checker](/tools/sender-id-checker/) and the [sender ID guide for the UAE and Saudi Arabia](/blog/sms-sender-id-registration-uae-saudi/). We prepare and file registrations with you through our [registration service](/services/registrations/); approvals remain with regulators and operators.

## How do you respect quiet hours at volume?

Schedule promotions by each recipient's local time and country rule, and keep non-promotional traffic out of that restriction. Some markets publish windows: the UAE bars marketing texts from 21:00 to 07:00, and Saudi Arabia from 22:00 to 09:00 and from 01:00 to 12:00 during Ramadan. See [quiet hours](/glossary/quiet-hours/).

- Group the list by country and time zone before queueing.
- Release each group into its own queue when its window opens.
- Stop promotional queues at the window end and carry the rest over to the next day.
- Plan the sequence with the [send-time planner](/tools/send-time-planner/).

A narrow window raises the TPS you need, so check it in the planning formula.

## Why separate OTP and promotional traffic?

OTP and alert messages are time-critical, and promotional campaigns are bulk; if they share a queue or bind, a campaign can delay a login code. Use separate binds or accounts, separate sender IDs where rules require, separate queues with strict priority, and separate monitoring. OTPs are not promotional, so quiet hours do not apply to them. Protect OTP routes from abuse too: see [SMS pumping fraud prevention](/blog/sms-pumping-fraud-prevention/) and the [OTP guide](/blog/otp-authentication-messages-guide/).

## Which KPIs should you monitor?

Monitor submission health, queue age, receipt outcomes and receipt delay, split by country and operator. Alert on changes against your own baseline.

| KPI | Formula | What it tells you |
|---|---|---|
| Submit success rate | Accepted submit_sm_resp ÷ submit_sm sent | Bind and account health |
| Throttle rate | ESME_RTHROTTLED responses ÷ submit_sm sent | Rate or window set too high |
| Queue age (p95) | Time from queue entry to submit | Capacity shortfall |
| Delivered rate | DELIVRD ÷ messages with a final status | Route and content quality |
| Failed and expired share | (UNDELIV + EXPIRED + REJECTD) ÷ final statuses | Number validity, sender ID, filtering |
| Receipt delay (median and p95) | Receipt time − submit time | Operator slowness |
| Receipt coverage | Final statuses ÷ messages submitted | Missing receipts |
| Opt-out rate | STOP replies ÷ promotional messages delivered | Audience and content fit |

See [improving SMS delivery rate](/blog/sms-not-delivered-improve-delivery-rate/) for diagnosis.

## What is a launch checklist for a multi-million send?

1. Required peak TPS calculated from segments, window and OTP load.
2. Rate per bind, number of binds, window and source IPs confirmed in writing by your provider.
3. Sender IDs registered for every country, with templates where required.
4. Load test at a fraction of volume, then ramp in steps; do not start at the maximum.
5. Queues, limiter, backoff and idempotency tested, including a forced disconnect.
6. Receipt pipeline tested at full receipt volume.
7. Quiet-hour scheduling verified per country.
8. OTP traffic separated and monitored.
9. Dashboards and alerts live, with an owner on call.
10. A stop button that halts promotional queues instantly.

## How OmniChannels.ai helps

BroadNet delivers SMS over direct operator connectivity and supports SMPP 3.4 over TLS with binds provisioned per account, plus a REST API, bulk sending, two-way SMS, Unicode and Arabic, HLR lookup and delivery reports. Capacity is sized per account and per route: tell us your destinations, peak volume, sending windows and sender IDs, and we agree throughput, binds and registrations with you. Our team prepares sender ID registrations. [Contact sales](/contact/) with your volume plan, or see the [wholesale programme](/partners/wholesale/). Alerts that need a call can use the [voice API](/channels/voice/).