Miss Blue field notes # iMessage delivered vs read: what each status tells you Understand delivered, read, and replied, why a missing read receipt is inconclusive, and how teams should measure actual customer responses. Published September 13, 2026 6 minute read In this guide [Delivered, read, and replied are different evidence](#section-1) [Read the label separately from the bubble color](#section-2) [For an API, accepted comes before delivery](#section-3) [Work through a conversation timeline](#section-4) [Define the numerator before naming a response rate](#section-5) [Handle late and repeated evidence without changing history](#section-6) [Choose a follow-up from context](#section-7) Build with Miss Blue **Turn the next message into a real reply.** Get a blue line for your product, agent, or team. Use the Message Center today and connect the API anytime. [Create your account](https://missblue.dev/signup) [Explore the API](https://missblue.dev/imessage-api) Build with Miss Blue **Turn the next message into a real reply.** Get a blue line for your product, agent, or team. Use the Message Center today and connect the API anytime. [Create your account](https://missblue.dev/signup) [Explore the API](https://missblue.dev/imessage-api) 01 ## Delivered, read, and replied are different evidence Delivered is a delivery status. Read is a receipt made available when the recipient’s settings and channel support it. Replied means an incoming response exists. A message can be delivered without a visible read receipt, and it can be read without the recipient answering. Apple lets people enable read receipts for everyone or individual contacts. Its iPhone guide describes Read as evidence that the message was opened. The absence of that label is not enough to establish whether someone saw a notification, intends to respond, or has blocked you. Avoid treating a missing receipt as a diagnosis of the recipient’s behavior. - [Apple’s read-receipt settings and meaning](https://support.apple.com/guide/iphone/turn-read-receipts-on-or-off-iph5e713a045/ios) 02 ## Read the label separately from the bubble color Apple documents blue bubbles for iMessage and green bubbles for RCS or SMS/MMS. RCS can support delivery and read receipts too. Color identifies the messaging service used for that message; it does not tell a business that a lead has responded or that a sale is likely. Swipe across the table to see every column. How to interpret the evidence without inferring a person’s intent. | Signal | What it supports | What it does not establish | | --- | --- | --- | | Blue bubble | The message used iMessage | The recipient replied or agreed | | Delivered | A reported delivery outcome | A person read and understood the content | | Read | A reported read receipt when available | Interest, consent to another campaign, or a completed task | | Incoming reply | A separate inbound message exists | Whether the reply is positive or needs a human | | No read receipt | No read evidence is available to you | A reliable explanation for silence | | Green bubble | RCS or SMS/MMS rather than iMessage | That all rich features are unavailable | How to interpret the evidence without inferring a person’s intent. - [Apple’s iMessage, RCS, and SMS/MMS comparison](https://support.apple.com/en-us/104972) - [The broader guide to blue text bubbles](https://missblue.dev/blog/blue-text-bubble) 03 ## For an API, accepted comes before delivery An HTTP success response can mean the provider accepted work, not that a person received it. In Miss Blue’s live sending contract, 201 means acceptance. Store the returned message identifier, then observe the subsequent status through the documented API and events. Do not mark a CRM task “customer reached” just because the request returned successfully. Miss Blue documents message.sent, message.delivered, message.failed, and message.received project events. Read receipts are available through message polling. Do not invent a message.read webhook and wait for an event the integration has not promised. Per-message status callbacks are unsigned; the receiving guide explains verification through a message fetch and the signed project-webhook alternative. - [What an accepted Miss Blue send means](https://missblue.dev/docs/sending-messages) - [Events, polling, and callback verification](https://missblue.dev/docs/receiving-messages) 04 ## Work through a conversation timeline Here is a hypothetical sequence. At 09:00, your application submits a scheduling message and stores its provider ID. At 09:01, it records delivery. No read receipt appears. At 09:08, an incoming message says “Friday works.” That reply is direct evidence of engagement even though your system never observed a read receipt. In another conversation, a read receipt appears at 09:02 but there is no reply by the end of the measurement window. Count the available read evidence separately. Do not silently turn it into a response because the campaign would otherwise look weaker. Also distinguish a person’s answer from an automated acknowledgment, an opt-out, or an unrelated inbound message. A reply event tells you something arrived; your documented business definition determines whether it was a qualified response. 05 ## Define the numerator before naming a response rate For a hypothetical cohort of 40 unique new leads, suppose 30 have delivered messages, 12 have observed read receipts, and 8 send a reply within seven days of first outreach. The seven-day text reply rate for that cohort is 8 ÷ 40 = 20%. It is not 30 ÷ 40. If you also want replies per delivered lead, label that separate metric and state its denominator. Exclude duplicate identities and repeated messages from a unique-lead denominator according to your declared identity rules. Keep the first-contact window, observation window, timezone, and handling of late responses visible. If today’s leads have had only ten minutes to answer, comparing them directly with a seven-day-old cohort can mislead. If a contact metric combines text replies with calls, require evidence of a human answering for the call contribution. A connected line, call duration, or voicemail should not stand in for a person reached. When human-answer evidence is unavailable, preserve that uncertainty instead of labeling every connection as contact. - [Deduplicate leads and preserve identity](https://missblue.dev/blog/imessage-crm-contact-sync) - [Measure a messaging program’s outcomes](https://missblue.dev/blog/imessage-marketing) 06 ## Handle late and repeated evidence without changing history Store receipt events independently of the current display label, with their provider IDs and timestamps. A duplicate delivered event should not increase your message count. A delayed older status should not erase an already recorded read receipt or incoming reply. Keep actual reply records even when receipt enrichment is incomplete. Event arrival order and a customer’s actions are separate timelines. If the provider supports message retrieval, use it to reconcile uncertain state; do not submit a second outbound message merely to make the status easier to interpret. - [Process duplicate and out-of-order events](https://missblue.dev/blog/imessage-webhooks) - [Test status handling before live traffic](https://missblue.dev/blog/testing-imessage-api-integration) 07 ## Choose a follow-up from context A missing read receipt by itself is a poor trigger for an immediate follow-up. Use the customer’s request, the urgency of the matter, your agreed follow-up policy, and current ownership. Someone waiting for an appointment confirmation needs a different response from someone who never asked for another message. When a person replies, stop any stale reminder about their silence and route the actual question. When they ask for a teammate, pause automated drafts and preserve the context. Better status reporting should help the team answer appropriately, not pressure customers based on a guessed explanation for silence. - [Write a useful next reply](https://missblue.dev/blog/how-to-respond-to-a-text-message) - [Hand the conversation to a teammate](https://missblue.dev/blog/ai-text-message-human-handoff) Frequently asked questions ## Quick answers Does Delivered mean the person read my iMessage?+ No. Delivery and an available read receipt are separate signals. An incoming reply is separate again. Why does it say Delivered instead of Read?+ Read receipts may be disabled or unavailable, or the message may not have been opened. The label alone does not establish the reason. Does a green bubble mean SMS and no read receipts?+ Green can mean RCS or SMS/MMS. Apple documents read-receipt support for RCS, so color alone is not enough to determine receipt capability. Should a business count a read receipt as a response?+ Keep it as a separate metric. A response rate should use the clearly stated reply or human-contact event that the metric claims to measure. Primary sources ## Read the documentation. - [Apple: read receipts](https://support.apple.com/guide/iphone/turn-read-receipts-on-or-off-iph5e713a045/ios) - [Apple: message types and colors](https://support.apple.com/en-us/104972) - [Miss Blue event and receipt contract](https://missblue.dev/docs/receiving-messages) Explore the platform ## Turn the research into a working conversation. [For developers ### iMessage API Build two-way blue-bubble conversations into your product or agent. Explore](https://missblue.dev/imessage-api) [For teams ### Message Center Use a complete shared conversation platform without writing code. Explore](https://missblue.dev/features/message-center) [For Apple contacts ### FaceTime Audio calling Call from your blue line without carrier Spam Likely labels. Explore](https://missblue.dev/features/facetime-audio-calling) [For every phone ### Outbound calling Call any dialable number from your Miss Blue business line. Explore](https://missblue.dev/features/outbound-calling) Ready to build? ## Send your first blue bubble with Miss Blue. [Explore the iMessage API](https://missblue.dev/imessage-api)