D3EMAIL FORENSICSD3 Forensics Limited

Site search

Find a clear explanation.

Search pages, FAQs, glossary terms and provider entries. Your query stays in this page and is not sent to a search provider.

Original content baseline 6 November 2026 · Content revision 0.3

Pages

Clarity in the email evidence

Specialist email examination for disputes and investigations. Understand what the evidence may establish, its limits and the next steps.

Pages

Email authenticity and alteration

Examine whether a disputed message is consistent with its claimed origin and history, and identify what the available evidence cannot resolve.

Pages

Deleted or missing email

Assess whether relevant correspondence survives and distinguish recovered deleted material from copies found elsewhere.

Pages

Mailbox comparison and chronology

Compare supplied message sets, explain differences and reconstruct relevant sequences without assuming either collection is complete.

Pages

Attachments and linked material

Assess attachment versions and their relationship to messages, while treating cloud links as a separate historical evidence question.

Pages

Microsoft 365 & Exchange email evidence

A business mailbox can be one of several evidence sources. Assess the messages, administrator records, endpoints and retention history separately before deciding what can be established.

Pages

Google Workspace email evidence

Google Workspace evidence depends on the organisation's configuration, access rights and retention history. Gmail content, Vault material and administrative records answer different questions.

Pages

Personal Gmail evidence

An authorised personal Gmail export or a surviving device copy may help answer an evidential question. It does not provide the organisation-level sources available in a managed Workspace environment.

Pages

Linux & self-hosted mail systems

Linux identifies an operating system, not a mail system. A useful examination starts by mapping the components that received, stored, delivered and displayed the relevant messages.

Pages

Apple Mail & iCloud email evidence

iCloud Mail is an email service. Apple Mail is an application that can access iCloud and other providers. The account, local material and backups should be assessed as separate sources.

Pages

What email headers can tell you

Headers can help explain addressing, routing and message handling. Interpretation depends on which system created each field and whether that part of the record can be trusted.

Pages

Why email timestamps can disagree

A message can carry several times for different events. A useful chronology identifies each event, preserves the source value and states the display timezone.

Pages

Message-ID and email threading

Identifiers and reply references can help reconstruct conversations. They do not establish authenticity or guarantee that every message in a conversation has survived.

Pages

mbox and Maildir evidence

These mailbox storage approaches organise messages differently. Preserve the surrounding context as well as the apparent message content.

Pages

Deletion, retention and holds

Deleting a message from view is not always the same as permanently removing every surviving copy. Equally, a later hold cannot be assumed to recreate material already lost.

Pages

Google Workspace and personal Gmail

A familiar Gmail interface can sit behind different account arrangements. The available administrative, retention and export sources must be identified for the specific account.

Pages

Exchange Online and Outlook.com

Exchange Online is a managed business service. Outlook.com is a consumer email service. Outlook also names client applications, so the name alone is insufficient to define an examination.

Pages

Shared mailboxes and delegated access

A message appearing to come from a mailbox does not establish which person operated it. Shared access, delegation and automation must be considered.

Pages

Email spoofing or account compromise?

A misleading sender identity and unauthorised use of a real account are different explanations. Investigation should test both rather than decide from appearance alone.

Pages

How migration can affect email evidence

Migration can change storage, identifiers and presentation. Differences between old and new copies require explanation before they are treated as deliberate alteration.

Pages

Hashes and chain of custody

A cryptographic hash helps compare bytes. A custody record explains handling. They support different parts of an evidence account and neither proves that an email's contents are true.

Pages

Encrypted email: access routes and limits

Encryption must be assessed at the correct layer. A provider's storage protection, end-to-end encrypted content and a password-protected attachment present different access questions.

Pages

What to prepare for a first consultation

Begin with the evidential question, the relevant systems and the material you already hold. A concise factual outline is more useful than sending an entire mailbox without an agreed procedure.

Pages

Examination shaped by the question

Define what needs to be established before choosing the collection or analysis method. Scope, authority and feasibility are agreed for every instruction.

Pages

Find the relevant email environment

Distinguish the hosting service from the application and the available evidence source. Start with a core platform or explore the provider directory.

Pages

Start with the situation

These are hypothetical instruction types, not client case studies. Each identifies possible sources, preservation considerations and limits.

Pages

Other providers & legacy systems

An enquiry directory of providers, archives and older systems. Inclusion is not confirmation of live access, extraction support or deleted-data recovery.

Pages

Frequently asked questions

42 practical answers on email authenticity, preservation, missing messages, available sources and the engagement process.

Pages

Email evidence glossary

75 email and forensic terms explained, with practical evidential limitations and related guidance.

Pages

Evidence source matrix

A dated source-by-source assessment of potential email evidence, prerequisites, retention dependencies and interpretation limits.

Pages

Look beyond a single mailbox

Messages, activity records and surviving copies answer different questions. Their provenance and collection scope matter as much as their content.

Pages

Preserve the available evidence

