There's a specific failure mode I see constantly with SaaS teams: they register one 10DLC campaign, wire both their auth service and their marketing tool to the same number, and everything works fine for a few weeks. Then login codes start arriving three minutes late — long enough that the code expires before the user types it — and the promo blast that used to hit 90% delivery quietly drops to 60%. Nobody changed anything. That's the point. The carriers changed something, because the traffic pattern flagged.
Full disclosure: I work for Ready, an SMS platform that handles 10DLC registration in-app. So I'll steer you toward doing this right on our platform. But the traffic-separation rule below is carrier physics — it's true wherever you send from, and if you get it wrong on Twilio it fails the same way it fails on us.
Why one number carrying both types of traffic breaks
A 10DLC campaign registration is a declaration to the carriers: this is who I am and this is what I send. You pick a use case — 2FA/OTP, marketing, account notifications, mixed — and the carriers assign trust and throughput based on that declaration. The registered use case is a promise, and carrier filtering systems watch to see if your actual traffic matches it.
Here's where mixing bites you. Transactional traffic — OTP codes, password resets, login verification — gets a high-priority lane and near-zero filtering, because carriers want those to land. A user locked out of their bank is a support nightmare. Marketing traffic gets a slower lane, tighter throughput, and aggressive spam scoring, because that's where the complaints come from.
When you send both from one number, two things happen:
- The carrier can't lane your traffic correctly. A stream that's half instant OTPs and half bulk promos looks like neither. T-Mobile's filtering in particular starts treating the whole number with suspicion.
- A single spam complaint on the promo side poisons the transactional side. One "report junk" tap on your Black Friday blast can raise the block probability on your login codes — the ones that absolutely cannot fail. This is the same mechanism that sinks delivery when businesses share a number, except here you're doing it to yourself.
The use-case mismatch flag, specifically
If you registered a Marketing campaign and push OTPs through it, you're technically fine on throughput but you're wasting the transactional priority lane your codes need. If you registered a 2FA/OTP or Low-Volume Mixed campaign and start blasting promos through it, that's the worse direction — you're sending clear marketing content through a lane declared for transactional-only, and carriers flag the mismatch. Delivery drops silently. No bounce, no error, just fewer messages arriving.
We wrote a whole piece on why registering the wrong use case quietly drops your delivery — the short version is that the carriers read your content and compare it to your registration, and disagreement costs you.
The fix: two campaigns, two numbers, one brand
You don't need two brands. Your 10DLC brand registration is your company — register it once (~$10/mo in carrier fees). Under that one brand, you register two campaigns, each with its own number:
| Transactional campaign | Marketing campaign | |
|---|---|---|
| Use case | 2FA / OTP / Account Notifications | Marketing |
| Sends | Login codes, password resets, receipts | Promos, feature launches, re-engagement |
| Number | Dedicated line A | Dedicated line B |
| Consent model | Implied at signup (they gave you the number to log in) | Explicit opt-in required |
| Filtering profile | High priority, near-zero filtering | Standard, spam-scored |
| Carrier fee | ~$20/mo campaign | ~$20/mo campaign |
The extra cost is roughly $20/month for the second campaign. Against the cost of a founder losing users because they can't log in, that's not a real decision.
The consent column matters as much as the delivery column. Your users handed over a phone number to receive a login code — that's implied consent for the transactional message and nothing else. You cannot legally market to that number without separate explicit opt-in. Keeping the two on separate numbers with separate consent records builds the audit trail cleanly. Ready records opt-in attestation on the marketing side automatically, which keeps the two streams from bleeding into each other.
We go deeper on the split logic in why your MFA texts should never share a number with marketing — worth reading if you want the user-lockout angle specifically.
What "approved" doesn't buy you
A dangerous assumption: campaign approval means messages land. It doesn't. Approval clears you to send; content-level filtering still runs on every message. A promo with a bare bit.ly link, all-caps urgency, or a dollar sign next to a percentage can get filtered even on a perfectly registered marketing campaign. Approval and delivery are two different gates.
This is exactly why you don't want that content-level scrutiny anywhere near your OTP lane. Login codes are boring by design — "Your code is 448201" trips nothing. Keep them on their own number and they stay untouched by whatever the marketing team is A/B testing this week.
Throughput is the other reason to split
OTPs are latency-sensitive and bursty — a hundred users hit "log in" at 9:01am and every code needs to arrive in seconds. Marketing is volume-sensitive — a 40,000-contact blast that takes an hour to drain is fine.
Put both on one number and the blast eats the throughput your codes need. Your 10DLC number pushes a finite number of texts per second, and if the marketing blast is mid-drain when the login rush hits, the codes queue behind it. That's the three-minute-late code from the intro. On separate numbers, the marketing throughput ceiling never touches the transactional lane.
Setting this up without the two-week wait
The historical objection to splitting was onboarding pain — registering two campaigns through a reseller meant two rounds of manual A2P paperwork stretched across weeks. That's the actual reason so many teams shove everything onto one number: they registered once and never wanted to touch it again.
Self-serve 10DLC changes the math. On Ready, brand and campaign registration happen in-app, and most approvals clear same-day. Registering a second campaign under an existing brand is faster than the first — the brand's already vetted. You're looking at another number and another approval, not another quarter.
The steps:
- Register your brand once (if you haven't).
- Register a 2FA/OTP or Account Notifications campaign on number A. Route your auth provider here.
- Register a Marketing campaign on number B. Route your marketing tool / GHL location here.
- Warm the marketing number before any big blast — don't send 10,000 from a day-old number.
- Write sample messages that match each use case, or risk rejection for content you'll never actually send.
If you're a SaaS team specifically, the SaaS 10DLC compliance guide covers the consent and use-case decisions in more detail.
The practical takeaway
One number, two traffic types is the setup that works until it doesn't — and when it stops working, your login codes fail, which is the one message you can't afford to lose. Split them: one brand, two campaigns, two numbers, ~$20/month more. Transactional gets its own untouchable high-priority lane; marketing gets its own spam-scored lane where content experiments and the occasional complaint can't reach your auth flow.
If you want to see what the two-campaign setup costs end to end, our pricing on ReadySMS lays out the per-segment and carrier fees plainly, and you can start with 2,500 free credits to register both campaigns before you send a single dollar's worth of traffic. Set it up right once and you stop thinking about it.