What survives an email forward

A forwarded email arrives with the original wrapped in the client's forward chrome, its links rewritten by a gateway, its headers mostly gone, and its footer possibly rewrapped. Fromenance builds communication provenance on what reliably survives that trip, which is why the verify code is the primary signal, the recipient comes from the redirect envelope, and the content fingerprint is computed after a normalization pipeline that strips everything the forward added.

What each client does

Gmail wraps the original in a ---------- Forwarded message --------- block with From, Date, Subject, and To lines, converts the body to its own HTML, and keeps links intact. The original headers are gone unless the user chooses "Forward as attachment".

Outlook (desktop and web) inserts a From/Sent/To/Subject header block, often prefixed with -----Original Message-----, and may rewrap long lines in plain text. Safe Links, if the tenant has Microsoft Defender, rewrites every URL through safelinks.protection.outlook.com.

Apple Mail adds "Begin forwarded message:" and a header block, and quotes the body with > markers in plain text. Signatures from the device ("Sent from my iPhone") are appended.

Proofpoint and Mimecast at the customer's employer rewrite links through urldefense.com (v2 and v3 encodings) or Mimecast's URL protection, sometimes strip images, and sometimes add banners.

What reliably survives

1. The verify code. An 8 symbol code in a sentence of plain text survives every client and every gateway. It appears twice in the footer, once in the sentence and once as a bare reference, so at least one copy survives aggressive rewrapping and screenshot OCR. The eighth symbol is a checksum, so the extractor ignores anything that merely looks like a code. In practice the code is found on well above 85 percent of forwards once the footer is deployed.
2. The customer's address. When the institution's verify@ rule redirects (rather than forwards) to the tenant inbox, the customer stays the envelope sender and their address survives. This is why the setup wizard tests the rule and refuses go live on a forward. A forward replaces the sender with the mailbox and loses the customer.
3. The visible text. Most of it. Words survive; formatting, images, tracking pixels, and link targets do not.

What does not survive

• Original headers, unless the customer forwards as an attachment. When they do, we verify DKIM on the original for the tenant's sending domains.
• Link targets, which are rewritten by gateways and sometimes stripped. This is why normalization replaces every URL with its bare registered domain before fingerprinting, and unwraps Proofpoint v2 and v3, Safe Links, and Google redirects first.
• Whitespace, case, and line breaks. Collapsed.

The normalization pipeline

Both the SDK at registration and the API at verification run the same code from a shared package, so both sides compute the same bits:

1. HTML to text, dropping tracking pixels
2. Unwrap gateway links
3. Remove forward chrome: forwarded message markers, From/Sent/To/Subject blocks, "wrote:" lines, quote markers, device signatures
4. Remove the verify footer itself
5. Cut at the signature delimiter
6. Replace every URL with its registered domain
7. Collapse whitespace and lowercase
8. SimHash over word 3-gram shingles with FNV-1a 64

A match is Hamming distance 6 or less out of 64 bits. The test fixtures for the same message forwarded from Gmail, Outlook, Apple Mail, and through a Proofpoint rewrite all land within that distance of the original; an unrelated lure lands around 30 bits away.

Why the order of signals matters

The code is strongest because it is bound to one registration and one recipient and survives everything. The recipient is second because it survives a redirect. The fingerprint is third because it survives most forwards but degrades with aggressive gateways. Headers are last because they rarely arrive. The verdict function evaluates in that order and reports which rule fired, so an analyst can see whether a Verified came from code+recipient+content or from recipient+fingerprint alone.

More on the trust model and the verdict function.