Proportionate first steps while an authorised collection plan is agreed. There is no universal instruction to switch off devices or disconnect every account.

Pages

Prepare for the first discussion

A concise description helps establish whether an examination is feasible. Keep passwords and full evidence out of the initial enquiry.

Pages

Website terms & scope

The website explains potential sources and examination approaches. Any professional instruction requires a separately agreed scope.

Pages

Content source register

Primary references, their checked dates, scope and limitations. Provider documentation is separate from confirmation of D3 capabilities.

FAQs

What is email forensics, and how does it differ from ordinary IT support?

Email forensics examines email material to address an evidential question, such as whether two message versions differ or what a surviving record supports about transmission. It involves documenting sources, collection methods, interpretation and limitations. Ordinary IT support usually aims to restore a working service. The two activities can overlap, but repair, migration or account changes may alter evidence. A forensic instruction therefore begins with the question, lawful authority and an appropriate preservation plan.

FAQs

Can you examine a single disputed email rather than an entire mailbox?

A single message can be the starting point for an assessment. Native message data, its attachments and the circumstances of its collection are more informative than a screenshot alone. The disputed point may nevertheless require recipient copies, surrounding correspondence or independent logs. A narrowly scoped examination can report what that item supports, while explicitly identifying questions that cannot be answered without wider material. The appropriate scope is agreed before full examination.

FAQs

Which email providers and file types can you assess?

The platform pages describe potential evidence from Microsoft, Google, self-hosted systems, Apple clients and other providers. Common supplied formats include EML, MSG, PST, mbox and Maildir, although file condition, encryption and software version affect examination. A provider appearing in the directory is an enquiry category, not a promise of live access or recovery. The initial assessment must establish the actual source, available authority and a feasible examination route for the material concerned.

FAQs

Do you examine both business and personal email accounts?

Both business and personal email may contain relevant evidence. Their available sources can differ substantially: a managed business tenant may have administrator records or preservation features that a consumer account does not provide. Access to an account is not, by itself, sufficient authority to examine every person's correspondence. The proposed work needs an identifiable evidential purpose, an authorised scope and consideration of confidential or privileged material. Feasibility is assessed for the particular account and available copies.

FAQs

Can you work with our solicitor, internal IT team or existing investigator?

An email examination can be coordinated with the people already responsible for the matter. The instruction should identify who can authorise access, provide system information, approve scope and receive findings. IT staff can often clarify retention, migration and account configuration; legal advisers can address authority, disclosure and privilege. Roles and necessary operational changes should be recorded so that collection is understandable and repeatable. Any expert-evidence work requires its own agreed scope and reporting requirements.

FAQs

What information is needed before you can assess feasibility?

Start with the question to be answered, the relevant date range, the provider and whether the account is business-managed or personal. Identify the available devices, native messages, exports, archives and backups, together with any deletion, migration or repair history. State who controls the sources and any known deadline. A brief description is sufficient for an initial enquiry. Do not send passwords, recovery keys, one-time codes or full evidence through the general contact channel.

FAQs

What permission or authority is required to examine an account?

The required authority depends on the account, its ownership and administration, the people affected and the proposed work. Possessing a password does not establish unrestricted permission to collect or examine correspondence. Before collection, the instruction should identify the authorising party, permitted sources, purpose and scope. Employer, employee, shared-account and cross-border questions may require legal advice. D3's acceptance of an instruction must not be treated as a determination of every legal issue affecting access or disclosure.

FAQs

Can you work with historical or discontinued email systems?

Historical material may remain examinable through original stores, exports, backups or associated records, even when the original service is no longer operating. The format, software version, encryption and condition of the data must first be established. An old product name alone does not confirm an available extraction method. Preserve original media and existing copies before attempting conversion or repair. A feasibility stage can identify supported routes and any information lost through earlier migrations.

FAQs

Can an email be edited or fabricated?

Yes. Message files, displayed content and screenshots can be altered or created, while legitimate forwarding, export and migration can also change a message's representation. Examination considers native structure, headers, attachments and corroborating copies or records. An inconsistency may support several explanations and should not automatically be labelled fabrication. The appropriate conclusion describes the observed differences, the reliability of the available sources and the limits of any opinion about provenance or alteration.

FAQs

Can you determine who personally wrote or sent a message?

Email evidence can sometimes support an attribution assessment, but an account name or successful login does not conclusively identify the person operating it. Shared access, delegation, automated systems and compromised credentials may provide alternative explanations. Message records can be considered alongside available account, device and contextual evidence. Any conclusion must distinguish the recorded account, the apparent sending mechanism and the human author, and explain both supporting evidence and unresolved possibilities.

FAQs

Does a valid DKIM signature prove an email is genuine?

