A sticky sender is the practice of always sending to a given recipient from the same number. The term comes from platforms that manage a pool of numbers and pick one per message; stickiness is the rule that says pick the same one for the same person.

## Why does it matter?

Because a handset groups messages by sender, and a changed sender starts a new conversation.

To a recipient, a message from a new number is a message from a stranger. It appears as a separate thread with no history above it, so the reminder does not sit under the booking confirmation it belongs with. If your messages arrive from a rotating pool, one relationship looks like several unrelated ones.

The stronger case is anything two-way. A recipient replies to the thread they are looking at, which means replying to the number that sent it. If you have since moved to a different number, their reply goes to a number you may not be listening on, and a reply that matters can be lost. `STOP` is the case where that becomes a compliance problem rather than a usability one: [what is a STOP keyword](/explained/sms/what-is-a-stop-keyword) covers what must happen when one arrives, and it cannot happen if the reply never reaches you. [What is MO vs MT](/explained/sms/what-is-mo-vs-mt) covers why inbound is a separate path at all.

## How does this work on Bird?

There is no sender pool to be sticky about, which changes where the responsibility sits.

Bird takes the sender on each send. The [Twilio migration guide](/docs/guides/sms/migrate/twilio) names the difference for anyone arriving from a platform that resolves it for you:

> **A Messaging Service SID becomes a plain sender value.** Twilio resolves the sender pool, sticky sender, and geomatch behind the SID. Bird takes the sender itself in `from`, so pick the sender per send, or use a [template send](/docs/guides/sms/templates), which selects a valid sender for the destination and rejects `from`.

So stickiness is not a setting to switch on. It is a consequence of what you pass in `from`, which means the mapping from recipient to sender is state you hold rather than state the platform holds for you.

That is more work and it is also more predictable. There is no pool to reason about, no allocation rule that might surprise you, and no case where the platform quietly picks a different number than last time.

## How do I implement it?

Store the mapping and use it.

The pattern is to record which sender a recipient was first contacted from, and to look it up on every subsequent send to that recipient. Two things to decide when you build it:

- **What happens when the mapping is missing.** A new recipient needs a sender chosen by some rule, and that rule should account for what the destination carries.
- **What happens when the stored sender is no longer valid.** A number you released, or one that is not permitted for a destination the recipient has moved to, needs a fallback and probably a re-mapping.

If you hold a dedicated number for a market, stickiness is close to free, because there is only one sender to be sticky with.

## When should I not bother?

When the sender cannot be stable anyway, which is more often than you would think.

A template send deliberately gives up stickiness: it selects a valid sender for the destination and rejects `from` outright. That is a good trade for international transactional traffic, where having a permitted sender in every country is worth more than one continuous thread.

The same applies wherever the sender type varies by destination. If a recipient in one country gets an alphanumeric sender and another gets a long code, there is no stickiness to preserve across them, and designing around a stable sender will mislead you. [Which sender type should I use](/explained/sms/which-sms-sender-type-should-i-use) covers what varies.