Communication provenance explained

Communication provenance is authoritative, sender side evidence that a specific institution issued a specific communication to a specific recipient at a specific time. Fromenance is a communication provenance platform: the institution registers each message at send time, and when a customer asks about one, the answer comes from that registry 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 authorized for this domain, and was this message signed by this domain? SPF, DKIM, and DMARC answer it. They protect the institution's 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 removed most of the tells it relied on.

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

What a provenance record contains

At send time, the institution's application, ESP webhook, or journal feed registers:

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

In return, the institution receives a verify code bound to that registration and puts it in the footer. The code is 8 Crockford base32 symbols with a checksum, shown as XXXX-XXXX, unique per message.

What a verification does with it

The customer forwards the message to verify@institution.com or pastes it on institution.com/verify. The platform extracts the code, hashes the customer's address, fingerprints the body, and runs a pure function over the registry:

• Code resolves and the recipient matches: Verified, with the time it was sent
• Code resolves but the recipient does not match, or the content is far: Not verified, and a replay flag internally, because a real footer was copied
• No code, but recipient and fingerprint match inside the window: Verified
• Indicators on the fraud list or fingerprint of a confirmed lure: Known fraud
• Otherwise: Not verified, worded as "no registered communication matches", never "fraudulent"

No model is involved. 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 the platform never makes one. Not verified means no record, which is also what a legitimate but unregistered vendor message returns; only once coverage is reviewed 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, URLs, phone numbers, and QR payloads are extracted the moment it fails. That is threat intelligence from a sensor nobody else has: the 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.