No. A valid DomainKeys Identified Mail signature supports a narrower conclusion about signed content and a signing domain under the applicable verification conditions. It does not establish the human author, the truth of the message or the legitimacy of a payment instruction. Not every header is necessarily signed, and interpretation depends on the signature's coverage and the available verification material. Domain authentication is one part of a wider examination, not a standalone authenticity verdict. Later verification can also differ from the receiving system’s original result. A signing key may have been removed or revoked, or the preserved message may differ from the representation originally checked. Record the verification date, method, available key material and signature coverage. An unavailable or failed later check should not, on its own, be described as proof that the original message was fabricated.

FAQs

Can I rely on an Authentication-Results header saying dkim=pass?

Not without establishing where that result came from. Authentication-Results records checks reported by a receiving system; a similar-looking field can be inserted into supplied message data. Identify the reporting service, its trust boundary and how the message was preserved. A result from a trustworthy receiver can support the recorded authentication assessment, but it does not independently identify the human author or establish that the message was truthful. Preserve the native message and supporting receiver records where available.

FAQs

Does a failed SPF or DMARC check prove fraud?

No. Authentication failures can arise from configuration, forwarding, message modification or a genuinely unauthorised sending route. Sender Policy Framework and Domain-based Message Authentication, Reporting and Conformance assess particular domain and transport relationships; they do not determine intent or human identity. The result, its recording system and the circumstances of evaluation need examination. A failure can be relevant evidence, but it should be tested against message routing and other available records before drawing conclusions about fraud.

FAQs

Can screenshots or a PDF be examined if the original message is missing?

Yes. They can show what was presented and may assist with chronology, visible differences or a disputed statement. They usually omit parts of the underlying message structure and may not preserve transport information or attachments in their original form. Keep the submitted material unchanged and record how it was obtained. An examination should describe these limitations and look for independent corroboration, including recipient-held copies, exports or system records, rather than treating the image as a complete original.

FAQs

Can you prove that an email was delivered or read?

Available records may support submission, delivery or a later message-handling event, but those are different propositions. A delivery status notification reports a transport outcome. A message disposition notification may report that a mail application displayed or otherwise processed the message. Even a displayed result does not guarantee that a named person read or understood it. Preserve the original notification and relate it to the message, recipient and reporting system. The conclusion should state the event actually supported and any uncertainty about personal receipt or awareness.

FAQs

Why do timestamps differ between a mailbox, a header and an export?

Different fields can describe different events, such as composition, transport, delivery, storage or export. A client may also display a time in its local timezone, while the underlying value uses another offset. Clock errors, migration and conversion can introduce further differences. Analysis should retain original values and offsets, identify the meaning of each field and state the timezone used for any combined chronology. A time discrepancy alone does not establish alteration or dishonesty.

FAQs

Can you identify a forged attachment or changed bank details?

Comparison can establish differences between available message or attachment versions and may help identify where a payment instruction changed. Relevant sources include native messages, attached files, recipient copies and available account or gateway records. A changed file does not by itself identify who changed it or prove fraudulent intent. The assessment must distinguish observed differences from inferences about their origin, and consider whether a linked document could have changed separately from the email containing its link.

FAQs

Can you establish whether a message was written using AI?

Text alone does not provide a reliable basis for conclusively identifying AI authorship. Automated detectors and stylistic similarities should not be presented as proof that a particular message was generated by AI or written by a named person. Other evidence, such as an authorised account record or a preserved drafting history, may be relevant if available. The report should distinguish direct observations from inference and explain alternative explanations rather than assign an unsupported authorship score.

FAQs

Can an email's IP address identify the person or their precise location?

Usually not on its own. An IP address in a message or log may identify a server, intermediary or network connection rather than the sender's device. Shared networks, virtual private networks, proxies and service infrastructure complicate interpretation. Geolocation results are estimates and are not proof of an exact physical address. Attribution requires context, an assessment of the record's provenance and appropriate corroboration; a recorded IP address alone is not conclusive personal identification.

FAQs

Why can two genuine copies of a message have different hash values?

A cryptographic hash describes the bytes of the particular file being hashed. Two representations of the same communication can differ because of added transport headers, line endings, export formatting, container structure or other transformations. Their whole-file hashes can therefore differ without proving that the substantive communication was fabricated. Conversely, matching hashes support byte consistency, not authorship or truth. Source exports and derived files should be hashed separately, with the algorithm and comparison basis recorded.

FAQs

What does it mean if an expected message is not found?

It means the message was not located within the sources and search conditions examined. It does not automatically prove that the communication never existed. Missing results may reflect deletion, limited retention, an incomplete export, indexing gaps, encryption, permissions or search criteria. A useful report identifies the examined population, methods and known omissions, then considers other surviving sources. The strength of a negative finding depends on how completely those sources address the question being asked.

FAQs

Can deleted emails be recovered, and what affects the prospects?

Sometimes, but recovery cannot be guaranteed. Relevant factors include the service, deletion state, retention and hold settings, local storage, encryption, backups, subsequent use and the time of examination. A surviving recipient copy or archive may fill a gap without constituting recovery from deleted structures. The initial assessment should identify which sources remain available and distinguish an actual recovery method from locating another copy. Data that has been irretrievably purged or overwritten may no longer be obtainable.

