The Complaint That Starts Every One of These Investigations
A customer rings and says they never got their booking confirmation. You open the Twilio console, find the message, and it says sent. So the code worked, right?
Not necessarily. sent is the most misread word in the Twilio dashboard, and in Australia — where carriers filter SMS more aggressively than almost anywhere — the gap between "we sent it" and "they received it" is exactly where messages go to die.
This post walks through how delivery actually works on Australian networks, what the error codes are really telling you, and the production test protocol we use to find the fault before anyone opens a support ticket.
"Sent" Is Not "Delivered"
Every Twilio message moves through a status lifecycle:
| Status | What it actually means |
|---|---|
queued | Twilio accepted your API request. Nothing has left the building. |
sent | Twilio handed the message to the downstream carrier. That is all. |
delivered | The carrier returned a delivery receipt (DLR) confirming handset delivery. |
undelivered | The carrier explicitly reported failure — check the ErrorCode. |
failed | The message never made it out of Twilio (bad number, no geo permission, etc.). |
The trap: sent means the carrier took the message. It does not mean the carrier passed it on. A message that a carrier silently filters can sit at sent forever — no error code, no bounce, no evidence, and a customer staring at an empty inbox.
The good news for Australian traffic is that Telstra, Optus and Vodafone return delivery receipts reliably, so delivered is a status you can actually trust here. Which means the inverse is also true: a message stuck at sent for more than a few minutes on a major Australian network is a red flag, not a rounding error.
If your dashboard, CRM or reporting counts sent as success, your delivery rate is fiction. Count delivered.
Why Australia Filters Harder Than You Think
Australian carriers operate under an industry code aimed at reducing scam SMS, and they enforce it with network-level content filtering. Telstra, Optus and TPG each run their own detection, and none of them publish the rules. What we see in practice, from working through real message logs on Australian traffic:
- URL shorteners are the number one trigger.
bit.ly,tinyurland friends are heavily associated with scam campaigns. Send your full branded domain instead. - Link plus urgency phrasing — "your account will be suspended, click here" — is a scam fingerprint even when it's legitimate.
- Sender mismatch gets messages flagged: a message claiming to be from a brand, sent from a random unregistered number or sender ID.
- New senders ramping fast. A number that sent nothing yesterday and thousands today looks like a compromised route.
On top of carrier-side filtering, Australia has been rolling out an SMS Sender ID Register operated by the ACMA. Carriers check alphanumeric sender IDs against it, and traffic from unregistered sender IDs is a candidate for blocking or scam-labelling. Sender ID registration has moved from nice-to-have to table stakes for Australian A2P messaging.
The practical takeaway: if your messages started failing without a code change, suspect filtering policy before you suspect your integration. Carrier rules shift; your code didn't.
Alphanumeric Sender IDs: Register or Get Filtered
An alphanumeric sender ID is when the message arrives from "YOURBRAND" instead of a phone number. It looks professional and lifts read rates — and it is also the most common thing we find misconfigured on Australian Twilio accounts.
Three things to know:
- Australia requires pre-registration. Twilio requires alphanumeric sender IDs to be registered for Australian traffic before use — you submit the sender ID, your business details, the use case and sample message content. Unregistered alpha sender traffic to Australia is liable to be filtered or rejected rather than delivered.
- Alphanumeric senders are one-way. There is no number to reply to. If your workflow expects replies — confirmations, reschedules, STOP handling — an alpha sender cannot carry it.
- Opt-out still applies. Under the Spam Act, marketing messages need a working unsubscribe path. With a one-way sender you must provide an alternative opt-out mechanism, and carriers notice when you don't.
If you registered nothing and you're sending from "YOURBRAND" today, you have found your problem.
Decoding the Error Codes That Matter
When a message does come back undelivered or failed, the ErrorCode field is the closest thing you get to a reason. The ones that matter for Australian traffic:
| Code | Twilio's label | What it means in practice |
|---|---|---|
| 30007 | Message filtered | The carrier's content filter ate it. Look at your content (links, phrasing) and your sender registration — not your code. |
| 30034 | Unregistered sender / A2P | Your message hit a registration requirement it doesn't satisfy. Most commonly seen on US-bound legs of mixed traffic, but it tells you precisely which route is unregistered. |
| 30003 | Unreachable handset | Phone off or out of coverage. Carriers retry for a window; persistent 30003 on one number is a dead handset. |
| 30005 | Unknown destination | The number doesn't exist. Recurring 30005s mean your contact data needs cleaning. |
| 30006 | Landline or unreachable carrier | You are texting a fixed line. Common when a lead form accepts any phone number. |
| 30008 | Unknown error | The carrier gave nothing back. Isolated, ignore; clustered, escalate with message SIDs. |
Two patterns worth memorising:
- A burst of 30007 across many recipients = the carrier changed its mind about your content or sender. Fix the trigger, don't resend the same message harder — repeated identical sends to a filtering carrier make your sender reputation worse.
- No error code, permanently
sent= the delivery receipt never came back. On Australian majors this usually means silent filtering; on some MVNOs and international hops it can just mean patchy DLR support. The test protocol below tells the two apart.
Choosing the Right Number Type for Australian Traffic
The sender you choose decides what your messaging can do — and how it gets filtered.
| Option | Two-way? | Best for | Watch out for |
|---|---|---|---|
| Australian mobile long code (+61 4xx) | Yes | Transactional messages, booking confirmations, anything expecting a reply | Per-number throughput limits — don't push campaign volume through one number |
| Alphanumeric sender ID | No | One-way branded notifications, once registered | No replies possible; must be registered for Australia |
| Short code | Yes | Genuine high-volume campaign scale | Lead time and ongoing commitment that only make sense at serious volume |
And one anti-pattern: do not send Australian traffic from US or other foreign numbers because they were cheap to provision. International-origin routes into Australian mobiles are exactly where filtering is harshest and delivery receipts are least reliable. If your recipients are Australian, your sender should be Australian.
For most Australian small businesses the right answer is an Australian long code for transactional two-way flows, with a registered alphanumeric sender for one-way notifications if brand presentation matters.
The Production Test Protocol: Run This Before Blaming Twilio
When delivery breaks, guessing is expensive. This is the log-reading protocol we run on Australian SMS faults, in order — each step either isolates the fault or eliminates a variable:
- Pull the actual message records. Not the dashboard summary — the API records, with
statusanderror_codeper message SID. The distribution tells you the story: allfailedis a config problem, scattered 30007 is filtering, uniformsent-and-stuck is silent filtering or DLR loss. - Build a carrier test matrix. One handset each on Telstra, Optus and Vodafone, plus one MVNO (Boost, Amaysim, whatever is in the office). Australian filtering is per-carrier — a message that delivers on Telstra and dies on Optus has just told you where to look.
- Isolate the content variable. Send three versions from the same sender: plain text, text with your full-domain link, text with a shortened link. When the plain text delivers and the shortener version doesn't, you have your answer without reading a single line of code.
- Isolate the sender variable. Same content from your alphanumeric sender and from an Australian long code. Alpha fails, long code delivers: registration problem.
- Check number formatting. Australian mobiles must go out as E.164 —
+614xxxxxxxx, leading zero dropped. Numbers stored as04xx xxx xxxin a CRM and passed through raw are a classic silent failure. - Check account configuration. Geo permissions include Australia, the messaging service actually contains the sender you think it does, and STOP/opt-out handling hasn't quietly unsubscribed your test recipients.
- Only then, escalate. If the matrix shows a specific carrier eating registered, clean-content messages, raise it with Twilio support with message SIDs attached. Now the ticket contains evidence instead of vibes, and it gets actioned instead of bounced.
This isn't a hypothetical checklist. We run two-way SMS in production for an Australian service business — booking confirmations backed by Stripe payments. The same build discipline runs a stack of sixteen integrations on one codebase in full automation. At that level of automation you don't get to assume delivery — the protocol above is what we build into an SMS channel before it carries live traffic.
Wire In Delivery-Rate Monitoring So You're Not Debugging Blind
The single biggest upgrade you can make to an SMS integration is knowing your delivery rate continuously instead of discovering a problem when a customer complains.
Twilio supports a status callback URL on every message: as the message moves through its lifecycle, Twilio POSTs updates to your endpoint with the MessageSid, MessageStatus and, on failure, the ErrorCode. Wiring it up takes an afternoon:
- Log every callback against the message SID — you now have a permanent per-message delivery record instead of a 30-day console history.
- Compute a trailing delivered rate — messages
delivereddivided by messagessent, over the last 24 hours. - Alert on two conditions: the trailing rate dropping below your normal baseline, and any burst of a single error code (five 30007s in an hour is a carrier policy change announcing itself).
- Keep the receipts. When a customer disputes a booking confirmation, a stored
deliveredstatus with a timestamp ends the conversation.
The verification layer is built to catch a carrier policy change before your customers do. Without it, your first monitoring system is your angriest customer — and they don't file structured error reports.
If It's Broken Right Now
Two situations, two paths:
Messages are failing in production today. That's a diagnosis job, not a rebuild — message logs, error-code distribution, carrier matrix, sender registration audit, in that order. That's exactly what our integration rescue service exists for, and we reply within 1 business day.
You're building SMS into your workflow and want it done properly the first time — registered senders, the right number types, status callbacks and monitoring wired in from day one. That's an integration build, and it's a lot cheaper than retrofitting verification after the first silent outage.
Either way: stop trusting sent. Delivery is a claim your logs should be able to prove.
Share This Article
Spread the knowledge