Communication provenance explained

We picked the phrase "communication provenance" because nothing existing described what we were building, and this post is the explanation we wish we could hand people on the first call. Communication provenance is evidence, from the sender's own side, that a specific institution sent a specific message to a specific person at a specific time. Fromenance is a communication provenance platform: you register each message as you send it, and when a customer asks about one, the answer comes from that record rather than from a guess about what the message looks like.

Three questions that sound the same and are not

Authentication asks: is this sending server allowed to send for this domain, and was this message signed by this domain? SPF, DKIM, and DMARC answer it. They protect your real domain from being spoofed. They say nothing about a message from a different domain.

Detection asks: does this message look malicious? Gateways, classifiers, and consumer scam detector apps answer it with a probability. Good detection catches a lot. It cannot be certain about a lure that looks exactly like the real thing, and it cannot confirm that the real thing is real. AI written phishing took away most of the tells it leaned on.

Provenance asks: do we have a record that this institution sent this exact message to this person? Only the institution can answer, because only the institution knows what it sent. Fromenance makes that record usable in seconds.

What a provenance record contains

As you send, your application, your ESP webhook, or your journal feed registers:

• A one way HMAC of the recipient's address, keyed with a per tenant secret, so we never hold the address
• A 64 bit SimHash and a SHA-256 of the normalized visible text, so we never hold the body
• The message id, the visible From, the sent time, the link domains, and optional template and campaign ids

In return you get a verify code that belongs to that registration, and you put it in the footer. The code is 8 Crockford base32 symbols with a checksum, shown as XXXX-XXXX, different for every message.

What a verification does with it

The customer forwards the message to verify@institution.com or pastes it on institution.com/verify. We pull out the code, hash the customer's address, fingerprint the body, and run a pure function over the registry:

• Code leads to a registration and the recipient matches: Verified, with the time it was sent
• Code is real but the recipient does not match, or the text is far off: Not verified, plus a replay flag for the fraud team, because a real footer was copied
• No code, but recipient and fingerprint match inside the window: Verified
• An indicator on the fraud list, or the fingerprint of a confirmed lure: Known fraud
• Otherwise: Not verified, worded as "no registered communication matches", never "fraudulent"

No model is involved anywhere in that list. The answer is a lookup.

Why the wording is locked

A provenance answer is only as good as what the institution can stand behind. "Matches a communication we registered and sent to you on September 24 at 10:42" is a claim the registry supports. A blanket assurance that a message is harmless is not, and we never make one. Not verified means no record, which is also what a legitimate but unregistered vendor message returns; only once we have reviewed your coverage together does Authoritative Mode turn that into "we did not send this".

The second thing provenance produces

Every submission that fails is an impersonation attempt delivered by the person it was written for. Its domains, links, phone numbers, and QR codes are pulled out the moment it fails. That is threat intelligence from a sensor nobody else has: the intended victim. Over time, joined to the authoritative record of what institutions actually send, it becomes a communication provenance graph.

Definitions for every term above are on the glossary. The mechanics are on how it works.