FAQs

Can material be recovered after Trash or Deleted Items has been emptied?

Possibly, depending on the system and circumstances. Emptying a visible folder does not have the same technical effect on every service or local store. Other retention mechanisms, backups, archives or correspondent copies may exist, but their presence must be established. Do not assume an enterprise recovery feature applies to a personal account. Avoid restoring or repairing over the only surviving material; record what happened and obtain source-specific advice before further changes.

FAQs

Can a deleted employee mailbox still contain retrievable evidence?

It may, depending on the platform, account lifecycle and preservation arrangements already in place. Possible sources include retained mailbox data, authorised archives, backups, local copies and other correspondents. Deletion of an employee's account does not by itself establish either complete destruction or continued availability. The administrator should provide the relevant dates, configuration and changes. Creating a hold later must not be assumed to recreate material already irretrievably purged, and collection still requires appropriate authority.

FAQs

Does Microsoft 365 retain every message indefinitely?

No universal assumption of indefinite retention is justified. What survives depends on the applicable service, mailbox state, permissions and configured retention or preservation features. Mailbox content, audit records and message-tracing information are separate sources and can have different availability. An assessment should establish the tenant's actual configuration and the relevant event history. A current setting does not necessarily describe the setting at the material time, and preservation applied today cannot be assumed to restore previously lost data.

FAQs

Does Google Vault contain all deleted Gmail messages?

No. Google Vault should not be treated as a universal backup or a guarantee that every deleted message survives. Availability depends on the organisation's entitlements, relevant accounts, configured retention and holds, and the history of the material. Vault and the live mailbox are distinct evidence sources whose search and export limitations must be recorded. A later preservation action does not necessarily recreate previously purged messages, and personal Gmail accounts should not be assumed to have Workspace preservation facilities.

FAQs

What is the difference between Google Workspace and personal Gmail evidence?

Google Workspace is administered within an organisation, while personal Gmail is a consumer account service. The distinction matters because administrator records, permissions and preservation options are not interchangeable. Both may have authorised exports or local copies, but an export is not automatically the full account history. The assessment should identify the actual account type, available administrator access and relevant configuration before proposing collection. A Gmail address or familiar interface alone does not establish which additional sources exist.

FAQs

Can you examine a PST or OST file without access to the live account?

A supplied local file may provide an examination route independent of live account access, subject to its format, condition, protection and contents. A PST and an OST serve different purposes, and neither should automatically be treated as a complete historical mailbox. A cached file may contain only a subset of synchronised data. Preserve the original file and its context before conversion or repair. Feasibility and the limitations of any derived output should be assessed against the actual file.

FAQs

Can you investigate Linux mail servers or Maildir and mbox data?

These sources can be considered where authorised access and a feasible examination method exist. Linux identifies an operating system, not a single email platform: transport software, mailbox services, webmail and stored formats must be identified separately. Maildir and mbox can contain message data, while available logs, queues, archives and backups may answer different questions. Configuration, rotation and subsequent activity affect completeness. The proposed examination must be based on the actual components and preserved material, not the server label alone.

FAQs

Can you assess Proton Mail, Tuta or other encrypted email?

An assessment can consider available authorised exports, accessible local copies and relevant metadata. The provider name does not establish access to message content or deleted data. Different arrangements, including end-to-end encryption, S/MIME, OpenPGP and protected attachments, have different access requirements. A feasible route may require valid credentials, keys or an already accessible copy. No claim of defeating encryption is made, and the directory does not confirm a validated acquisition method for every listed service.

FAQs

Can archives, backups or another person's mailbox fill a gap?

They may contain surviving copies or records absent from the main mailbox. Their coverage, creation dates, retention and provenance need examination, and access must be authorised. A backup may reflect only one point in time; an archive may cover selected traffic; a recipient copy may include different transport information. Finding such material can be valuable, but it should be reported as a surviving copy from that source, rather than automatically described as recovery from deleted mailbox structures.

FAQs

Are cloud-linked documents included in a mailbox export?

Not necessarily. A message may contain a link or reference to a document held in a separate service, rather than the document's bytes. Access permissions, historical versions and the state of the document at the relevant time are separate questions. A current download may differ from what was previously available to a recipient. Preservation should therefore identify the linked service and available version history, with suitable authority, instead of assuming the mailbox export includes the historical document.

FAQs

Can smartphone and computer evidence corroborate email findings?

Potentially. Devices may hold local message data, attachments, application records or other artefacts relevant to a particular question. Their presence and completeness depend on the application, synchronisation, retention, encryption and subsequent use. An account visible on a device does not guarantee that all historical correspondence is stored there. Device examination should be separately scoped and authorised, then correlated carefully with mailbox and server evidence without treating every device timestamp as the same kind of event.

FAQs

Will collection change the account, its read status or its audit records?

