Why We Stopped Sending Cold iMessage

Apple banned our iMessage sending account three times.

The first time reads as bad luck. The second time you add safeguards — slower warming, tighter caps, backup accounts. The third time you have to admit the safeguards are not the problem, because you were treating a symptom.

This is what we found, and what we changed.

What actually gets an account banned

The instinct is to assume volume. Send too much, get flagged. So you cap volume, and you get flagged anyway.

Volume matters, but it is not the trigger. Sift through what is publicly known about Apple's enforcement and a consistent picture emerges — the flagged profile is a combination:

• an account that is young relative to what it is doing
• low recipient diversity — the same shape of message, out to many people
• a lopsided send-to-receive ratio — an account that talks and never listens
• sudden bursts to numbers it has never contacted before

And one factor that operates on a completely different timescale from all the others: the junk report.

Volume throttling builds over weeks. Reports kill in hours. A single "Report Junk" tap starts causing trouble; a handful in a short window can end an account outright. No amount of careful pacing survives it.

The observation that changed the design

Here is the part that reframed everything for us.

The Report Junk affordance only exists before someone has messaged you.

Once a person has sent you a message, the conversation is one they started. The report button is not the first thing on screen. The relationship is, by definition, wanted.

So the entire class of risk — the fast one, the one that actually kills accounts — lives in exactly one situation: a message to someone who has never talked to you.

Every other signal on that list follows from the same place. Bursts to unfamiliar numbers only happen during cold outreach. A lopsided send-to-receive ratio is what cold outreach looks like by definition. Low recipient diversity is a list being worked.

Cold outreach is not one of several risk factors. It is the root that the others grow from.

What we did about it

We could keep tuning: better warming curves, more accounts, tighter caps, smarter rotation. That is what most platforms in this space do, and it works — for a while, on a treadmill, with the ban always somewhere ahead of you.

Instead we removed the condition:

A senderZ iMessage line never sends to a number that has not messaged it first.

That is enforced in the routing layer, before anything reaches a device. Cold traffic does not get a warning or a slower ramp. It goes over SMS instead — which is A2P-registered infrastructure built exactly for reaching people who have not written to you.

What that costs, honestly

It costs the cold-outbound use case entirely. If your plan is to import ten thousand purchased numbers and send blue bubbles, senderZ will not do it, and the platforms that say they will are selling you a countdown.

It also means the first touch in a lot of workflows is green rather than blue. A lead from a listing site, a verification code at signup, a reminder for a patient who has never texted the clinic — all SMS, at least until they reply once.

We think that is the right trade, and not only for safety reasons. SMS is what SMS is for: one-way, transactional, to people who have not opted into a conversation. iMessage is worth having for the thing it is actually good at — a real thread, with read receipts, that someone chose to be in.

What it buys

The ban class disappears. Not reduced, not mitigated — the condition that creates it stops occurring on our lines.

Consent becomes structural rather than procedural. Every iMessage conversation on the platform started with the recipient. There is no consent record to maintain because the conversation itself is the record.

The signals fix themselves. Send-to-receive ratio is healthy by construction. There are no bursts to unfamiliar numbers. Recipient diversity is whatever your actual customer base looks like.

How a conversation starts now

If you cannot message someone first, they have to come to you. So the product's job becomes making that easy.

A senderZ invite is a link — usable as a button, or printed as a QR code — that opens the recipient's Messages app already addressed to your number, with a short opener written for them. They tap send. That is the whole interaction.

curl -X POST https://api.senderz.com/v1/invites \
  -H "Authorization: Bearer $SENDERZ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"label": "Storefront QR", "opener": "Hi!"}'

{
  "data": {
    "ref": "a7k2np",
    "link": "https://go.senderz.com/a7k2np",
    "number": "+15551230000",
    "opener": "Hi!"
  }
}

Put that link on a receipt, a website button, an email signature, a sign by the till, the back of a van. Whoever scans it starts the conversation, and everything you send them afterwards is unlimited iMessage.

The short code in the opener tells us which business the message belongs to, which is what makes attribution correct when several accounts share a sending number.

Would we recommend this to everyone?

If you are running iMessage at any scale, the question is not whether Apple's thresholds will catch up with you. It is whether you will have built something that survives it.

We rebuilt after the third ban. The honest lesson is that we should have done it after the first, and the reason we did not is that each individual mitigation sounded reasonable at the time.