Producing email as TIFF images
“Produce as single-page TIFF with a Concordance load file” is a sentence that arrives in a production request and means the other side has a review platform and a specification. It is not a preference about file formats. It is a description of what their system can ingest.
This page is about meeting that specification for email specifically, which
behaves differently from the scanned paper the format was designed around.
EML Exhibit images .eml messages to multi-page TIFF at 150 to 600 DPI
as a Pro feature.
The protocol is the specification
An imaged production has more moving parts than a folder of PDFs, and nearly every dispute about one traces back to a specification that was never read closely or never agreed at all. Before imaging anything, the protocol should answer:
| Question | Typical answer | Why it bites |
|---|---|---|
| Resolution | 300 DPI | Re-imaging means re-stamping the whole set |
| Colour depth | Bitonal, colour where relevant | Bitonal destroys markup and highlighting |
| Image format | Single-page TIFF | Multi-page sets have to be split before delivery |
| Load file | Concordance DAT plus OPT | Field order and delimiters are unforgiving |
| Metadata fields | Custodian, date sent, from, to, subject | Comes from the natives, not the images |
| Native carve-outs | Spreadsheets, presentations | Imaged spreadsheets lose formulas |
If it does not answer them, that is a meet-and-confer conversation, not a guess. Guessing costs a redo of everything downstream of the image.
Email is not scanned paper
The TIFF production workflow was built for boxes of documents fed through a scanner. Email breaks several of its assumptions:
Pagination is generated, not inherent. A scanned page exists; a rendered email page is created by the render. Two tools will paginate the same message differently. Image the whole set in one pass with one tool, or the page counts in your load file will not match the images.
Threads duplicate massively. A twelve-message thread quoted at each reply contains the first message twelve times. Imaging every message in full images that content twelve times, and the receiving party pays to review it twelve times. Threading and deduplication are worth doing before imaging, not after.
The header block is the metadata. On scanned paper, metadata is external. On email, sender, recipients and date are both on the face of the document and in the load file, and the two need to agree. They come apart when messages are imaged from forwards rather than from the collected originals.
Attachments have a relationship. A scanned document is a document. An email with three attachments is four documents with a parent-child structure that has to survive into the platform, or the reviewer sees an attachment with no idea what transmitted it.
Resolution, honestly
300 DPI is the answer when the protocol is silent. It is the common specification, it renders the small type in a deeply quoted thread legibly, and it is what the receiving party will assume.
Going higher is worth it only when embedded images carry detail that will be read closely — a photograph of a damaged part, a scanned signature under dispute. Going lower saves storage that nobody is short of, and a set imaged at 150 that turns out to be unreadable in the quoted tail of a thread is an expensive economy.
Keep the natives, always
The load file’s metadata comes from the .eml files, not from the images. So
does the extracted text. So does any re-imaging if the specification changes or
a page is challenged. Imaging is a lossy, one-way step, and the original
messages are the only thing standing between you and doing the collection
again.
How to do it in EML Exhibit
-
Read the protocol before imaging anything
Find the DPI, the colour depth, whether single-page or multi-page TIFF is required, the load-file format, and the required metadata fields. Imaging several hundred messages against the wrong specification is a full redo, including re-stamping.
-
Decide what gets imaged and what goes native
Most protocols image the message bodies and produce spreadsheets natively, because an imaged spreadsheet loses its formulas and is often unreadable. Confirm which side of that line each attachment type falls on.
-
Image the message bodies
Convert the .eml batch with TIFF selected at the specified resolution. Each message becomes a multi-page TIFF with the header block above the body.
-
Split to single-page images if required
Many Concordance-style specifications call for one image per page. The multi-page TIFFs produced here need splitting by your load-file tooling before delivery if that is what the protocol says.
-
Build the load file and stamp
The load file maps images to documents and carries the metadata fields. It is built from the original .eml files, which is why the natives are retained rather than discarded after imaging.
Single-page or multi-page TIFF?
Whatever the protocol says. Traditional Concordance-style specifications call for single-page TIFFs with the page relationships expressed in the load file, because that is what older review platforms ingest. Newer specifications are often relaxed about it, and some prefer PDF outright. The output here is multi-page, one image per message; splitting to single-page is a downstream step.
Black-and-white, greyscale or colour?
Protocols commonly default to black-and-white for text documents, with colour where colour is material. For email, colour is more often material than people expect: tracked-change markup, colour-coded spreadsheet cells pasted into a body, and highlighted text all lose meaning in bitonal. If the protocol allows colour where relevant, use it there.
Does imaging make the production unsearchable?
The images themselves, yes — a TIFF is a picture. Searchability in a review platform comes from the extracted text delivered alongside the images, usually as per-document text files referenced by the load file. Extracted text from an email is genuinely extracted rather than OCR’d, so it is accurate, which is one real advantage email has over scanned paper here.
What happens to the attachments in an imaged production?
They are extracted here as unmodified originals. Whether they are then imaged alongside the parent, produced natively, or both is a protocol question. The parent-child relationship has to survive whichever choice is made, and that relationship is expressed in the load file rather than in the images.
Why not just produce PDF?
Increasingly you can, and many protocols now accept it. Ask. If the other side’s platform ingests PDF, producing PDF saves everyone the imaging step and the split-to-single-page dance. TIFF persists because specifications were written when platforms required it and nobody has revisited them.