Some collection methods can create access records or affect account state, while others work from existing exports or preserved copies. The effect depends on the service and method and must not be assumed away. The collection plan should identify foreseeable changes, minimise unnecessary interaction and record settings, times, errors and relevant actions. Necessary operational containment may also change evidence. Those changes should be coordinated and documented so that later interpretation can distinguish collection activity from the events under examination.

FAQs

What should I preserve, and what should I avoid changing?

Retain original material and record what happened, including dates, account changes and any previous collection or repair. Avoid unnecessary deletion, compaction, migration, conversion or restoration over the only surviving copy. Preserve available context such as export settings and correspondence about how files were supplied. There is no universal instruction to disconnect accounts or power devices down. Where compromise is active, coordinate evidence preservation with authorised account protection and containment, and document necessary changes.

FAQs

How do you protect confidential, personal or potentially privileged material?

Handling arrangements should be agreed before evidence transfer, including authorised recipients, scope, access restrictions and any review or segregation requirements. Potentially privileged material should be identified with the instructing legal advisers; labelling it privileged does not establish its legal status. The initial enquiry should contain only the information needed to assess the matter. Detailed transfer and retention arrangements require confirmation for the engagement. Do not send full mailboxes, passwords or recovery material through an ordinary website enquiry.

FAQs

How are scope, costs and timescales agreed?

They are established from the question, available sources, volume, condition, access requirements and reporting needs. A limited feasibility stage may be appropriate before committing to a wider examination. The written scope should identify proposed work, exclusions, deliverables and the basis on which additional work would be agreed. This website does not offer fixed recovery prices or guaranteed turnaround times. Any relevant court, commercial or preservation deadline should be disclosed at the outset so that feasibility can be assessed realistically.

FAQs

Can you guarantee recovery or a conclusive authenticity opinion?

No. The available evidence may be incomplete, altered through ordinary processing or incapable of resolving the disputed point. Recovery depends on the source and its history; an authenticity assessment may identify consistencies, discrepancies and competing explanations without supporting a binary genuine-or-fake answer. The purpose of the assessment is to establish what the evidence reasonably supports and to report the limits openly. An inconclusive finding can still clarify which propositions remain unproven and what further evidence would be useful.

FAQs

What reports, schedules and native files might be delivered?

Depending on the agreed scope, outputs may include a feasibility opinion, acquisition record, technical report, evidence schedule and identified native or derived files. A schedule can record sources, item identifiers, filenames, recorded correspondents, timestamps, attachments and hashes where available. Bcc, envelope recipients and deletion state are source-dependent fields. The report should explain methods, transformations, omissions and limitations. An expert report or testimony requires separate instruction and should not be assumed to form part of every examination.

FAQs

Can your findings be used in court or an expert-witness instruction?

An examination can be scoped to assist legal proceedings, with methods, sources and reasoning documented for scrutiny. The appropriate report and any expert role should be agreed with the instructing legal advisers, taking account of the relevant forum and issues. A report's label does not guarantee admissibility, privilege or acceptance by a court. Conclusions must remain within the evidence and the practitioner's expertise, and expert-evidence duties must be considered separately from a client's preferred outcome.

FAQs

How should I contact you, and should I send passwords or evidence initially?

Use the contact page to provide a short description of the issue, the relevant provider, the available sources and any deadline. Do not send passwords, one-time codes, recovery keys or complete evidence through a general enquiry channel. Identity, authority, conflicts and scope should be addressed before an appropriate transfer arrangement is agreed. This website has no evidence-upload facility, and sending an enquiry does not by itself establish an engagement or an undertaking to act.

FAQs

How do I know whether D3 has received my enquiry?

If the website offers a form, a confirmation from the form service means it accepted the submission. Contact D3 directly if you need to verify receipt. An email link opens a draft, which you must send from your email application. For an urgent deadline, use the published contact details and explain the timing. An enquiry alone does not create an engagement.

Glossary

Microsoft 365

Microsoft's collection of subscription services, which can include organisational email and associated administration features. The subscription name alone does not establish available licences, logs, retention or collection permissions.

Glossary

Exchange Online

Microsoft's hosted organisational email service. Mailboxes and administrative records can provide different evidence sources. A mailbox export is not automatically a complete account history or an export of all tenant logs.

Glossary

Exchange Server

Exchange software operated on an organisation's infrastructure, potentially alongside hosted services in a hybrid arrangement. Version, configuration, storage condition and available backups determine the examination route.

Glossary

Google Workspace

Google's managed organisational service environment, which can include Gmail and administrator-controlled features. Workspace capabilities must not be assumed to exist for personal Gmail or every organisational subscription.

Glossary

Gmail

Google's email service, available in personal accounts and within Google Workspace. The familiar interface does not identify the account's administrative or preservation capabilities.

Glossary

email client

Software used to access and manage email, such as Outlook, Apple Mail or Thunderbird. The client is distinct from the hosting service and may retain only selected or cached material.

