Here's the failure mode almost every SaaS team walks into: you register one 10DLC campaign, wire your number into your auth service and your lifecycle marketing, and everything works for a few weeks. Then support tickets start trickling in — "I never got my login code." You check your logs, the message shows "sent," and you have no idea why a customer couldn't log in.
The short version: your one-size-fits-all campaign is being treated by carriers as marketing traffic, and marketing traffic gets filtered harder than transactional. Your 2FA codes — the messages you literally cannot afford to lose — are riding the same lane as your "50% off annual plans" blast.
Full disclosure: I work for Ready, an SMS platform. We handle 10DLC registration in-app, so I've watched a lot of teams file the wrong campaign shape and pay for it in delivery. This post is about why the split matters and how to actually do it.
Carriers rate every campaign by its worst-behaving message
When you register a 10DLC campaign, you pick a use-case: 2FA, account notifications, marketing, mixed, and so on. That use-case sets expectations. Carriers apply different filtering thresholds and different content scrutiny depending on what you said you'd send.
Transactional traffic — OTP codes, password resets, shipping alerts — gets the gentlest treatment. It's user-initiated, expected, and low-complaint. Marketing traffic gets the strictest. Promotional content triggers more spam reports, so carriers filter it aggressively and throttle it harder.
Now put both on the same campaign. Two things happen:
- You register the campaign as "mixed" or "marketing" to cover the promo sends, which means your OTP codes inherit marketing-grade filtering.
- Your promo content drives complaints and STOP replies, and those complaints degrade the campaign's reputation — the same campaign your login codes depend on.
The auth messages didn't do anything wrong. They just got dragged down by the neighborhood they were living in. We wrote a whole piece on the registration side of this — registering a 'marketing' campaign for transactional texts is why your delivery silently drops — and the pattern is exactly the same when you cram both use-cases into one campaign.
Why "sent" doesn't mean "delivered" for filtered codes
This is the part that trips up engineers. Your auth provider's API returns a success. Your logs say delivered-to-carrier. But the carrier's spam filter can silently drop or delay the message before it reaches the handset, and you often get no distinct error back.
For a marketing message, a filtered send is annoying. For a login code, it's a locked-out customer, a support ticket, and — if it happens enough — churn. A user who can't log in twice is a user shopping for a competitor.
The cruel timing: filtering gets worse as your marketing volume grows. So the exact moment your product is succeeding — more sends, more campaigns — is when your critical auth traffic quietly starts failing.
The fix: separate campaigns by use-case, not by convenience
The clean architecture is one campaign per intent, each registered honestly:
| Traffic type | Use-case to register | Typical content | Why it's separate |
|---|---|---|---|
| 2FA / OTP | Authentication / 2FA | "Your code is 448210" | Highest trust, must never be filtered |
| Account notifications | Account notification / transactional | "Your invoice failed", "Password changed" | User-expected, low complaint |
| Lifecycle / marketing | Marketing | "Upgrade and save 20%", "New feature drop" | High complaint, needs isolation |
Each campaign carries its own reputation. A complaint against your marketing campaign no longer touches your auth campaign. Your OTP traffic gets the light-touch filtering it deserves because that campaign only ever sends codes.
Yes, this means more registrations. Under 10DLC that's roughly ~$10/mo per brand (one-time-ish, you register the brand once) plus ~$20/mo per campaign in carrier fees. So running three campaigns instead of one is about $40/mo extra in campaign fees. Weigh that against the cost of a single week of undelivered login codes and it's not a close call.
For the SaaS-specific angle on which use-cases apply to which of your flows, our SaaS 10DLC compliance guide breaks it down flow by flow.
Should auth and marketing use different numbers, too?
Separate campaigns are the non-negotiable part. Separate numbers are a further refinement, and whether you need it depends on volume.
- Same number, separate campaigns: Perfectly valid. A number can carry multiple campaigns. The campaign is the unit carriers rate, so isolating campaigns already isolates reputation.
- Separate numbers: Worth it at scale, especially if your marketing volume is large enough to be a throughput bottleneck. Auth codes are latency-sensitive — a user is staring at the screen waiting. You don't want them queued behind a 40,000-contact promo blast that's spreading out over the throughput ceiling.
That throughput point is real and under-discussed. A 10DLC number has a per-second send cap, and a big marketing blast eats it. We covered exactly this in why your noon flash sale trickles out until 12:40 — if your OTP codes share that number, they're stuck in the same queue while someone's trying to log in.
My rule of thumb: below a few thousand marketing sends a day, same number with split campaigns is fine. Above that, give auth its own dedicated number so a promo send can never delay a login.
Watch your OTP message content, too
Splitting campaigns fixes the structural problem. Two content details still bite people:
Don't jam marketing into transactional messages. The tempting move is to append "P.S. Check out our new plans!" to a password-reset text. That's the fastest way to get your transactional campaign reclassified and filtered as marketing. Keep auth messages pure — code, purpose, done.
Keep them short and clean. A code message like "Your Acme code is 448210. It expires in 10 minutes." is 55 characters — one GSM-7 segment at $0.02 + $0.0045 carrier on Ready Standard, so about $0.0245 per code. Add an emoji and you cross into unicode encoding, which drops the segment limit to 70 characters and can split a message you thought was one segment into two. For high-volume auth traffic, that emoji doubles your cost for no benefit. Skip it.
What this looks like set up correctly
A SaaS company doing this right has, at minimum:
- An Authentication campaign — OTP and 2FA only, registered as auth, ideally on its own number if volume is high.
- A transactional / account-notification campaign — billing failures, security alerts, password-change confirmations.
- A marketing campaign — onboarding drips, feature announcements, upgrade nudges, win-back — with its own consent trail and STOP handling.
On Ready, all three register from the same dashboard, opt-outs propagate across campaigns so a STOP on your marketing never accidentally silences a legit account alert the user still wants (that logic is per your consent setup, but the mechanism is there), and quiet-hours enforcement applies where it should — you generally don't want quiet hours on OTP, since a code is user-initiated and expected at any time.
If you're building the marketing side properly from scratch, our creative SaaS SMS onboarding piece has the lifecycle flows worth registering that marketing campaign for.
The practical takeaway
Your login codes and your promo blasts have opposite risk profiles. Codes must never be filtered; marketing will always generate some complaints. Put them on the same 10DLC campaign and the complaints from one drag down the delivery of the other — and it's always the critical traffic that suffers, silently, with a "sent" status hiding the failure.
The fix is boring and cheap: register separate campaigns per use-case, give auth its own number once volume justifies it, and keep OTP messages free of any marketing content. Roughly $40/mo in extra campaign fees buys you a login flow that doesn't break when your marketing succeeds.
If you want to set the campaigns up and see the split live, you can start on Ready with 2,500 free credits — no card required — and register each use-case from the same dashboard. Or read the SaaS 10DLC compliance guide first if you'd rather map your flows before you file anything.