Support · Contact · Legal
Verified RCS · SMS · MMS · Log in

How does RCS fall back to SMS?

Technical RCS & Developers

Quick answer

Per recipient, once you switch it on. On SimplyRCS an API send carries a fallbackToSms flag and a blast carries up to three fallback steps in descending richness (RCS, then MMS, then SMS). With fallback on, the platform runs a capability check on each destination number before delivering: phones that can receive RCS get the branded, rich version; phones that cannot get the same message as SMS or MMS instead. You author once, and the delivery report shows the channel each recipient actually received.

See this on your own phone: Try RCS on your phone →

Fallback is the mechanism that makes an RCS-first programme safe to adopt before every customer is RCS-ready. It answers the objection every marketing team raises first, which is what happens to the people who cannot receive it. The answer is that they still get the message, in the format their phone supports, without anyone building a parallel campaign. It is also why what RCS messaging is can be answered without a reach caveat attached.

What happens at send time

The sequence is short and entirely invisible to both sides.

  1. You submit one message to one audience, with fallback switched on for that send: the fallbackToSms flag on an API send, the fallback steps on a blast.
  2. The platform checks each destination number's capability, which is a live lookup rather than a stored guess, because capability changes as people change device, carrier, or settings.
  3. RCS-capable numbers receive the rich message: verified sender, images, rich cards, suggestion buttons.
  4. Everyone else receives a degraded but coherent version over SMS, or MMS where the message carries media.
  5. Delivery results come back tagged with the channel each message actually went out on.

There is a second kind of fallback worth knowing about. A number can be RCS-capable and the RCS delivery can still fail, for example if the handset never comes online within the message's time-to-live. Falling back in that case has to be driven by delivery state, not by a timer alone, or the customer can end up with the same message twice. The safe sequence is:

  1. Send the RCS message and wait for its DELIVERED receipt for a set window that suits the message (minutes for a passcode, longer for a promotion).
  2. If no receipt arrives, revoke the RCS message before doing anything else. Google's RBM best practices describe revoking an undelivered message so it cannot arrive late.
  3. Send the SMS version only if the revoke succeeds. A failed revoke usually means the RCS message was delivered in the meantime, so sending SMS as well would duplicate it.
  4. Key every fallback on the original message ID, so a retried job or a late receipt cannot trigger a second SMS for the same message.

When you evaluate a platform, ask which of these steps it performs for you on each send path (API, campaigns, bot replies) and which you configure, and check the answer against the delivery events it actually reports.

What a rich message looks like when it degrades

This is where most of the design work is, and it is worth doing deliberately rather than leaving to a default. A rich card has an image, a headline, a description, and buttons. SMS has none of those things. So the fallback version has to carry the same intent in text: the core message survives, and any suggested action becomes a link.

The practical rule is to write the SMS version as a real message rather than as a stripped card. If the RCS message says "Your order shipped" with a Track button, the SMS should say "Your order shipped. Track it: [link]", not "Your order shipped." with the action silently gone. Check the fallback copy in preview before every campaign, because the failure mode is quiet: the message arrives, it just does nothing.

What fallback does to your bill

Billing follows actual delivery. RCS rates apply to messages delivered as RCS, and carrier SMS or MMS rates apply to the rest. This is exactly why the delivered-as breakdown matters: without it, you cannot reconcile an invoice, and you cannot tell whether your RCS share is growing. Our published rates are on the pricing page and every line of a bill is itemised on billing transparency.

MMS deserves a specific warning here. A media-carrying message that falls back becomes MMS, which is materially more expensive than SMS. A campaign with a large image and a low RCS-capable share can therefore cost more than expected, and the fix is usually to reconsider whether the image is doing enough work to justify carrying it to non-RCS recipients.

Why registration still matters

The SMS leg of a fallback rides a registered 10-digit number, so your 10DLC brand and campaign registration is what keeps that leg deliverable. Leading with RCS does not remove the requirement, it just means fewer messages take that path. 10DLC vs RCS sets out how the two layers fit together.

Key facts
  • Once switched on for a send, fallback is decided per recipient by a capability check at send time, not from a stored list.
  • One authored message covers both paths; rich content degrades to SMS, or to MMS when media is attached.
  • Billing follows actual delivery, so a provider should report the delivered-as breakdown back to you.
  • MMS fallback costs more than SMS, so heavy media on a low-RCS audience is the case to watch.
  • On SimplyRCS fallback is set per send: a fallbackToSms flag on the API send call, up to three fallback steps (RCS, MMS, SMS) on a blast. The message report records the primary channel, the actual channel and the fallback reason for every recipient, and each leg is billed at its own published rate.

Frequently asked

Who decides when a message falls back to SMS?

Two decisions. You decide whether a send may fall back at all: on SimplyRCS an API send carries a fallbackToSms flag and a blast carries up to three fallback steps (RCS, then MMS, then SMS). Once that is on, the platform decides per recipient, from an RCS capability check made at send time: if the device, carrier or setting cannot receive RCS at that moment, the message is delivered as SMS or MMS instead.

Does the customer notice the fallback?

They see a plain text message rather than a branded, interactive one, in the same conversation thread. What they should not see is nothing at all, which is the point: fallback trades richness for reach, so a time-sensitive message still goes out to a phone that cannot take RCS.

Do we pay RCS or SMS rates when a message falls back?

You pay for what was actually delivered. A message that falls back is billed at the SMS or MMS rate, not the RCS rate. On SimplyRCS the delivery report shows which messages landed as RCS and which fell back, so the bill can be reconciled against real delivery rather than estimates.

Does fallback require a separate 10DLC registration?

Yes. The fallback rides your registered 10DLC number, so a brand and campaign registration must be in place for the SMS leg to be deliverable. RCS verification and 10DLC registration are separate approvals and you need both for an RCS-first program to work end to end.

The fastest way to understand RCS is to receive one. Try RCS on your phone →

← All RCS questions