White labelling a messaging service is usually presented as a branding exercise, and the branding is the part that carries no risk. What decides whether a white-label programme survives its first customer audit is the authorisation chain behind the sender identity, and that chain is built on hardware and records rather than on a logo.
This guide covers the structural side of white-label SMS gateway hardware: what the label changes about the sender of record, which authorisations have to exist and in whose name, how far customisation can reasonably go, and what a reseller should be able to produce when a customer or a regulator asks who sent a message.
What does white label actually change?
It changes who the recipient sees, not who sends.
The branding changes the identity presented to the recipient, while the obligations attached to the traffic stay with the party operating the infrastructure.
Three things change and one does not. The sender name on the message changes to the reseller’s brand. The commercial relationship changes, because the reseller now sells messaging rather than purchasing it. The support surface changes, because the reseller’s customers raise issues with the reseller. What does not change is the underlying obligation: the party operating the gateway is the party that can be asked to demonstrate consent, registration and logging.
Confusing the two is the most common structural error in a white-label programme. A reseller who believes branding transfers responsibility will build the commercial layer first and the evidence layer later, and the gap becomes visible during the first audit or the first carrier enquiry rather than during normal operation.
Who is the sender of record?
The entity the recipient and the regulator can reach.
Sender identity has two audiences, and a structure that satisfies one may not satisfy the other.
From the recipient’s side, the sender identity is the name or number that appears on the message, and it needs to be recognisable as the brand they dealt with. From the market’s side, the sender identity is the entity responsible for the traffic, which in registration regimes is a named organisation rather than a brand. Where the two diverge without documentation, a recipient complaint or a carrier enquiry produces the same question: who is answerable for this traffic.
The workable structure documents both and shows how they relate. The reseller’s brand appears to the recipient; the registration or authorisation is held by whichever entity is permitted to send in that market; and the relationship between them is recorded rather than implied. That record is what makes the arrangement explicable in a single conversation instead of an investigation.
Where the deployment operates across markets, the numbering conventions that recipients see follow the ITU Recommendation E.164 numbering plan, but sender registration and consent rules are set nationally, so the structure has to be documented per market rather than once for the programme.
What has to be in the authorisation chain?
Three links: consent, registration, mandate.
The chain has to be complete from the end recipient back to the entity operating the hardware, and every link has to be producible.
| Link | What it establishes | What proves it |
|---|---|---|
| End-recipient consent | That the recipient agreed to receive the message | Consent record held by the end customer |
| Customer attestation | That the reseller’s customer warrants consent exists | Contractual term and evidence of the warrant |
| Sender registration | That a sending entity is permitted in that market | Registration or authorisation in the sending entity’s name |
| Reseller mandate | That the reseller may send on the registered entity’s behalf | Written mandate naming scope and duration |
The link most often missing is the last. A reseller operating gateway hardware on behalf of a registered entity needs a written mandate, and the mandate should state the scope: which markets, which sender identities, which traffic types, and for how long. Without it, the arrangement depends on an informal understanding between two organisations, which is not a structure.
Operational practice guidance such as the material published by M3AAWG describes how these obligations are normally handled, and market rules published by bodies such as the CTIA show how the North American framework expresses them. Where the programme is subject to a formal security or governance review, the control structure described in NIST SP 800-53 Revision 5 is a reasonable vocabulary for expressing access control and audit requirements.
How far can branding and firmware be customised?
Branding is unlimited; firmware is a support decision.
The practical boundary is not what can be changed but what can be supported afterwards.
The console and documentation can carry a reseller’s brand without touching behaviour, and that is the safe part of a programme. Firmware customisation is different: a change to the device software creates a build that the vendor may not support, and it introduces a divergence that has to be maintained across every future release. Where a legitimate requirement exists — a default configuration, a restricted feature set, a particular logging format — it should be expressed as configuration where possible rather than as a modified build.
Three questions settle the boundary. Can the requirement be met by configuration rather than code? If not, will the vendor support the modified build through future releases? And if that support ends, what is the migration path back to a standard build? A programme that cannot answer the third question is carrying a permanent maintenance obligation that appears in the operating cost rather than in the purchase price.
What audit trail does the programme need?
One record per message that answers who, for whom, and when.
The audit trail is the part of a white-label programme that is cheapest to build at the start.
A record sufficient for a customer audit or a carrier enquiry carries five fields: the sending identity used, the end customer on whose behalf the message was sent, the originating and destination numbers, the timestamp, and the outcome. Where the device log already records delivery state, carrier latency and retry counts per message, most of that trail exists; the work is joining it to the commercial relationship that explains why the message was sent.
Two design decisions make the trail reliable. Attribute the message at submission rather than at reconciliation, because the information needed to attribute it is available at that moment and may not be later. And retain the record longer than the longest period in which a complaint is likely, which is usually a matter of contractual terms rather than a technical limit.
Where the programme serves several customers from one estate, the trail also has to support separation: a customer should be able to see their own traffic and no other. That requirement usually pushes the programme towards per-customer port groups or per-customer devices, which is a design decision rather than a reporting one.
How should a multi-customer estate be structured?
Allocate by customer, not by availability.
Allocation that follows availability optimises utilisation and makes every later question harder to answer.
The published range spans enough configurations to allocate deliberately, from the 32-port, 32-slot configuration at $1,160.00 to the 64-port model at $1,880.00, with SIM capacity extendable through the SIMPOOL range from 128 slots at $1,800.00. Choosing within that range is a question of how many distinct customer estates the programme serves and how much separation each contract promises.
Three structural patterns are workable. Shared hardware with a customer-per-port-group allocation, which suits programmes where contracts do not promise dedicated resources. Shared hardware with customer-specific SIM groups, which separates identities while sharing radios. Dedicated devices per customer, which is the simplest to explain in a customer’s security review and the most expensive in stranded capacity.
Whichever pattern applies, record the allocation against the customer rather than against the device. When a device is replaced, the allocation should follow the customer rather than having to be reconstructed, and that is only true if the record was keyed on the commercial relationship from the beginning.
What should the agreement specify?
Scope, evidence, and who answers when something goes wrong.
An agreement that describes only commercial terms leaves the operational questions to be settled during an incident.
- Scope of the mandate. Which markets, sender identities, traffic types and time period the reseller may send under.
- Evidence obligations. What each party must produce, and within what period, when a complaint or enquiry arrives.
- Attestation of consent. That the end customer warrants consent exists, and what happens if that warrant proves false.
- Data handling. What message data is retained, for how long, and who may access it.
- Support boundary. Who receives a customer complaint and who investigates it.
- Exit. What happens to identities, registrations and records when the arrangement ends.
Item six is the one that is almost never specified and almost always needed. A white-label arrangement that ends without a plan for the sender identities leaves the reseller unable to continue serving the customers it has acquired, and it leaves the registered entity holding registrations for traffic it no longer sends. Agreeing the exit at the start is cheaper than negotiating it under pressure.
Where the programme also has to satisfy a formal governance or equipment framework, the ITU Telecommunication Standardization Sector publications provide a neutral vocabulary for the numbering and interconnection terminology a mandate tends to reference.
Conclusion
White-labelling changes what the recipient sees, not who is answerable. The structure that survives scrutiny has three properties: a sender identity documented for both audiences, an authorisation chain complete from end-recipient consent through to a written reseller mandate, and an audit trail that answers who sent what on whose behalf. Branding is the easy part; firmware customisation is a support decision with a maintenance cost; and the estate should be allocated by customer rather than by availability.
Where the programme operates across markets, the registration and consent rules differ by country even though the numbering conventions are standardised, so the structure should be documented per market. The published range from the 32-port configuration at $1,160.00 to the 64-port model at $1,880.00, with SIM capacity from $1,800.00, provides enough separation to allocate deliberately rather than by availability.
Document the authorisation chain before the first message is sent. Send your markets, customer count and separation requirements to service@telarvo.com, or review the published configurations on the SK-SMS Gateway pages.
FAQ
Does white labelling transfer responsibility for consent?
No. Branding changes what the recipient sees, while the obligations attached to the traffic remain with the party operating the infrastructure. A reseller should therefore hold a written mandate from the registered sending entity, covering markets, identities and traffic types, and should be able to produce it alongside the consent attestation from its own customer.
Can we put our own brand on the device console?
Console branding and documentation are the safe part of a programme because they do not change behaviour. Firmware changes are a different decision: a modified build may not be supported through future releases, and the divergence has to be maintained. Where a requirement exists, express it as configuration if possible, and confirm the vendor’s support position and the migration path back to a standard build.
What records should a white-label programme keep?
One record per message covering the sending identity, the end customer on whose behalf it was sent, the originating and destination numbers, the timestamp and the outcome. Where the device log already carries per-message delivery state, latency and retry counts, the work is joining that to the commercial relationship. Attribute at submission, because the information is available then and may not be later.
How should several customers share one gateway?
Allocate by customer rather than by availability. The workable patterns are a customer-per-port-group allocation, customer-specific SIM groups that separate identities while sharing radios, or dedicated devices per customer where a contract or security review requires physical separation. Record the allocation against the customer, so it follows them when hardware is replaced.