Landline SMS: How Text-to-Landline Routing Actually Works

The assumption that burns deliverability budgets

You scrub your list, keep only numbers flagged as landlines, and route every one of them to your voice channel. Clean logic. The problem is you just skipped sending a text to a few thousand numbers that would have received it fine, read it, and maybe converted. I’ve seen this happen on campaigns where the marketer was being careful, not careless. The mistake was treating “landline” as a synonym for “no SMS.”

It isn’t, not anymore.

Carriers like AT&T, Verizon, and a long tail of regional telcos have quietly enabled text-to-landline on a large portion of their business DID inventory. When an SMS hits one of those numbers, the carrier’s platform catches it and either reads it aloud via text-to-speech, forwards it to a linked email address, or routes it into a business messaging portal. The end subscriber actually gets the message. Not always in the way a mobile user does, but they get it.

The percentage of landlines with this capability active varies by carrier and by the subscriber’s own configuration. But it is high enough that defaulting every landline to voice-only is leaving real reach on the table.

What the carrier DIP layer actually does

When you send an SMS to a US or Canadian number, your upstream carrier runs a database dip against the NANP routing tables to figure out where to terminate the message. For a mobile number that’s straightforward: the LRN points to the terminating carrier, the message goes there. For a landline, the carrier has historically rejected the message with a 30003 or similar error code, because landline switches don’t speak SMPP.

Text-enabled landlines work differently. The carrier provisions a messaging layer on top of the voice DID. Inbound SMS hits that layer instead of the switch, and the carrier handles the translation. From your platform’s perspective, the message is accepted. You get a delivered status. Whether the subscriber actually reads it depends on their configuration, but the routing itself succeeds.

The catch is there’s no universal signaling that tells you a landline has this layer active before you send. You’re flying blind unless you query a source that has mapped it.

How CheckThatPhone surfaces landline SMS capability

The /v1/lookup endpoint returns carrier DIP data on every request: dipCarrier, dipCarrierType, dipCarrierSubType, and dipPorted give you the current serving carrier and whether the number has moved networks. nanpType tells you mobile, landline, or not-mobile (VoIP, toll-free, etc.).

For landline SMS specifically, you add landlineSmsLookup: true to your request body. That triggers an additional query against messaging capability records and returns three extra fields:

  • dipMessagingLookup: whether the lookup itself was attempted and returned a result
  • dipMessagingEnabled: true if the number has an active text-enabled DID layer
  • dipMessagingProvider: the provider handling the messaging translation (useful for debugging if a specific provider has a known delivery issue)

A real request looks like this:

POST https://api.checkthatphone.com/v1/lookup
Authorization: Bearer <key>
Content-Type: application/json

{
  "phone": "2125550198",
  "landlineSmsLookup": true
}

If nanpType comes back as landline and dipMessagingEnabled is true, that number can receive SMS. Route it text-first. If dipMessagingEnabled is false or dipMessagingLookup indicates no record, route it to voice.

This is not a theoretical optimization. The routing decision happens before you spend anything on termination or voice minutes. Getting it right at lookup time is cheaper than learning the hard way from bounce rates.

Building the routing decision into your flow

In practice, the logic inside a campaign send or a signup flow is a small conditional. Something like:

  1. Look up the number via the API.
  2. If nanpType is mobile, send SMS.
  3. If nanpType is landline and dipMessagingEnabled is true, send SMS.
  4. If nanpType is landline and dipMessagingEnabled is false, initiate voice call.
  5. If nanpType is not-mobile (VoIP, toll-free), decide based on your use case. VoIP numbers via hosted platforms often do accept SMS, but that’s a separate routing question.

You also want to check deliverable, blackList, and reason before committing to any channel. A text-enabled landline that’s been deactivated (check deactivationDate) or is on a blocklist is still a wasted send.

If you’re running any kind of marketing campaign, add litigatorFilter: true to the request. That returns litigator, litigator_type, and litigator_name. Sending SMS or making calls to known TCPA litigators is an expensive mistake. The lookup costs cents. A demand letter does not. See how the litigator scrub works if you’re not already running it.

Cleaning a large list before a campaign

If you’re working from an existing contact list rather than validating numbers in real time, calling the endpoint once per number at scale gets tedious and rate-limited fast. The better approach is bulk CSV verification through the CheckThatPhone dashboard.

Upload your list via Dashboard > Bulk CSV. You can enable both the litigator scrub and landline SMS lookup as add-ons on the upload. The system deduplicates, runs carrier and line-type validation on every row, and returns a downloadable result file with all the same fields you’d get from the single-number endpoint, including dipMessagingEnabled for every landline in your list. Files and results are deleted within 24 hours of delivery, which matters if you’re handling any kind of regulated data.

This is the right tool for the pre-campaign hygiene pass. The /v1/lookup endpoint is for real-time checks: signup forms, IVR systems, CRM enrichment on inbound leads. See the contact list hygiene use case for more on how to structure that workflow.

Where this gets imperfect

I want to be honest about the limits. dipMessagingEnabled reflects the carrier’s provisioned capability at the time of the DIP. It does not tell you whether the specific subscriber has configured their text-to-landline preferences. A business can have a text-enabled DID from their carrier and still have the SMS-to-email forwarding turned off on their account. Your message routes successfully at the carrier layer and then goes nowhere on the subscriber side.

That’s an edge case, but it happens. The practical fix is treating text-enabled landline as a tier below confirmed mobile in terms of expected deliverability, and structuring your fallback accordingly. If a text-enabled landline doesn’t produce a response within your conversion window, follow up with voice. Don’t assume silence means disinterest.

Also, dipMessagingProvider is worth logging even if you don’t act on it immediately. If you notice a specific provider in that field correlating with non-responses, you have a data point to investigate.

What to do next

If you’re running any campaign that currently routes all landlines to voice without checking messaging capability, that’s the thing to fix first. Add landlineSmsLookup: true to your lookup requests, split on dipMessagingEnabled, and measure the difference in response rates between text-enabled and non-enabled landlines over your next send cycle.

Check the API docs for the full field reference and the pricing page to see how landline SMS lookups are billed. The cost per lookup is low enough that it makes sense to run it on every landline hit, not just a sample.

Start validating phone numbers today

CheckThatPhone provides real-time carrier, line type, portability, and deliverability data for US & Canada numbers in a single API call.