Glossary

webmail

An interface for accessing email through a web browser. The web interface does not establish where complete mailbox content or historical records are stored.

Glossary

tenant

An organisation's administered environment within a cloud service. Tenant membership does not confer unrestricted authority or technical access to every account and record.

Glossary

mailbox

A logical store of messages and associated folders or labels for an account or shared purpose. Its present contents may exclude deleted, archived, unsynchronised or separately retained material.

Glossary

shared mailbox

A mailbox intended for use by more than one authorised person or process. A message associated with it does not, by itself, identify the individual responsible.

Glossary

delegate

A person or account granted permission to perform specified actions on another mailbox. Permission and its scope can change; present delegation does not establish historic use.

Glossary

alias

An additional address associated with a mailbox or routing destination. Several addresses can reach one mailbox, so an address alone is not a separate person or account.

Glossary

OAuth

An authorisation framework through which an application can receive defined access without directly using a user's password. A granted permission or token does not establish who performed every resulting action.

Glossary

multi-factor authentication

Authentication requiring more than one distinct type of evidence of identity. A successful authentication event is not conclusive proof of the human operator or subsequent message authorship.

Glossary

IMAP

Internet Message Access Protocol, commonly used by clients to access and synchronise server-held email. A synchronised client may not contain every folder, historical item or provider-side record.

Glossary

POP3

Post Office Protocol version 3, commonly used to retrieve messages from a server. Client settings and earlier retrieval can affect which copies remain on the server or device.

Glossary

SMTP

Simple Mail Transfer Protocol, used for submitting and transferring email between systems. A transfer event does not by itself establish that a person read the resulting message.

Glossary

mail transfer agent

Software that accepts and routes email between systems, such as a transport service on a mail server. Its logs may describe routing without preserving complete message content.

Glossary

mail delivery agent

Software responsible for placing accepted messages into a recipient's mailbox or local store. Recorded delivery is distinct from personal receipt, reading or understanding.

Glossary

mail user agent

The application through which a user composes, reads and manages email; another term for an email client. Its display is a representation of evidence and may omit headers or other underlying data.

Glossary

PST

A Personal Storage Table file used by supported Outlook workflows to store email and other items. A PST can be selective, altered or incomplete; its existence does not prove a full mailbox collection.

Glossary

OST

An Offline Storage Table file used by some Outlook configurations as a local synchronised store. It may contain only cached data and is not automatically an independent, complete historical archive.

Glossary

MSG

A Microsoft message-file format that can hold an individual Outlook item and associated properties. Export and application behaviour affect the properties retained; it is not identical to every transport representation.

Glossary

EML

A common file representation of an email message, typically containing headers, body and MIME-encoded parts. The extension does not authenticate provenance or establish that all original transport information survives.

Glossary

EMLX

A message storage format associated with Apple Mail, containing message data and additional storage information. A single file may require surrounding store context to interpret associated state and attachments correctly.

Glossary

mbox

A family of mailbox formats that store multiple messages sequentially within a file. Variants and export transformations require care when identifying message boundaries and interpreting metadata.

Glossary

Maildir

A mailbox storage approach using individual message files arranged in defined directories. Filenames and directory states require system-specific interpretation and do not alone prove user actions.

Glossary

NSF

A Notes Storage Facility database format associated with Notes and Domino applications, including mail. Version, access controls, encryption and database condition affect feasible examination.

Glossary

MIME

Multipurpose Internet Mail Extensions, rules for representing email content such as different text encodings and attachments. Equivalent displayed content can have different encoded bytes, affecting comparisons and whole-file hashes.

Glossary

header

A structured message field recording information such as addresses, subject, dates or transport details. Individual header values may be supplied or modified by different systems and are not uniformly trustworthy.

Glossary

envelope

The sender and recipient information used during message transport, distinct from the addresses displayed in the message. A saved message does not necessarily preserve the complete transport envelope.

Glossary

Message-ID

An identifier generally intended to distinguish a message and assist with referencing or conversation grouping. It can be duplicated, missing or fabricated and does not independently authenticate a message.

Glossary

In-Reply-To

A header that can identify the message to which a reply relates. Its presence supports a stated relationship, not proof that the referenced original is authentic or available.

Glossary

References

A header that can list message identifiers associated with a conversation's earlier messages. Thread reconstruction can remain incomplete or misleading where identifiers are missing or inconsistent.

Glossary

Return-Path

A header commonly recording a transport return address used for delivery-related notifications. It need not match the visible From address and does not identify the human author.

Glossary

Received header

A header added by a mail-handling system to describe a transport step and associated time information. Trust depends on the system that added it and the preserved context; an entire chain is not automatically reliable.

Glossary

Bcc

Blind carbon copy, used to address recipients without displaying them to all other recipients in the ordinary message view. Bcc information may be absent from recipient-held copies and cannot be assumed available in every export.

Glossary

attachment

