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

> Some landlines accept SMS through a text-enabled messaging provider. Learn how dipMessagingLookup and dipMessagingEnabled let you route text-first or call-first correctly.

Published 2026-05-26, updated 2026-10-03 by Marcus Whelan. Canonical: https://checkthatphone.com/blog/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 texting the landlines that would have received the message fine, read it, and maybe converted. Careful marketers make this mistake, not just careless ones. The mistake is treating "landline" as a synonym for "no SMS."

It isn't, not anymore. About 7% of the landlines we check are SMS-capable.

A landline becomes textable when a messaging provider is set up to handle texts for the number while the voice service stays with the landline carrier. Business texting platforms and services like Google Voice work this way. When an SMS hits one of those numbers, the messaging provider catches it and delivers it into an app, an email inbox, or a business messaging portal. The end subscriber actually gets the message. Not always in the way a mobile user does, but they get it.

Seven percent is a minority, but on a large list it's enough reachable people that defaulting every landline to voice-only leaves real reach on the table.

## What the carrier DIP layer actually does

When you send an SMS to a US or Canadian number, your messaging provider runs a database dip against the 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 an ordinary landline, the message typically fails with a "landline or unreachable carrier" style error, because the landline network has no way to deliver a text.

Text-enabled landlines work differently. A messaging provider is registered to handle texts for the number, separately from the voice service, so inbound SMS routes to that provider instead of the landline switch. 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` gives the numbering-plan view (`mobile`, `landline`, or `not-mobile`), which porting can make stale, so route on `dipCarrierType`.

For landline SMS specifically, you add `landlineSmsLookup: true` to your request body. When the number is a landline, that runs an additional messaging-capability check and adds the `dipMessaging*` fields. Mobile numbers skip the check and aren't charged for it. The fields that matter most:

- `dipMessagingLookup`: `"true"` when the check actually ran (absent for mobiles and when you didn't ask)
- `dipMessagingEnabled`: `"true"` if messaging is enabled for this landline, `"false"` if not
- `dipMessagingProvider`: the messaging provider serving the number, when there's a match (useful for debugging if a specific provider has a known delivery issue)

Two more, `dipMessagingRefId` and `dipMessagingCountryCode`, carry the provider's reference ID and country. The [landline SMS lookup](/landline-sms-lookup) page covers the add-on and its pricing.

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 `dipCarrierType` comes back as `"landline"` and `dipMessagingEnabled` is `"true"`, that number can receive SMS, and `smsEligible` comes back `"true"` too. Route it text-first. If `dipMessagingEnabled` is `"false"`, 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 with `landlineSmsLookup: true`.
2. If `dipCarrierType` is `"mobile"`, send SMS.
3. If `dipCarrierType` is `"landline"` and `dipMessagingEnabled` is `"true"`, send SMS.
4. If `dipCarrierType` is `"landline"` and `dipMessagingEnabled` is `"false"`, initiate a voice call.
5. If `dipCarrierSubType` is `IPES` (VoIP), decide based on your use case. Some VoIP numbers accept SMS and some don't, so that's a separate routing question.

Steps 2 and 3 collapse into one check if you prefer: `smsEligible` is `"true"` for active mobiles and for landlines confirmed SMS-capable. 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 add-on costs one extra credit. A demand letter costs a great deal more. See [how the litigator scrub works](/use-cases/tcpa-litigator-scrub) 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](/bulk-phone-validation) 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. The upload and the result file are deleted within 24 hours, 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](/use-cases/contact-list-hygiene) for more on how to structure that workflow.

## Where this gets imperfect

I want to be honest about the limits. `dipMessagingEnabled` reflects whether messaging is provisioned for the number at lookup time. It does not tell you whether the specific subscriber has configured their text-to-landline preferences. A business can have a text-enabled number from its provider and still have the SMS-to-email forwarding turned off on its 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. For the list-level view of the same problem, see [why your SMS campaign is silently dropping landlines](/blog/why-your-sms-campaign-is-silently-dropping-landlines-and-how-to-detect-text-enabled-ones), and for how the line types themselves differ, [understanding line types](/blog/understanding-line-types).

Check the [API docs](/docs) for the full field reference and the [pricing page](/pricing) 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.

---

CheckThatPhone is a phone validation API for US and Canada numbers: https://checkthatphone.com (docs: https://checkthatphone.com/docs.md, pricing: https://checkthatphone.com/pricing.md).