SMS push email China — replace the blocked stack
When SMS push email China still rides FCM, global OTP, and overseas mail, Mainland China users never get the message. Remap to China-reachable SMS, vendor push, and transactional email.
SMS push email China is a blocked-client remap, not a CPaaS catalog. If OTP, in-app alerts, and mail still ride FCM, a global SMS rail, and overseas transactional email, Mainland China users often never receive the message. Prove the dead channel, then replace it with China-reachable SMS, vendor push, and email — with entity and ICP adjacency where the sender rail requires it.
What SMS, push, and email deps mean in Mainland China
Hard names for this stack decision:
- SMS (短信) — One-time codes and transactional texts to +86. China SMS products (for example Alibaba Cloud Short Message Service and Tencent Cloud SMS) expect templates, signatures, and a China organizing path. Twilio Messaging is the global SMS/CPaaS rail your HQ stack already knows — it is typically not the Mainland China user OTP path.
- Push / FCM — Firebase Cloud Messaging is Google’s push product (FCM docs). From Mainland China, send and registration hosts commonly fail, and Android devices usually lack Google Mobile Services. Chinaready’s 2026-06-25
cn-beijingprobe recorded FCM send/install hosts as blocked — cite that measurement in Firebase alternatives for China rather than a new 2026 re-probe here. FCM China alternatives are China vendor or OEM channels, not a VPN hope. - Push notifications China — Delivery that Mainland China devices can actually receive: aggregators such as JPush, Getui, or Tencent TPNS, or per-OEM kits. Landscape’s Firebase Cloud Messaging map is a research shortlist, not an endorsement.
- Transactional email China — Password resets, receipts, and invite mail that must arrive in Mainland China inboxes. China-reachable products include Alibaba Cloud DirectMail and SendCloud. Global SaaS mail that never lands is a conversion bug, not a copy-tone issue.
- Blocked client deps — The FCM SDK on the China APK, OTP SMS to +86 via a global sender, and mail from an overseas transactional host. Adjacent form/captcha failure is a sibling gate: Captcha and forms in China. Phone OTP also sits beside app login and payments.
- Common myth — “Keep one global messaging vendor; China is a locale.” Geography is the product. A green Twilio or FCM dashboard outside China does not prove +86 delivery or device push.
Vocabulary first. Next: what must be locked before vendor tickets are real work.
What must be true before you remap the three channels
Missing any of these stops your product team before a clean cutover — you will swap SDKs and still fail China journeys.
| Precondition | Why your process stalls |
|---|---|
| Journey inventory — which flows need SMS, push, or email (login OTP, password reset, order, in-app alert) | Fixing marketing mail while login OTP still uses global SMS leaves China signup dead |
| Per-channel host proof from Mainland China (SMS delivery, FCM/push registration, mail inbox) | Overseas QA “passes” while China users never get the code |
| Entity or China landing partner for SMS signatures / templates and some sender products | Global CPaaS keys do not unlock China template approval |
| ICP-adjacent sending story where mail or web origins must live on a China-filed property | Domain and hosting mismatch → mail or landing URLs still fail |
| Client split decision — China APK/web vs rest-of-world stack | One global FCM binary keeps Mainland China devices mute |
| Owner for cutover + rollback (templates, sender IDs, push certs, mail DNS) | Engineering merges an SDK with no China ops owner for rejects |
Chinese-language vendor consoles, legal-person verification, and template review sit beside the tech change. Your team usually cannot close SMS signatures from HQ Wi‑Fi alone.
SMS vs push vs email remap forks
Use this as a gate map. Stages are decisions, not console click-paths. Fork per channel — a working email path does not rescue blocked push.
| Stage | Decision / outcome |
|---|---|
| 1. Name the broken journey | OTP never arrives · in-app alert silent · reset mail missing — not “messaging is flaky” |
| 2. Classify the dependency | Global SMS (Twilio-class) · FCM / Google push · overseas transactional mail · mixed |
| 3. Prove from Mainland China | Delivery to +86 · FCM/push token path · inbox arrival — cite prior FCM probe; re-test SMS/mail on your path |
| 4. Fork the remap | SMS → China SMS product + templates · Push → vendor/OEM China channel · Email → China-reachable transactional mail |
| 5. Bind entity / ICP where required | SMS signature and some mail/domain rails need a China organizing path; do not invent extra licenses |
| 6. Split the client | China build without FCM on the critical path; keep global rails for non-China users if you must |
| 7. Re-prove after release | Store packages and web tags re-introduce Google or global senders quietly |
Channel forks (selection gate)
Wrong fork keeps the same silent user. Use the set before you fund a “retry webhook”:
| Channel | Typical Mainland China outcome | Honest next decision |
|---|---|---|
| FCM on the China client | Send/registration hosts fail; no GMS device channel | Replace for China — see FCM China alternatives below |
| Global SMS to +86 (Twilio Messaging and peers) | OTP delayed, filtered, or never delivered | China SMS product with templates; Landscape Twilio SMS map is optional research |
| Overseas transactional email | Mail never arrives or lands in spam too late | China-reachable transactional email China path (DirectMail / SendCloud class) |
| China SMS + vendor push + China mail | Usable when contracted, templated, and proved | Primary remap — still prove each journey |
| Keep global stack for China users | Silent OTP, mute push, dead reset mail | Stop claiming China-ready messaging |
Necessity: product teams often freeze “one messaging vendor worldwide.” Without this table, China login and lifecycle stay broken while overseas dashboards stay green.
Why a green global inbox still dies in China
FCM 200 outside China → false confidence. A send API that works from a US region does not mean Mainland China devices registered or received. Device GMS absence is independent of HTTP. Details and dated host probes live in Firebase alternatives for China — this Guide does not copy that table.
Global SMS dashboard green → +86 still dark. Twilio-class Messaging is built as a global rail (Twilio Messaging docs). China carriers and template rules are a different product surface. Unproved +86 OTP is a login outage.
Transactional mail “sent” → user never opens. SPF/DKIM can be valid on an overseas host while Mainland China inboxes never show the message in time. Treat arrival, not API 202, as the gate.
One channel fixed → next journey still blocked. Password reset mail without SMS OTP, or vendor push without a reachable token API, still drops the user. Forks are linked, not optional extras.
Captcha/form still Google-hosted → OTP never starts. If the login form never submits, SMS remap never runs. Sequence captcha and forms beside this map.
Access acceleration without dependency rewrite → partial win. Faster HTML does not resurrect FCM or overseas SMTP. Replace the client dep, then tune delivery.
What blocks a clean messaging cutover
- Single global FCM binary as policy — China APKs need a China-reachable push path, not hope that
fcm.googleapis.comimproves. - Twilio (or peer) as the +86 OTP plan — Global Messaging docs are not a China SMS template approval.
- Proving only the marketing site — OTP, push tokens, and mail hosts are part of “the product.”
- SDK swapped, templates forgotten — China SMS signatures and content templates reject silently if the entity path is missing.
- Mail DNS updated, inbox untested from Mainland China — DirectMail/SendCloud class products still need arrival proof.
- Login still email-only — Mainland China apps often need phone SMS as a real path; see login and payments.
- No China ops owner — Template rejects, sender-ID changes, and OEM push certs are live ops, not a one-sprint ticket.
What “fixed” means: Mainland China users receive the OTP SMS, the push on a China device, and the transactional mail in a usable inbox; China builds do not depend on FCM for those journeys; rollback keys exist. A global-only stack with a China marketing claim is not fixed.
When you need a China landing partner for messaging
Most product teams need a China landing partner to contract China SMS and push vendors, clear signature/template rails, place sending domains beside ICP-aware hosting, and prove +86 / device / inbox paths from Mainland China — not another longer list of CPaaS brands. Your team still owns journey copy and retry UX; the partner path makes China-side sender identity and cutover evidence executable when they are not already in-house.
What we can offer?
SMS, push, and email in Mainland China are a blocked-client remap — prove the dead channel, then cut over to China-reachable rails. Chinaready helps your product team close that loop beside access and hosting:
- China Readiness Assessment — Inventory which journeys still ride FCM, global SMS, or overseas mail; sequence FCM China alternatives vs China SMS vs transactional email China without treating Twilio as the +86 plan.
- China Access Acceleration — Keep China-facing origins reachable while you remove blocked Google and overseas messaging hosts from the critical path.
- China Product Hosting — Place token APIs, mail sending, and related backends where Mainland China proof stays coherent with ICP-adjacent domains.
- Mobile App Distribution — Ship a China client without FCM on the mute path, and align OEM/store packages with vendor push and SMS login that reviewers and users can complete.
Contact us when Mainland China users never get the OTP, the push, or the reset mail — and you need a China-reachable messaging remap, not another global CPaaS retry.
Frequently asked questions
Does FCM work for Mainland China users?
Usually no as the China user path. Firebase Cloud Messaging depends on Google send and registration hosts, and Mainland China Android typically has no Google Mobile Services to hold the device channel. Chinaready’s 2026-06-25 cn-beijing probe of FCM hosts is recorded in the Firebase alternatives Guide — treat that as prior measurement, then remap push for China devices.
Can we keep Twilio SMS for +86 one-time codes?
Treat Twilio SMS as the global messaging rail, not the default Mainland China user path. OTP to +86 usually needs a China SMS product with templates, signatures, and a China organizing path. Prove delivery from Mainland China before you keep a global CPaaS on the China login journey.
What are practical FCM China alternatives?
Replace FCM on the China client with a China-reachable vendor or OEM channel path — aggregators such as JPush, Getui, or Tencent TPNS, or per-OEM kits. Shortlist for device coverage and Mainland China proof; the Firebase alternatives Guide maps the FCM failure, this Decision Map is the remap fork.
Why does transactional email China never arrive?
Global transactional mail often never lands in Mainland China inboxes, or lands too late to complete signup. Use a China-reachable transactional email product (for example Alibaba Cloud DirectMail or SendCloud) with a domain and sending path that works from the China journey — not a hope that SendGrid-style global mail “usually gets through.”
Do SMS, push, and email need a China landing partner?
Usually yes when your team lacks a Mainland China entity or partner path for SMS signatures, push vendor contracting, ICP-adjacent sending domains, and Chinese-language consoles. Engineering can wire SDKs; template approval and +86 delivery sit on China ops rails.