A file or other item included within a message's stored or transmitted content. A displayed filename does not establish the file's content, provenance or authorship.

Glossary

embedded message

An email included as an item inside another message, rather than merely quoted as text. Its inclusion does not independently verify its origin or prove it was previously transmitted.

Glossary

cloud attachment

A reference or link to a file stored in a separate online service, presented as part of an email workflow. The current linked file may differ from the version accessible at the relevant time.

Glossary

SPF

Sender Policy Framework, a mechanism for checking whether a sending system is authorised for an evaluated domain. It does not establish human authorship or the truth of message content.

Glossary

DKIM

DomainKeys Identified Mail, a mechanism using a domain-associated signature over selected message elements. A valid result concerns signed elements and verification conditions, not every header or the human author.

Glossary

DMARC

Domain-based Message Authentication, Reporting and Conformance, a framework relating domain authentication and alignment to handling policies. Pass or fail is not a complete finding about fraud, identity or message truth.

Glossary

ARC

Authenticated Received Chain, a mechanism for carrying authentication assessments through participating intermediaries. Interpretation depends on the recorded chain and trust in participating systems; it is not a personal-authorship certificate.

Glossary

digital signature

A cryptographic mechanism for checking signed data against a key and detecting certain changes to that data. Identity, key control, signature scope and verification conditions must be assessed separately.

Glossary

S/MIME

Secure/Multipurpose Internet Mail Extensions, a framework for digitally signing and encrypting message content using certificates. Examination may depend on suitable keys and certificates; a signature does not establish the truth of the content.

Glossary

OpenPGP

A standard for cryptographic protection, including signing and encryption of messages and files. Accessible ciphertext does not imply access to plaintext; keys and signature context affect interpretation.

Glossary

end-to-end encryption

Protection designed so that message content is readable by the communicating endpoints rather than intermediate service operators. Available metadata or exports do not establish that encryption can be bypassed or deleted content recovered.

Glossary

spoofing

Making a communication appear to originate from an identity or address that it does not legitimately represent. Visible address similarity alone does not establish the technical mechanism or the offender.

Glossary

lookalike domain

A domain selected to resemble another name, potentially through spelling or visual similarity. Similarity is an observation; intent, use and control require supporting evidence.

Glossary

business email compromise

Misuse of business communication or related identities to facilitate deception, often including payment diversion. The description does not establish whether an account was accessed, an address spoofed or a particular offender identified.

Glossary

forwarding rule

A mailbox instruction that redirects or copies messages meeting specified conditions to another destination. A current rule does not alone establish when it was created, who created it or every message affected.

Glossary

audit log

A record of selected events generated by a system for administration or accountability. Coverage, permissions, event meaning and retention differ; absence from a log is not automatically absence of activity.

Glossary

message trace

Provider or transport records describing selected stages in a message's processing or delivery. A trace may omit message content and does not establish that a named person read it.

Glossary

timestamp

A recorded date and time associated with a particular event or property. Its meaning, clock source and timezone must be identified before combining it with other times.

Glossary

UTC

Coordinated Universal Time, a common reference used when comparing events across timezones. Converting display times to UTC does not correct inaccurate clocks or establish the event represented.

Glossary

timezone offset

The stated difference between a local time value and UTC, such as plus eight hours. An offset is not a precise physical location and may depend on date-specific clock rules.

Glossary

read receipt

A notification associated with a client or service reporting a message-handling event commonly described as reading. It does not conclusively prove that a named person read or understood the content.

Glossary

retention policy

Rules governing how long specified material is kept and when it may be removed. Actual survival depends on scope, configuration and history; a present policy does not prove past preservation.

Glossary

legal hold

A preservation instruction or configured mechanism intended to retain relevant material for a legal matter. Its technical effect is source-specific and cannot be assumed to recreate irretrievably purged data.

Glossary

Recoverable Items

An Exchange storage area associated with particular deletion and preservation behaviours. Its contents and accessibility depend on mailbox state, configuration, permissions and retention history.

Glossary

journal

A separately maintained record or copy of selected email traffic under a configured journalling arrangement. Coverage must be established; a journal is not automatically a complete record of every communication.

Glossary

archive

A store used to retain email outside, or in addition to, its ordinary working location. The term describes many arrangements with different selection, retention and export properties.

Glossary

backup

A copy made to support restoration or resilience, often reflecting a particular point in time. It may be incomplete, overwritten or unsuitable for answering every historical question.

Glossary

forensic acquisition

A documented process for obtaining evidence while recording the method, scope, integrity checks and relevant limitations. A cloud export is not automatically a complete forensic image or the entire history of an account.

Glossary

chain of custody

Documentation of evidence identification, possession, transfers and handling through the relevant process. A custody record supports provenance and accountability but does not prove the truth of the underlying content.

Glossary

hash value

A fixed-length value calculated from data using a specified algorithm, commonly used to compare byte consistency. Matching hashes do not prove who authored a message or whether its content was true before collection.

