How to Redact Email Attachments: Documents, Images, Audio, Video

The body of an email is often the least sensitive part of the message it belongs to. A two-line cover note can carry a scanned letter, a spreadsheet of names, phone photos of a scene, a voicemail and a video clip at once. Each of those files needs a different kind of redaction, and some of what travels with a message is not a file in the ordinary sense.

Our guide to email redaction across a mailbox deals with the release as a whole, and our article on PII in emails maps the personal information in the message itself. Attachments are where a release most often goes wrong, because they are opened last and arrive in the widest range of formats. To redact email attachments reliably, work through five steps, each of which the sections below take in turn with the checks that go with it:

1. List every attachment each message carries, including inline images, attached messages, cloud links and the contents of archives.
2. Agree the production format with whoever receives the release, then send each file to the redaction its format needs.
3. Open every file with its hidden content showing, both before redaction and after it.
4. Settle what happens to a file that cannot be finished, so that a failure is visible instead of silent.
5. Release each attachment with its message, labeled so that a reader can match them.

Listing everything a message carries

Ordinary file attachments are the easy part of an inventory, and pictures carried inside the message are the first of the hard parts. Inline images placed in the body count as attachments in Microsoft Graph, but the message's own flag leaves them out. Graph's message reference notes that the hasAttachments property "doesn't include inline attachments, so if a message contains only inline attachments, this property is false." A filter on that flag drops those messages entirely, and the same page advises parsing the body for a src attribute beginning with cid: to find them.

Attached messages and cloud links are the two kinds of attachment that break a simple download of everything in a message. Microsoft's documentation on getting an attachment lists three types: a file, an Outlook item such as a message, and "A link to a file stored in the cloud." An attached message comes back whole, in MIME format, and can carry attachments of its own, which Graph will expand "including any nested attachments up to 30 levels." A cloud link has no content in the mailbox at all, since "Attempting to get the $value of a reference attachment returns HTTP 405." The file has to be fetched from wherever it lives, and it may have changed since the message was sent. Our article on Microsoft 365 email redaction shows how a pull from Outlook should retrieve each of them.

Archives and the PDF packages that export tools produce hide files in a third way. A zip or tar archive can hold dozens of files, sometimes including further archives, and a PDF package may carry attachments embedded inside the PDF instead of printed as pages. Each of those belongs on the inventory as an item of its own.

This step closes with a count taken at both ends: attachments per message at the source and again in the release, with inline images and attached messages included. Record every cloud link as well, with where its file came from and which version of it was released.

Routing each file, once the format is agreed

Our document redaction renders every document as pages before anything is removed, so a spreadsheet comes back as a redacted PDF rather than a workbook, and so does a Word or PowerPoint file. That suits most public records releases, but it can clash with a discovery production specification that asks for native files. Agree the production format with the receiving party before redaction starts, so that nobody disputes redacted PDFs of spreadsheets after the release has gone out.

With the format settled, each file goes to the method its format needs, and the table sets out what that looks like for the formats a mailbox usually yields.

Our own email rendering leaves attachments out on purpose, and the reason applies to any tool. Folded into the message, an attachment would either skip the treatment its own format needs or look covered when only its file name had been. A voicemail, for example, cannot be redacted as a page of text, so every attachment becomes its own item with its own redaction and its own record of what was removed and why. Voicemails carry the least visible risk of the set, and our post on how to redact audio recordings goes deeper into spoken personal information.

Before moving on, open every redacted attachment in the viewer a recipient will use as well as in the redaction tool, since the recipient's view is the one the release will be judged by.

Where attachments hide data

Hidden worksheets, rows and columns, comments, tracked changes and speaker notes all survive in an Office file that looks clean on screen. Released spreadsheets have gone wrong in exactly those places, including one freedom of information release that exposed a whole police service's staff list. Our article on redacting Word documents and spreadsheets tells that case and sets out what to strip before an attachment leaves.

The mechanism behind that release was ordinary office work, which is what makes it instructive for anyone releasing spreadsheets. Extra worksheets were created in the downloaded file while the information was analyzed, and the visible tabs were deleted at the end. The original worksheet holding the personal details stayed in the file, and quality assurance never picked it up. One check catches that kind of leftover: open every spreadsheet and presentation with hidden sheets, rows, columns, comments and speaker notes shown, both before redaction and after it.

A PDF can carry files of its own, along with scripts and actions that run when it opens, and a redaction pass over the pages never looks at any of them. Our document redaction strips embedded files, scripts and open actions from every redacted output, so nothing leaves with the file that a reviewer did not see. An embedded file that has to be released is extracted first and redacted as an item of its own.

Nothing about file properties or photo metadata shows on the page, which makes them the easiest hiding place of all to forget. A document's author, company and editing dates, or the location stored in a phone photo, can identify people the visible redaction was meant to protect. Check the properties of every redacted document and the metadata of every redacted photo before release.

When a file cannot be finished

Every redaction tool eventually meets an attachment it cannot finish, and what it does at that moment decides whether the failure is visible or silent. A failed or stalled job should delete its partial output and leave the original untouched, so that the copy released is always the one that was actually redacted.

A failure in a long recording can land in the middle of the file, so video and audio need their own version of that rule. In our video redaction, a frame whose redaction fails is written fully masked and the job carries on, so one bad frame neither leaks a face nor stops a long recording. A redaction stage that stops early, or an encoder that exits with an error, fails the whole job, and partial output is deleted before anything can pick it up. A failed audio job fails outright, and the recording is never published unredacted. When checking the results, listen a few seconds either side of each silenced segment, where a word can be clipped at the edge. Scrub video frame by frame wherever an object enters or leaves a masked region.

A file nobody can open is a file no detector can read, so password protection needs a decision too, before a tool skips the file quietly and leaves a gap in the release. Where the VIDIZMO platform keeps stored documents password-protected, redaction runs on an unlocked working copy and the protection is put back on the redacted copy. An attachment locked by its sender is a different case, since the password or an unprotected copy has to come from the custodian before any tool can redact it. Password-protected Office files and zip archives raise the same question.

Keeping each message and its attachments together

Separating an attachment from its message in a release leaves the reader unable to tell what was sent with what, even when both were redacted correctly. For federal agencies, the recordkeeping rule at 36 CFR 1236.22 makes that link explicit, requiring attachments that are an integral part of the record to be preserved with the email record or linked to it.

In practice, each attachment is redacted as its own item and released with its message, labeled so that a reader can match them. Each item keeps its own record of what was redacted and why. In litigation the review platform that assembles the production assigns family numbering, as our guide notes, so what the redaction step owes it is one redacted file per attachment, clearly tied to its message.

How VIDIZMO handles each kind of attachment

On the Microsoft 365 path described in our guide, the AI Intelligence Hub workflow hands every attachment it pulls to VIDIZMO Redactor, which does the detection and redaction. Redactor applies the methods in the table to documents, images, audio, video and zip or tar archives, and a few details go further. A redacted document is a PDF in which flagged properties such as author and company are anonymized. Images are rebuilt from their redacted pixels so embedded location data does not travel, and audio is masked on every channel of a stereo recording.

Bulk redaction is permissioned per format, so an operator can be allowed to batch documents without being allowed to batch video.

For how Word files, spreadsheets and PDFs are redacted in detail, see document redaction in Redactor.