DMText: enterprise SMS that actually gets delivered

The problem: sending is easy, arriving is not

Almost anyone can send a text message from code. Sign up for a messaging API, paste in a number, POST a body, and a phone somewhere buzzes. That demo takes fifteen minutes, and it convinces a lot of teams that SMS is a solved problem.

It stops being solved somewhere around the first real campaign. A company with a list of two hundred thousand customers hits send, watches the dashboard fill with green checkmarks, and then finds out that a meaningful slice of those messages never reached a handset. No bounce, no error, no explanation. The API said queued, then sent, and the story ended there.

That gap is the whole problem DMText was built around. The interesting engineering in enterprise SMS is not the send call. It is everything sitting between your API request and a carrier's decision about whether a message deserves to reach its subscriber — filtering, registration, reputation, throughput shaping, and the retry logic that decides what to do when the answer is no.

What DMText does

DMText is a mass texting platform for businesses: campaigns to large contact lists, automated sequences, and the deliverability tooling that keeps those campaigns landing. It advertises 99.9% delivery and scales to millions of messages.

Both of those numbers deserve to be read precisely, and they are the first thing on this page's fact-check list. "Delivery" in SMS is not one number — it is a chain of them. A message can be accepted by the platform, accepted by the aggregator, accepted by the carrier, and still never render on a screen. A serious platform reports the deepest signal it can actually observe, which for most routes is the carrier delivery receipt, and is honest about where visibility ends. Anything higher up the chain is a send rate wearing a delivery rate's clothes.

The product surface is deliberately unglamorous: import a list, build a campaign, schedule or trigger it, watch delivery in something close to real time, and act on what comes back. Underneath that surface is where the work is.

Deliverability is the product

Carrier filtering

Every message a US carrier delivers passes through spam filtering that is intentionally opaque. Carriers do not publish their rules, do not explain individual blocks, and change behavior without notice. From the sender's side you observe consequences, not causes: a route that ran clean for six weeks starts silently dropping a fraction of traffic, and it is on you to figure out why.

The practical response is to eliminate the things filters reliably dislike. Shortened links from public URL shorteners are among the most consistent triggers, so campaign links get sent through a branded, per-account domain instead. Message bodies that vary only in a customer's first name across a hundred thousand sends look like exactly what they are, so templates carry real variation. Opt-out language stays in the message rather than being trimmed for character count. None of this is clever; all of it compounds.

10DLC registration and compliance

US application-to-person messaging over standard ten-digit numbers runs through the 10DLC framework. Every business registers as a brand, registers each use case as a campaign, and receives throughput and daily volume allowances based on how that brand and campaign were vetted. Unregistered traffic does not get a warning — it gets blocked, surcharged, or both.

For a platform serving many businesses at once, registration is not a one-time setup chore. It is an ongoing operational workflow: collecting the legal entity details and tax identifiers each customer needs to submit, mapping each customer's actual sending behavior to a use case that honestly describes it, handling rejections and resubmissions, and re-checking allowances when a customer's volume grows past what their vetting tier permits. A campaign that a customer describes as "customer care" but uses for promotional blasts will eventually be reclassified by someone other than you, and it is better for that to be caught during onboarding than during a send.

Consent handling sits alongside registration. Opt-in records need to be retained and attributable, STOP and its variants must be honored immediately and permanently at the platform layer rather than left to each customer's own logic, and HELP must return something a human wrote. These are the requirements most often skipped by tools that treat SMS as a feature bolted onto an email product — and they are exactly the requirements whose absence shows up later as filtering.

Sender reputation

Numbers accumulate history. A number that has been sending steady, low-complaint traffic for months is treated differently from one that appeared yesterday and immediately pushed fifty thousand messages. Reputation is per-number, and it is easy to destroy and slow to rebuild.

That makes number strategy part of the architecture. New numbers ramp rather than launch: volume climbs over a warm-up period instead of starting at the customer's desired send rate. Traffic types stay separated, so a promotional campaign and a transactional alert do not share sending identity — one type's complaint rate should never poison the other's delivery. High-volume senders move to sending identities appropriate to their volume rather than accumulating an ever-larger pool of ten-digit numbers, and the platform tracks per-number delivery and complaint metrics closely enough to pull a degrading number out of rotation before its problems spread across the pool.

The queue: what "millions" actually requires

Sending millions of messages is not a throughput problem in the way it first appears. Modern infrastructure can push far more requests per second than the downstream carriers will accept. The constraint is not your capacity — it is a set of externally imposed rate limits that differ per number, per carrier, per registered campaign, and per route, and that change underneath you.

So the architecture is fundamentally about shaping, not speed. A campaign gets expanded into individual messages and enqueued, then drained by workers that respect a rate budget for every sending identity involved. Recipients get bucketed by carrier where that is known, because a single global rate limit either wastes capacity on the permissive carriers or blows past the limits of the strict ones.

Failures need to be sorted before they are retried. A carrier rejection for an invalid or disconnected number is permanent — retrying it wastes budget, costs money, and teaches the platform nothing. A temporary rejection from a saturated route is worth retrying with backoff. A block that appears suddenly across an entire route is not a retry problem at all; it is an alert, because retrying into a block makes the underlying reputation problem worse. Getting that classification right is most of the difference between a queue that recovers from an incident and one that amplifies it.

The other requirement is that campaigns be interruptible. Long-running sends must be pausable and resumable without duplicating messages, because someone will eventually notice a typo in a template forty thousand messages into a send, and "we can stop it now" is the answer that keeps the customer.

What "automated campaigns" means concretely

The phrase covers three distinct things, and the distinction matters for both deliverability and compliance.

Scheduled sends are the simplest: a list, a template, a time. The scheduling layer needs to respect quiet hours in the recipient's local time zone rather than the sender's, which means resolving a rough time zone from the number and holding messages that would otherwise land at 6am.

Triggered sends fire from an event — a signup, an appointment, an abandoned action — which requires the platform to receive events from whatever system the customer already runs. In practice that is where SMS work turns into integration work: the CRM, the booking tool, or the internal database is the source of truth, and getting clean, deduplicated events out of it is a larger job than the message itself.

Sequences are multi-step flows with waits and branches, where a reply or a conversion stops the rest of the series. The hard requirement here is that inbound messages are first-class. A platform that treats SMS as outbound-only will keep sending step three to someone who already replied "yes" to step one, and that is both a bad experience and a fast route to complaints.

What this project reinforced

The lesson that generalizes past SMS: in messaging infrastructure, the vendor API is the least interesting part of the system. Swapping one provider for another is a week of work. Building the registration workflow, the reputation tracking, the classification of failures, and the throughput shaping that makes a high delivery rate repeatable is the actual product — and it is the part that does not come from anyone's SDK.

The second lesson is that delivery numbers are only meaningful with their definitions attached. A platform that says 99.9% should be able to say immediately what it measures, where its visibility ends, and what it does on the days it misses.