To test an SMS route, send real messages to handsets on every major network in the destination country, then compare what the phones received with the delivery reports: check that the sender ID and text arrive unchanged, measure latency, and confirm that failures are reported as failures. Repeat over several days before moving real traffic.
Before you start
- Get test numbers on each network. Use your own SIMs, colleagues or partners in the country, or a handset test panel service. Testing only one network hides problems on the others. Use MCC and MNC codes to make sure you cover each operator.
- Use your real sender ID and real content. A route that delivers "Test 123" from a generic sender may block your brand name or your OTP template. If registration is required, complete it first. See sender ID registration.
- Request DLRs on every test message and log submit time, submit_sm_resp time and DLR time.
- Agree the test with the supplier so the volume is small and the route is the same one you will get in production.
What to check
| Check | How | Good result |
|---|---|---|
| Delivery | Message appears on each test handset | All handsets receive it |
| Sender ID | Compare displayed sender with what you sent | Identical, not replaced by a random number |
| Content | Compare text, special characters, links | Unchanged, no garbled characters, links intact |
| Long messages | Send a 2 or 3-part message | Shown as one message |
| Latency | Time from submit to arrival on the phone | A few seconds on good routes |
| DLR accuracy | Compare DLR status and time with the phone | DELIVRD only for received messages, timestamps close to arrival |
| Failure reporting | Send to an invalid number and to a phone switched off | UNDELIV or EXPIRED, not DELIVRD |
The last row is the most useful single test for fake DLRs. A route that reports delivery to a phone that is off is not telling the truth.
Test types
- Functional test: 10 to 20 messages per network covering the checks above, including Unicode text if you send in local languages. See GSM-7 vs Unicode.
- Time-of-day test: repeat at peak hours and late at night. Some routes change path when volume grows, and some deliver promotional content only during allowed hours.
- Load test: send at your expected peak TPS to see if throttling or delays appear. See SMPP binds and TPS.
- Pilot: move a small share of live traffic (for example 5 to 10%) and compare delivery and conversion with your existing route.
Reading the results
- Sender ID replaced or content altered usually means the route is indirect or grey for that network. See SMS route types.
- Latency that varies from 2 seconds to several minutes suggests queueing or multiple hops.
- For OTP traffic, the pilot's conversion rate (codes entered vs sent) is the result that matters most.
- Record the results with dates. Routes change, and you will need a baseline when quality drops.
Keep testing after launch
A route that passed in week one can degrade in week six. Schedule small automated tests per country and network every day or every few hours, and alert on changes in delivery rate, latency or DLR distribution. What to track is in SMS delivery rate and latency.
Getting a route to test
VoIPMatcher sources A2P SMS routes from its carriers and works with you on testing before traffic starts. Request an SMS route with the countries and networks you want to test.
Frequently asked questions
How do I test an SMPP connection?
Bind with the credentials and IP address the supplier whitelisted, using an SMPP client or your own platform. Check that the bind succeeds, that enquire_link keeps it alive, and that a test submit_sm returns status 0 with a message ID. Then confirm that delivery reports arrive on the bind and match what the test handset receives.
What is an SMS testing tool?
An SMS testing tool sends messages to real SIM cards on networks in the destination country and reports what arrived: sender ID, text, encoding and delivery time. It replaces having your own phones in every country. Use it together with your delivery reports, because the comparison between the two is what exposes route problems.
How many test messages should I send?
For a functional test, 10 to 20 messages per network is usually enough to check delivery, sender ID, content and latency. Repeat at peak and off-peak hours over several days. After that, move a small share of live traffic, for example 5 to 10 percent, and compare conversion with your existing route before scaling.
Is a free SMS test enough to judge a route?
No. A few free test messages show that a route can deliver, not that it will keep delivering your real traffic. Routes can change path when volume grows, and some block brand names or OTP templates that a generic test message would pass. Test with your real sender ID and content, then run a pilot.
Need a route?
Send the destination, route type and target rate. We reply with what we can deliver.