Sending a million SMS messages is straightforward. Getting a million SMS messages delivered is an entirely different challenge. At the heart of that challenge sits SMS throughput rate limiting — the practice of deliberately pacing outbound message volume to stay within carrier-imposed thresholds and avoid triggering content filters. For high-volume senders running time-sensitive campaigns, understanding and implementing proper rate limiting is the difference between a strong delivery rate and watching half your traffic silently disappear into carrier filtering systems.
This guide breaks down how carrier filtering works, what throughput limits look like across different number types, and how to architect a sending strategy that maximizes volume without sacrificing deliverability.
Why Carriers Filter High-Volume SMS Traffic
Carriers like T-Mobile, AT&T, and Verizon operate sophisticated filtering systems designed to protect subscribers from spam. These systems analyze traffic patterns in real time, looking for signals that distinguish legitimate messaging from unwanted bulk sends. When your sending behavior triggers these heuristics, messages get silently dropped — no error code, no bounce notification, just a message that never arrives.
The filtering operates at multiple layers:
- Velocity-based filtering — Sudden spikes in message volume from a single number or campaign trigger automatic throttling or blocking.
- Content-based filtering — Repeated identical or near-identical message bodies across large volumes flag the traffic as spam.
- Reputation-based filtering — Numbers or campaigns with poor historical engagement (high opt-out rates, low click-through) face stricter scrutiny.
- Pattern-based filtering — Uniform send intervals, identical message lengths, and predictable sending patterns look automated and get flagged.
Rate limiting addresses the velocity layer directly, but it also indirectly helps with pattern detection. By pacing sends intelligently, you avoid the telltale signatures of bulk spam operations.
Throughput Limits by SMS Number Type
Not all originating numbers are created equal. The type of number you send from determines your baseline throughput ceiling, and exceeding that ceiling is the fastest way to get filtered. Below is a breakdown of the major number types and their practical throughput limits in the United States.
| Number Type | Max Throughput (MPS) | Registration Required | Typical Use Case | Filtering Risk at Max Rate |
|---|---|---|---|---|
| Long Code (unregistered) | 1 MPS | No (but risky) | P2P messaging | Very High |
| 10DLC (low-volume brand) | 3–15 MPS | Yes (TCR) | Small business campaigns | Moderate |
| 10DLC (high-volume brand) | 15–75 MPS | Yes (TCR + vetting) | Enterprise A2P campaigns | Low–Moderate |
| Toll-Free (verified) | 30–50 MPS | Yes (toll-free verification) | Transactional + marketing | Low |
| Short Code (dedicated) | 100–500+ MPS | Yes (carrier approval) | High-volume marketing | Low |
MPS stands for messages per second. These numbers represent theoretical maximums — in practice, sustained sending at the ceiling often triggers filtering even on registered numbers. Many experienced senders operate at 60–80% of the stated maximum to maintain a safety margin.
If you are running campaigns on 10DLC numbers, proper registration is essential. Our complete 10DLC registration walkthrough covers the process from brand registration through campaign approval and throughput tier assignment.
How Carrier Filtering Works: A Technical Overview
Understanding the mechanics of filtering helps explain why naive approaches to high-volume sending fail. Carrier filtering systems operate as multi-stage pipelines.
Stage 1: Ingress Rate Detection
When messages arrive at the carrier's SMSC (Short Message Service Center), the system tracks the ingress rate per originating number and per campaign. If the rate exceeds the number's registered throughput tier, excess messages are queued or dropped. Some carriers return a 4xx throttling response; others silently accept the message and discard it downstream.
Stage 2: Content Analysis
Messages that pass the rate check enter a content analysis engine. This engine examines the message body, embedded URLs, and metadata. High similarity scores across a batch of messages — even if sent within rate limits — can trigger filtering. This is why message variation matters alongside rate limiting.
Stage 3: Behavioral Scoring
The carrier maintains a rolling reputation score for each originating number. Factors include opt-out rates, complaint rates, delivery success rates, and historical volume patterns. Numbers with poor scores face lower effective throughput limits, regardless of their registered tier.
Stage 4: Network-Level Decisions
Finally, the carrier makes a delivery decision. Messages can be delivered, delayed, silently dropped, or in some cases, delivered with a spam label. T-Mobile's anti-spam system is particularly aggressive, while AT&T tends to silently drop filtered messages without notification.
For a broader look at deliverability factors beyond throughput, see our guide on whether your SMS messages will actually get delivered.
Rate Limiting Strategies for High-Volume SMS Senders
Effective rate limiting goes beyond simply capping sends per second. A robust strategy accounts for number pools, carrier distribution, time-of-day patterns, and dynamic adjustment based on delivery feedback.
Strategy 1: Per-Number Throttling
The most fundamental approach is capping the send rate on each individual originating number. If you are using 10DLC numbers with a 15 MPS tier, configure your sending system to stay at 10–12 MPS per number. This provides headroom for carrier-side rate counting discrepancies.
A simplified implementation in pseudocode:
// Token bucket rate limiter per originating number
for each originating_number in number_pool:
rate_limiter[originating_number] = TokenBucket(
rate=12, // messages per second
burst_size=15, // allow small bursts
refill_interval=1 // refill every second
)
// Before sending each message
if rate_limiter[selected_number].acquire():
send_message(selected_number, recipient, body)
else:
queue_for_retry(message)
Token bucket algorithms work well here because they allow small bursts while enforcing an average rate over time, which mimics natural sending patterns more effectively than a strict fixed-rate approach.
Strategy 2: Number Pool Distribution
To achieve aggregate throughput beyond what a single number supports, distribute sends across a pool of originating numbers. If you need 100 MPS and each 10DLC number supports 12 MPS safely, you need a minimum of 9 numbers — though 12–15 is more prudent to account for variance.
The distribution algorithm matters. Round-robin assignment is simple but creates a detectable pattern. More effective approaches include:
- Weighted random selection — Assign sends randomly across the pool, weighted by each number's current health score and remaining rate budget.
- Carrier-aware routing — Route messages through numbers that have historically performed well with the recipient's carrier.
- Sticky assignment — Assign each recipient to a consistent originating number to maintain conversation continuity and avoid the appearance of number rotation.
Strategy 3: Ramp-Up Scheduling
New numbers and newly registered campaigns should not immediately send at their maximum throughput. Carriers track volume ramp patterns, and a number that goes from zero to 10 MPS overnight looks suspicious. A standard ramp-up schedule for a new 10DLC number might follow this pattern:
| Day | Target MPS | Daily Volume Cap | Notes |
|---|---|---|---|
| 1–3 | 1–2 MPS | 500–1,000 | Initial warm-up; monitor delivery rates closely |
| 4–7 | 3–5 MPS | 2,000–5,000 | Gradually increase if delivery rates stay above 95% |
| 8–14 | 5–10 MPS | 10,000–25,000 | Approach operational target; watch for filtering signals |
| 15+ | 10–12 MPS | Full volume | Steady state; continue monitoring |
If delivery rates dip below 90% at any stage, reduce volume and investigate before continuing the ramp.
Strategy 4: Dynamic Rate Adjustment
Static rate limits are a starting point, but the most resilient systems adjust dynamically based on real-time delivery signals. Key signals to monitor include:
- Delivery receipt (DLR) success rate — A sudden drop in DLR success rates suggests filtering has engaged.
- Carrier-specific error codes — Codes like 30007 (carrier violation) or 21610 (unsubscribed) from downstream providers indicate problems.
- Opt-out rate spikes — A sharp increase in STOP replies signals content or targeting issues that will damage your number's reputation.
- Click-through rate changes — If CTR drops while send volume increases, some messages may not be reaching recipients.
When these signals degrade, the system should automatically reduce throughput, redistribute load across the number pool, or pause sending on affected numbers. Trackly's deliverability tools include built-in throughput rate limiting that automatically paces message sends to stay within carrier thresholds, adjusting in response to delivery feedback to help high-volume senders maintain consistent delivery rates at scale.
Message Encoding and Its Impact on Throughput
An often-overlooked factor in throughput planning is message encoding. SMS messages encoded in GSM-7 fit 160 characters in a single segment, while UCS-2 encoded messages (required for emoji and many non-Latin characters) fit only 70 characters per segment. A single "logical" message that spans multiple segments consumes multiple message slots in your throughput budget.
Consider this scenario: you are sending a 200-character marketing message that includes an emoji. The UCS-2 encoding requirement means this message consumes 3 segments. If your rate limit is 12 MPS, you are effectively limited to 4 logical messages per second — a 67% reduction in effective throughput.
This is why character encoding validation should be part of your pre-send pipeline. Our detailed breakdown of GSM-7 vs UCS-2 encoding and its impact on cost and deliverability covers this topic in depth. Trackly's deliverability tools include GSM-7 encoding validation and segment counting, helping you catch encoding issues before they eat into your throughput budget.
Common Rate Limiting Mistakes
Even teams that understand the need for rate limiting often make implementation errors that undermine their efforts.
Mistake 1: Limiting Only at the Application Layer
If your application enforces a 10 MPS limit but your message queue has retry logic that resubmits failed messages, the actual send rate can exceed your intended limit during retry storms. Rate limiting must account for retries, and retry delays should be factored into the throughput budget.
Mistake 2: Ignoring Carrier-Specific Behavior
Different carriers have different filtering sensitivities. T-Mobile is notably more aggressive than AT&T or Verizon. A one-size-fits-all rate limit may be too conservative for some carriers and too aggressive for others. Carrier-aware rate limiting — where you maintain separate throughput budgets per destination carrier — produces better results.
Mistake 3: Treating All Message Types Equally
Transactional messages (order confirmations, 2FA codes) and marketing messages receive different carrier treatment. Mixing them on the same originating numbers and applying the same rate limits wastes throughput on the marketing side and risks filtering on the transactional side. Separate your traffic streams.
Mistake 4: No Monitoring or Alerting
Rate limiting without monitoring is flying blind. You need real-time visibility into per-number send rates, DLR success rates, and carrier-level delivery metrics. Without this data, you cannot determine whether your rate limits are appropriate or whether filtering is occurring.
Mistake 5: Sending Identical Content at Volume
Rate limiting alone does not prevent content-based filtering. If you send the exact same message body to 100,000 recipients — even at a carefully paced rate — carriers will flag the content as spam. Message variation (dynamic fields, rotating copy variants) is a necessary complement to rate limiting. Platforms with A/B testing and algorithmic creative selection capabilities, like Trackly, make it straightforward to rotate message variants automatically across a campaign.
Architecture Patterns for Scalable SMS Sending
For teams building or evaluating high-volume SMS infrastructure, several architectural patterns support effective rate limiting.
Pattern 1: Queue-Based Throttling
Place all outbound messages into a message queue (e.g., RabbitMQ, SQS, Kafka). Worker processes consume from the queue at a controlled rate, with each worker bound to a specific originating number and its associated rate limit. This decouples message generation from message sending and provides natural backpressure.
// Simplified queue-based architecture
[Campaign Engine] → [Message Queue] → [Rate-Limited Workers] → [SMS Gateway]
↑
Token Bucket
per originating
number
Pattern 2: Distributed Rate Limiting with Redis
In distributed systems where multiple application instances send messages concurrently, a centralized rate limiter is essential. Redis-based implementations using the sliding window or token bucket pattern ensure that the aggregate send rate across all instances stays within limits.
// Redis sliding window rate check (pseudocode)
function can_send(originating_number, max_rate, window_seconds):
key = "rate:" + originating_number
now = current_timestamp_ms()
// Remove entries outside the window
redis.zremrangebyscore(key, 0, now - (window_seconds * 1000))
// Check current count
count = redis.zcard(key)
if count < max_rate * window_seconds:
redis.zadd(key, now, unique_id())
redis.expire(key, window_seconds * 2)
return true
return false
Pattern 3: Timezone-Aware Scheduling
High-volume campaigns that target recipients across multiple time zones benefit from timezone-aware send scheduling. Rather than sending the entire list at once and hitting throughput limits, stagger sends by timezone to spread the load over several hours. This reduces peak throughput requirements and improves engagement by delivering messages during appropriate local hours.
Trackly's scheduled sends feature supports timezone-aware delivery, which naturally distributes volume across time windows and reduces the peak throughput demand on your number pool.
Monitoring and Observability for SMS Throughput
A production-grade rate limiting system needs comprehensive monitoring. The key metrics to track include:
- Current send rate — Per originating number and aggregate, measured in real time.
- Queue depth — How many messages are waiting to be sent. Growing queue depth indicates your throughput capacity is insufficient.
- DLR success rate — Per originating number and per destination carrier. This is your primary signal for detecting filtering.
- Time-to-send — The latency between a message entering the queue and being submitted to the carrier. High latency means your rate limits are creating bottlenecks.
- Retry rate — The percentage of messages that require retries. High retry rates suggest you are hitting carrier limits.
- Opt-out rate — Tracked per campaign and per originating number. Spikes indicate content or targeting problems.
Set up alerting thresholds for each metric. A DLR success rate dropping below 90% on any number should trigger an immediate investigation. A retry rate above 5% warrants a review of your rate limit configuration.
Calculating Your SMS Throughput Requirements
Before configuring rate limits, you need to understand your actual throughput requirements. The calculation depends on your campaign parameters:
Required MPS = (Total Messages × Average Segments per Message) ÷ Send Window in Seconds
For example, a campaign sending 500,000 single-segment messages over a 4-hour send window requires:
500,000 ÷ (4 × 3,600) = 34.7 MPS
If those messages average 2 segments each (due to length or encoding), the requirement doubles to 69.4 MPS. This is why encoding optimization and message length management are throughput concerns, not just cost concerns.
Once you know your required MPS, you can calculate the number pool size:
Number Pool Size = Required MPS ÷ Safe Per-Number MPS × 1.25 (safety margin)
For 69.4 MPS on 10DLC numbers with a safe rate of 12 MPS per number:
69.4 ÷ 12 × 1.25 = 7.2 → 8 numbers minimum
When Rate Limiting Is Not Enough
Rate limiting is necessary but not sufficient for high-volume deliverability. Several complementary practices are equally important:
- Content variation — Rotate message copy, use dynamic personalization fields, and vary URL parameters to avoid content-based filtering.
- List hygiene — Remove invalid numbers, long-term non-engagers, and known litigators. Sending to bad numbers wastes throughput and damages reputation.
- Proper opt-out handling — Process STOP requests immediately and maintain accurate suppression lists. Sending to opted-out recipients is both a legal risk and a deliverability problem.
- Number registration — Ensure all originating numbers are properly registered with the appropriate campaign use case. Unregistered traffic faces the strictest filtering.
- Engagement-based segmentation — Prioritize sending to engaged subscribers. Carriers track engagement signals, and high-engagement traffic earns more favorable treatment.
These practices work together with rate limiting to build and maintain a strong sending reputation. Neglecting any one of them can undermine even the most carefully tuned throughput configuration.
Putting It All Together
Effective SMS throughput rate limiting is a system-level concern, not a single configuration setting. It requires understanding carrier behavior, choosing appropriate number types, implementing robust per-number throttling, monitoring delivery signals in real time, and adjusting dynamically when conditions change.
For high-volume senders, the investment in proper rate limiting infrastructure pays for itself through improved delivery rates, lower per-message costs from fewer wasted sends, and more predictable campaign performance. The alternative — sending as fast as possible and hoping for favorable results — is a strategy that works until it suddenly does not, usually at the worst possible time.
If you are scaling SMS campaigns and want a platform that handles throughput rate limiting, encoding validation, and deliverability monitoring out of the box, Trackly SMS is built for high-volume senders who need reliable delivery at scale.