Glossary

metadata

Information describing an item or its handling, such as recorded addresses, dates, identifiers and file properties. Metadata can be incomplete or transformed; each field requires source-specific interpretation.

Glossary

deduplication

Identifying items treated as duplicates under a defined comparison method to organise review or production. The comparison basis matters; removing a copy may also remove distinct custodian or contextual information.

Glossary

email threading

Grouping related messages into conversations using identifiers, subject patterns, quoted content or other criteria. A reconstructed thread may be incomplete or incorrectly grouped and requires appropriate validation.

Glossary

parent and child relationship

An association between a containing item and an included item, such as an email and its attachment. Separating items during processing can obscure context unless the relationship is preserved and reported.

Glossary

eDiscovery

The identification, preservation, collection, review and production of electronically stored information for a legal or investigative purpose. Technical processing alone does not determine relevance, privilege, disclosure duties or admissibility.

Glossary

Authentication-Results

A message header carrying a system’s reported results of email-authentication checks. Its evidential value depends on the reporting system and preserved trust context. The presence of pass text alone does not establish that a trustworthy receiver generated it.

Glossary

Delivery status notification (DSN)

A structured report about the delivery status of an email for one or more recipients. Identify the reported action, recipient and reporting system. A transport outcome does not establish that a named person read the content.

Glossary

Message disposition notification (MDN)

A structured report about how a mail application handled a message, such as displaying, deleting or processing it. A displayed notification does not guarantee that the content was read or understood. Assess the notification’s provenance and its relationship to the original message.

Providers

Yahoo Mail

Account material, supplied exports, local copies or backups for assessment. Account history, access status and surviving source format must be established; a provider name is not a recovery commitment.

Providers

AOL Mail

Supplied messages, authorised account material and older client stores. Historical account changes and local export provenance need assessment before completeness can be evaluated.

Providers

Zoho Mail

Available user or organisation-provided exports and administrator material. Organisation access, account edition and the actual export scope must be confirmed.

Providers

Fastmail

Authorised account material, messages and existing local stores. Aliases, domains and client copies must be reconciled to the relevant account and dates.

Providers

Proton Mail

Authorised exports or existing local copies; Proton documents export routes. A supported export route does not establish deleted-data recovery or any ability to defeat encryption.

Providers

Tuta

Material already supplied by an authorised account holder and any feasible export route. Access, keys, client version and export coverage require assessment. Encryption bypass is not offered or implied.

Providers

QQ Mail

Supplied messages, account exports where feasible and existing client material. Account access, authorisation, language and collection restrictions must be established for the particular matter.

Providers

Tencent enterprise mail

Organisation-supplied messages and authorised administrative material for assessment. Consumer QQ access and enterprise administration must not be treated as equivalent evidence routes.

Providers

NetEase 163 / 126

Available authorised messages, exports and local client stores. The precise service, account status and source history require confirmation before collection is scoped.

Providers

Alibaba Mail

Organisation-provided material and feasible authorised account sources. Administrator permissions, service variant and retained history must be checked rather than assumed.

Providers

Netvigator

Supplied historical messages, backups and client stores, together with accessible account material. An older backup may hold a different population from the current account; provenance and coverage require reconciliation.

Providers

Zimbra

Supplied mailbox material, server stores, archives and backups for assessment. Edition, version, hosting arrangement and export format must be identified before an examination route is confirmed.

Providers

Roundcube

Underlying mailbox service and relevant webmail configuration or artefacts. Roundcube is a webmail client; its web server cannot be assumed to contain a complete mailbox or history.

Providers

Mimecast

Authorised archive exports or gateway records supplied for the agreed matter. Actual product configuration, retained scope and administrator permissions determine what may be available.

Providers

Proofpoint

Available archive, journal or gateway records from the specific deployment. A gateway event is different from preserved message content; the deployed product and source must be identified.

Providers

Enterprise Vault

Existing archive exports and associated metadata for assessment. Archive scope, export transformations and links to original custodians must be documented.

Providers

MailStore

Supplied archive material and any available acquisition records. An archive's existence does not establish that every mailbox or date range was captured.

Providers

Barracuda

Records from the identified archive, backup or gateway product. The product family contains different source types; a brand name alone does not define content or retention.

Providers

HCL Notes / Domino

Supplied NSF databases, exports and backups for format and access assessment. Version, database design, encryption and authorised credentials may affect interpretation and accessibility.

Providers

GroupWise

Supplied mailbox, archive or historical backup material. Legacy version, available software and export provenance must be established before examination is agreed.

Providers

Kerio Connect

Available server stores, exports and backup material for assessment. The storage layout, version and backup completeness require an environment-specific review.

Providers

MDaemon

Supplied messages, server stores and relevant logs or backups. Collection scope must distinguish message content from transport and account-activity records.

Start with the question

Tell us what needs to be established.

A brief account of the issue, the available sources and the relevant dates is enough to begin.

Discuss your matter