A2P SMS Content Integrity: A Guide to Detecting Changes
A practical investigation framework for comparing content at observable stages, recording differences, and separating reported status from evidence of what appeared on a receiving device.
Acceptance, delivery, and integrity are different signals
As an investigation framework, it helps to separate three questions: Did the system accept the request? What delivery status did the route report? What content actually appeared on the device? Each answer requires different evidence.
Acceptance of a request may document that a stage received or processed it, according to that stage’s own records. A delivery status report (DLR) is a status reported by a stage. The evidence available here does not establish whether it confirms the text displayed on the handset. Keep this uncertainty explicit when reporting an incident.
Do not attribute an alteration to the application, gateway, or a later stage simply because a delivery status exists. As an investigation proposal, compare the records available to you and, when possible, evidence obtained from the receiving device.
- As a record-keeping suggestion, retain the request ID and the response from the stage that received it.
- Note the reported status, its source, and the time; do not present it as verification of the visible text.
- If you document evidence from the destination, state how it was obtained and whether it corresponds to the message and device under investigation.
Trace content from the template to the destination
As an operational proposal, map the message’s actual journey through your integration: template and inserted data, the client that prepares the request, API or SMPP connection, gateway, provider or route, and evidence available at the destination. Do not assume that every deployment has the same stages or that you can inspect them all.
At each point under your control, you could record a reference to the template version and a representation of the text sent to the next stage. If an external stage does not expose the content it processed, note that as an observability limit rather than inferring what happened there.
You could define a correlation between internal identifiers and those returned by each system. If you do, restrict access to that correlation and avoid including full phone numbers, one-time passcodes, or personal text in operational records unless necessary. Set retention and access controls appropriate to the data.
- As a traceability exercise, mark each component’s boundaries of responsibility and visibility.
- Consider retaining timestamps and identifiers to relate events, subject to appropriate access and retention controls.
- Record the template version and relevant integration changes, if available.
- Document data that you do not receive from the provider or cannot verify on the handset.
Record references and compare observations carefully
As an instrumentation proposal, you could calculate a cryptographic hash of a defined content representation at points you control and associate it with an event reference. A hash can help compare the representations used in that calculation; it cannot reconstruct the message or, by itself, verify what the handset received. If you choose this approach, document exactly what representation is included. These are general suggestions, not verified capabilities of any particular system.
If available, you could also record values such as length, encoding or alphabet, and segment count as reported or calculated by a component. Keep locally calculated values separate from those reported by a gateway or provider. The evidence available here does not verify how any component calculates or reports these values.
Normalization may hide differences. As an investigation suggestion, compare the exact representation and, if useful, a normalized view with its transformations documented. Retain full content only when necessary, with appropriate access restrictions and a defined retention period. Do not automatically remove spaces, line breaks, accents, or invisible characters.
- If you calculate a hash, note the method and the exact definition of the content being compared.
- Separate locally calculated values from values reported by another system.
- Minimize stored content: consider references or hashes when retaining the full text is unnecessary, and define access and retention controls.
- Avoid recording OTPs or personal data in plain text unless there is a justified need and appropriate safeguards.
Investigate possible substitutions and differences with controlled cases
If two stages show different text, as a proposed analysis method, first compare the exact representations and then, if useful, a normalized view that is easier to read. Identify the first point where the difference appears. If a stage has no record, define the interval that cannot be inspected and do not claim the change occurred there.
You could prepare synthetic tests with authorized, controlled content, such as basic text, accented characters, punctuation, line breaks, and other characters used by your templates. Change one variable at a time and retain results only at stages where they are observable. This may help compare visible differences with reported data, without assuming how that data is generated.
Do not infer how a route behaves from a single test. Repeat the case with new identifiers and document the conditions. A synthetic result describes only what was observed under that configuration and at that time; it does not guarantee the outcome of all production traffic.
- Use harmless test messages; do not include real customer data or active OTPs.
- Compare character by character and record the observed difference, not a cause you have not verified.
- Record encoding, length, and segment data only as reported or calculated, and identify the source.
- If the content is observed only on the phone, document that evidence separately from other systems’ records.
Narrow down the segment with repeatable tests
As a proposed diagnostic approach, design a matrix that varies the route, destination, sender, and content type in a structured way, where those options are available and authorized. Keep other conditions constant and record what changed between runs.
Start by reviewing the available integration records. Then, if necessary, run a controlled test to a device you are authorized to access. Compare the content prepared by the application with what the handset displays and with evidence available from intermediate systems.
An observation from one phone should not be generalized to all recipients. Likewise, a test that does not reproduce the problem does not rule out an intermittent difference or one dependent on an uncontrolled condition. State the exact scope of each conclusion.
- Use a unique reference for each run and retain the test configuration, subject to appropriate data controls.
- Change one dimension at a time to make comparisons easier.
- Separate synthetic tests from real messages and do not send tests to unauthorized recipients.
- Record negative results and the conditions under which they were obtained.
Escalate with evidence and communicate uncertainty
As a proposed operational criterion, escalate the case when you have a reproducible difference, a specific unobservable segment that prevents progress, or conflicting statuses between systems. Include correlatable identifiers, times, route and destination in an appropriate format, template version, non-sensitive test content, and records that you can share securely.
Ask the other party to confirm what content it can observe and at which point in the flow. If it has only a DLR or delivery identifier, ask it to distinguish that signal from a check of the content on the handset. Do not assume that a party can inspect information its system does not expose.
When reporting the result, classify each statement as observed, inferred, or pending confirmation. For example, an application record may support what string that stage recorded; a claim about what appeared on the handset requires device evidence. Attributing a substitution to a stage requires evidence that locates the change there.
- Include a sequence of events with times and identifiers, avoiding unnecessary sensitive data.
- State what evidence is missing and which party may be able to provide it.
- Propose the next verifiable step instead of assigning a cause without evidence.
- Agree with the client on how to protect screenshots, phone numbers, and personal content.
Checklist to prevent regressions
Before releasing changes to a template, integration, or routing condition, you could retain representative test cases and compare results at points where you have visibility. Review the content and any reported or calculated length, encoding, and segment values; do not assume a single field confirms the final text.
After the change, record the deployed version and run authorized tests. If observation ends at an intermediate system, report that limitation; if verified on a device, make clear which device and run were checked.
BulkSMSMarket is building a business platform for discovering, comparing, buying, selling, and managing A2P SMS capacity. The public site describes route discovery and management, HTTP and SMPP connectivity, supplier access, and HLR lookup. These capabilities do not, by themselves, verify the text that appears on a handset.
- Keep a reference to the template and integration version.
- Compare exact and normalized content where appropriate; explain the transformations applied and limit retention of full text.
- Separate encoding, length, and segment values by the stage and source that reports or calculates them.
- Confirm which evidence comes from systems and which comes from a receiving device.
- Document limits, results, and changes before extending a conclusion to other destinations.
Frequently asked questions
Does a DLR confirm that the message arrived with the expected text?
The evidence available for this article does not establish that. Treat the DLR as a status reported by a stage, not as proof of the text displayed on the device. Confirming the visible text would require device evidence linked to that run.
What should you compare when investigating an alteration?
As a proposed investigation method, compare the content representations at observable points and, if useful, a normalized version with documented transformations. Separately identify any encoding, length, and segment data as reported or calculated, and state its source.
Does a content hash prove what the recipient received?
No. A hash can help compare defined representations in the systems where it was calculated. It does not reveal the original text or, by itself, verify what appeared on the handset.
How can you locate the stage where content changes?
As a proposed method, correlate records using identifiers and timestamps, compare the text at each stage under your control, and repeat controlled tests while changing one variable at a time. If visibility is missing between two points, report that interval as unconfirmed.
What information should an escalation include?
As an operational recommendation, include correlatable identifiers, timestamps, test conditions, template version, available records, and a description of the difference. Protect personal data and clearly distinguish what was observed, inferred, and remains to be verified.
Sources consulted
- 3GPP specifications3GPP
- ITU-T E.164International Telecommunication Union
- GSMA resourcesGSMA