Trackly SMS | Blog
Deliverability & Throughput

SMS Throughput Rate Limiting: Scale High-Volume Campaigns Without Getting Filtered

Trackly SMS ·

Tags: sms throughput, rate limiting, sms deliverability, carrier filtering, high-volume sms, 10dlc throughput

SMS Throughput Rate Limiting: Scale High-Volume Campaigns Without Getting Filtered

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:

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 TypeMax Throughput (MPS)Registration RequiredTypical Use CaseFiltering Risk at Max Rate
Long Code (unregistered)1 MPSNo (but risky)P2P messagingVery High
10DLC (low-volume brand)3–15 MPSYes (TCR)Small business campaignsModerate
10DLC (high-volume brand)15–75 MPSYes (TCR + vetting)Enterprise A2P campaignsLow–Moderate
Toll-Free (verified)30–50 MPSYes (toll-free verification)Transactional + marketingLow
Short Code (dedicated)100–500+ MPSYes (carrier approval)High-volume marketingLow

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:

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:

DayTarget MPSDaily Volume CapNotes
1–31–2 MPS500–1,000Initial warm-up; monitor delivery rates closely
4–73–5 MPS2,000–5,000Gradually increase if delivery rates stay above 95%
8–145–10 MPS10,000–25,000Approach operational target; watch for filtering signals
15+10–12 MPSFull volumeSteady 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:

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:

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:

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.