Does a message in the report prove it was sent or received?¶
title: Does a message in the report prove it was sent or received? subtitle: The content may be present while the direction, submission, delivery or receipt status still needs interpretation. slug: does-a-message-in-the-report-prove-it-was-sent-or-received series: mobile-extraction-and-reader-reports section: interpreting-common-artefacts card_type: question_card content_type: core-operational risk_level: high-risk pathway_order: 29 section_order: 4 status: draft owner: IF Digital last_updated: '2026-07-25' version: '0.1' review_gate: pending review_mode: ai-assisted review_timebox_mins: 60 qa_gate: pending qa_count: 0 pipeline_ref: PIPELINE_PRG_001 pipeline_version: '1.1' public_safe: true video_ready: true word_count: 468 estimated_read_time_seconds: 194 audiences: - investigator - supervisor - fraud and compliance practitioner tags: - mobile evidence - messages - direction - delivery status - interpretation sources: - title: SWGDE Best Practices for Mobile Device Forensic Analysis url: https://www.swgde.org/documents/published-complete-listing/20-f-005-swgde-best-practices-for-mobile-device-forensic-analysis/ - title: 'NIST SP 800-101 Rev. 1: Guidelines on Mobile Device Forensics' url: https://csrc.nist.gov/pubs/sp/800/101/r1/final - title: 'NIST Computer Forensics Tool Testing: Mobile Devices' url: https://www.nist.gov/itl/csd/secure-systems-and-applications/computer-forensics-tool-testing-program-cftt/cftt-7
Does a message in the report prove it was sent or received?¶
The content may be present while the direction, submission, delivery or receipt status still needs interpretation.
Script¶
A message displayed in a mobile report proves that message-related data was present in the acquired and processed source.
It does not always prove that the message was successfully sent or received.
Start with the application and source.
Was the record taken from the active message database, a draft store, notification, cache, backup, database journal or recovered fragment?
Does the artefact expose direction and status fields?
Which account and participants are linked to it?
A composed message may be saved as a draft.
A message may be queued locally while the device has no network connection.
An outgoing record may show that the application attempted to submit it.
The service may later mark it sent, delivered or read.
An incoming notification may show that a server pushed a preview to the device even if the complete message database was not acquired.
A recovered fragment may preserve the text while losing the direction or status.
Different applications use different status models.
The forensic tool may translate numeric values into friendly words.
Where the exact status matters, the examiner may need to validate the source field and application version.
Don't infer direction from the order in which messages appear on screen.
Conversation views may colour or align messages, but exports can lose that presentation.
The stored account identifier and direction field are stronger.
Also distinguish device evidence from provider evidence.
A handset record may support that the local application stored an outgoing message with a sent status.
Provider or recipient-side records may be needed to establish that the service accepted or delivered it.
The recipient’s device may independently preserve the incoming copy.
These layers strengthen one another.
Beware of synchronisation.
A message sent from a linked computer or another handset may appear in the mobile application’s conversation after cloud synchronisation.
The phone may store the message even though it was not the device used to compose or submit it.
Likewise, a received message may synchronise to several devices.
The presence of the record does not prove which device was first involved.
The common mistake is:
“The message is in the extraction, so the phone sent it.”
The extraction may show that the account history synchronised the message to the phone.
Another mistake is:
“There is no delivery tick in the screenshot, so it was never received.”
The screenshot may omit the relevant status, and the application database or provider may hold stronger evidence.
A careful conclusion might say:
“The active application database records this message as outgoing from account A to account B with a sent status at this time.”
If delivery matters, add the supporting source:
“The recipient device contains the matching incoming record.”
Or:
“The provider recorded delivery.”
A message artefact can be powerful evidence.
Keep the conclusion tied to its state, account, source and device relationship.
Key takeaway
Identify the message state, account, participants and source before describing the communication as sent, delivered or received.
Related questions¶
- What is the difference between draft, queued, sent, delivered and read?
- What does an application artefact actually show?
- Why might one conversation appear in several places?
Source notes¶
- SWGDE Best Practices for Mobile Device Forensic Analysis
- NIST SP 800-101 Rev. 1: Guidelines on Mobile Device Forensics
- NIST Computer Forensics Tool Testing: Mobile Devices