iMessage vs RCS: Which Channel Should You Verify?
Short answer: check both, because the two signals answer different questions. An iMessage lookup tells you whether a number is registered on Apple's network. An RCS lookup tells you whether that line can use Rich Communication Services, and the second answer splits into peer-to-peer RCS and business RCS. Only the second kind applies to a campaign you send. Neither check tells you the message will arrive.
Why the comparison gets framed wrong
People ask which one is more accurate. That framing assumes the two compete for a single slot in your routing table. They don't. They sit on different networks with different coverage, and on a real list you end up using all three routes, including plain SMS at the bottom.
| iMessage | RCS | SMS | |
|---|---|---|---|
| Who runs it | Apple, over data | Carrier and Google, over data | Carrier, over the voice network |
| Devices | Apple hardware only | Android, plus iPhone from iOS 18 | Anything with a radio |
| Bubble color on iPhone | Blue | Green | Green |
| Can you send a campaign over it | No. Apple Messages for Business needs the customer to start the thread | Only where the carrier has enabled business RCS | Yes |
| What a lookup returns | Registered, not registered, unknown | RCS-ready, SMS fallback, review | Line reachability only |
Read that top to bottom and the "which is better" question mostly dissolves. iMessage exists where Apple hardware exists. RCS exists where a carrier turned it on, which is a different map from "owns an iPhone" and a different map again from "can receive a business message."
What the two checks actually return
A useful lookup gives you three outcomes, not two, and the third one is where lists go wrong.
| Result | What it means | What people wrongly read into it |
|---|---|---|
| Registered / RCS-ready | The line answered with a live capability signal at that moment | "This person is active and will open the message" |
| Not registered / SMS fallback | No capability signal came back for that line | "This number is fake" |
| Unknown / review | The lookup timed out, or the upstream answer was inconclusive | "Treat it like a no" |
That last row deserves its own paragraph. An inconclusive lookup is not a negative one, and folding the two together is the single most common way a clean-looking export goes wrong. Sendblue's public API docs handle this correctly: an indeterminate answer comes back as HTTP 502 with its own error code, and the docs tell you to keep it separate from a successful SMS result rather than treating it as proof the recipient lacks iMessage. If the tool you use merges them, you're one join away from suppressing good records.
The other thing to internalize is that a registration answer is a dated observation. Apple's own support page walks people through turning iMessage off when they move to a non-Apple phone, and the reason is simple: registration can outlive the device. Someone who switched to Android last month without deregistering still reads as registered. A number reassigned by the carrier keeps the state it had. So the answer describes the number at the moment you asked, not the person.
The split almost nobody checks: peer-to-peer RCS vs business RCS
Apple shipped RCS in iOS 18, and every comparison post repeats that line, including the earlier version of this one. It's true and it's incomplete in a way that matters if you send messages for a living.
What Apple turned on is peer-to-peer RCS: two people texting, one on an iPhone and one on Android. RCS for Business is a separate path with separate carrier certification. A carrier can enable the first and skip the second, and several large ones have done exactly that.
| Carrier | Peer-to-peer RCS on iPhone | Business RCS |
|---|---|---|
| Rogers (Canada) | Available | Unavailable |
| Fido (Canada) | Available | Unavailable |
| SoftBank (Japan) | Available | Unavailable |
| Vodafone (UK) | Unavailable | Unavailable |
| AT&T, T-Mobile, Verizon (US) | Available | Available |
Rogers is the clean example. A consumer RCS conversation works on an iPhone on that network. A business RCS message does not. So a check that only answers "is this line RCS-capable" returns a yes that means nothing for your campaign. The question worth answering is narrower: can this line be reached through a business RCS route, on this carrier, in this country.
Those tables also rot. The one above is a CPaaS vendor's carrier summary updated in May 2026, and carriers change support without announcing it. Check the month on any coverage table before you build routing rules on top of it, including this one.
What the green bubble tells you, and what it doesn't
There's a persistent shortcut where people read bubble color as a capability test. It fails in both directions. Apple's support page states that RCS messages appear in green bubbles, the same as SMS and MMS, so green tells you "not iMessage" and nothing about whether RCS is active. Blue tells you iMessage was used, which requires you to have already sent something.
You can't run that test at scale either. One number at a time, type a character, watch the color, delete the draft. Across 50,000 contacts that's a project, not a check.
How to decide for your own list
Four steps, in this order.
1. Find out what's in the list before you pick a channel. Run the cheap passes first: country, then line type. A number's country tells you which RCS map applies. Its line type tells you whether it can receive anything at all. Channel checks on top of a list you haven't validated are measuring the wrong thing.
2. Only check iMessage where iPhone share makes the answer actionable. On an Android-heavy list, an iMessage pass spends budget confirming what the line-type data already suggested.
3. For RCS, verify against business coverage, not consumer coverage. This is the step that changes routing decisions, and it's the one left out of most comparison posts.
4. Keep SMS in the fallback slot for everything you can't classify. Three slots, not two. The row that lands in fallback was never the problem; the row you deleted because a timeout looked like a no was.
| List shape | Check first | Why |
|---|---|---|
| Mostly US, consumer marketing | iMessage, then business RCS | Both routes are broadly available there, so the answer changes segmentation |
| Mostly Android, outside the US | Business RCS, then SMS fallback | An iMessage pass adds little when Apple share is low |
| Mixed B2B contact data | Line type and country first | Half the routing decision is already made before any channel lookup |
| Numbers you've already sent to | Nothing. Use the delivery log | Observed delivery beats an inference |
What we do internally, and what we won't claim
We built a 50-country phone format dataset in October 2026 for a different article, and it taught the same lesson this one is about. Every row runs eight assertions against libphonenumber metadata. Three countries failed on the first build, Pakistan, Turkey and Australia, because their national format prints the trunk prefix inside the area-code brackets and our digit count picked it up as significant. The table looked fine. It was wrong by one digit for those three countries.
Channel lookups fail in the same shape. The output looks clean, one column is quietly wrong, and it's usually the column where unknown got binned with no. So we keep three buckets on the RCS side, matched, unmatched and uncertain, and the uncertain bucket never inherits the meaning of the other two.
What we won't claim: we have no controlled test that puts a revenue number on routing this way, so we don't publish one. A capability check is not a delivery guarantee. A registered number is not an online phone. Both are limits of the data rather than bugs to be fixed in the next release.
Three failure modes worth naming
Folding unknown into negative
Timeouts and indeterminate answers become suppressions, and the records you lose are the ones the upstream happened to be slow about. Keep the bucket separate and retry with backoff before you decide anything.
Reading registration as activity
A registered iMessage number means an Apple ID is associated with it. It says nothing about whether the phone is on, whether the person reads it, or whether they want your message.
Reading consumer coverage as business coverage
This one is expensive because it looks like good news. The line can do RCS, the carrier supports RCS, and your campaign still can't use it.
FAQ
iMessage vs RCS, which should I verify first?
Start with line type and country, then pick the channel that matches the list. For a US consumer list, iMessage and business RCS are both worth checking because both routes are broadly available there. For an Android-heavy list outside the US, business RCS coverage is the answer that changes your routing.
Does RCS support on iPhone mean my business can send RCS messages?
No. Apple's iOS 18 support is peer-to-peer RCS between people. Business RCS is a separate carrier certification, and carriers including Rogers and Fido in Canada support the consumer path without supporting the business one.
Can the bubble color tell me whether RCS is active?
No. Apple's support documentation says RCS messages show in green bubbles, the same as SMS and MMS. Green means the conversation isn't using iMessage. It says nothing about RCS.
How fast does an iMessage registration go stale?
Immediately, in the case of someone who switches away from an iPhone and never deregisters. Apple documents the deregistration step because of this. Treat every answer as timestamped and refresh on a schedule rather than once per list.
Should I drop numbers that fail both checks?
Not on a timeout, and not on a single result. An inconclusive lookup is not a negative one. Retry it, and only suppress after a conclusive answer or a repeated failure, or you'll bin records that were fine.
Related ZelNum pages
- iMessage Checker
- RCS Number Checker
- RCS test numbers: how to verify RCS support
- 50-country phone number format dataset
- Phone line type checker
Got a file? Try iMessage Number Checker
Related articles
Ethan works on phone-number normalization, E.164 formatting, country-code rules, carrier metadata, and line-type detection. His editorial work turns verification signals into practical workflows for CRM cleaning, SMS preparation, lead review, and bulk data operations.
View full author profile →