Glossary

The words we use, defined once

Fromenance uses a small vocabulary for communication provenance, and we would like it to mean the same thing on this site, in the docs, and in the product. So here it is: one sentence per term, kept stable, and when a definition changes we note it here.

Communication provenance: 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, which is what Fromenance gives you and what domain authentication like DMARC never claimed to.
Registration: Registration is you telling Fromenance, as you send, that a message went to a recipient, handing over a recipient hash, a content fingerprint, the message id, the sent time, and the visible From address, and getting a verify code back.
Verify code: A verify code is the 8 symbol Crockford base32 identifier, shown as XXXX-XXXX with a checksum in the eighth symbol, that Fromenance issues for each registration and that you put in the message footer.
Verify footer: The verify footer is the sentence you add to registered messages, such as "Not sure this email is from JT Merlin Bank? Forward it to verify@jtmerlin.com or enter code KX73-PQ9G at jtmerlin.com/verify. Reference: KX73-PQ9G", with the code repeated so one copy survives rewrapping and a phone camera.
Recipient hash: A recipient hash is hmac-sha256 of the lowercased, trimmed recipient address keyed with your tenant secret, and it is the only form in which Fromenance ever holds a recipient on a registered communication.
Content fingerprint: A content fingerprint is the 64 bit SimHash (plus a SHA-256) of a message's normalized visible text, computed the same way at registration and at verification so Fromenance can match a forwarded copy without ever storing the body.
Content normalization: Content normalization is the deterministic pipeline (HTML to text, gateway link unwrapping, forward chrome removal, footer removal, URL to domain replacement, whitespace and case collapse) that runs before fingerprinting so you and Fromenance end up with the same bits.
Fingerprint threshold: The fingerprint threshold is the largest Hamming distance, 6 of 64 bits by default and tunable per tenant, at which Fromenance still treats two content fingerprints as the same message.
Submission: A submission is one customer asking Fromenance about one message, whether by forwarding it to verify@ or by pasting it, uploading an .eml, or uploading a screenshot on your verify page, and it always resolves to exactly one verdict.
Verdict: A verdict is Fromenance's immutable answer to a submission, one of Verified, Not verified, or Known fraud, recorded with the rule that produced it and any analyst override.
Verified: Verified is the Fromenance verdict when a submission matches a communication you registered for that recipient, and the reply says "matches a communication we registered and sent to you on" the recorded time.
Not verified: Not verified is the Fromenance verdict when nothing in your registry matches a submission, and the reply says "no registered communication matches", which on its own does not mean the message is fraudulent.
Known fraud: Known fraud is the Fromenance verdict when a submission carries an indicator that is on your fraud list, or its fingerprint matches a lure one of your analysts already confirmed.
Authoritative Mode: Authoritative Mode is a per tenant Fromenance setting, switched on only by one of our operators after we have reviewed your coverage together (the working threshold is 95 percent for 30 days), that changes the Not verified reply from "no registered communication matches" to "we did not send this".
Coverage: Coverage is the share of what you actually send on a stream that is registered with Fromenance, tracked per sending source against the volume you told us to expect, and it is what has to be high before Authoritative Mode makes sense.
Coverage gap: A coverage gap is a real message you never registered, and Fromenance surfaces one whenever an analyst marks a Not verified submission as legitimate or a reserved code goes uncompleted for 24 hours.
Replay attack: A replay attack is someone using a real Fromenance verify code or footer on a message it was not issued for or with a person it was not sent to, and it comes back Not verified for the customer with a high priority flag for you.
Footer replay: Footer replay is the specific replay attack where an attacker copies your genuine verify footer into a lure, which Fromenance catches because the code belongs to one registration and one recipient hash.
Trust check: The trust check is the gate Fromenance puts in front of every message that arrives at your tenant inbox: the slug resolves to you, the forwarding hop passes DKIM or ARC for a domain you own, and that domain's _fromenance TXT token matches.
Trust TXT record: The trust TXT record is the one DNS record, _fromenance.<domain> TXT "v=fromenance1; t=<slug>; k=<token>", that ties your domain to your Fromenance tenant, and we re-check it every day.
Redirect rule: A redirect rule is the mail flow rule on verify@yourdomain.com that redirects (rather than forwards) messages to your tenant inbox, so the customer stays the sender and Fromenance can reply to them.
Reply identity: A reply identity is the sending domain your Fromenance verdict replies leave from, either a DKIM signed subdomain you delegate (which we recommend) or our reply domain with your display name, which we only allow for pilots.
Locked verdict block: The locked verdict block is the fixed text and timestamp in every Fromenance reply template that carries the verdict wording, cannot be edited by anyone on your side, and never quotes the suspicious message or claims more than the registry supports.
Reserve flow: The reserve flow is how you register with Fromenance from an ESP that cannot give us the rendered body: you reserve a verify code before sending, drop it in with the ESP's merge field, and let the send event complete the registration.
Sending source: A sending source is one Fromenance integration that registers your messages (an API caller, an ESP adapter, or a journal address), each with its own health readout: last event, events per hour, signature failures, and reserve to complete ratio.
Journal or BCC path: The journal path is how you register with Fromenance from a system that can only BCC: it sends a copy to journal-<slug>@ingest.fromenance.com and we hash, fingerprint, and register the full message without anyone changing application code.
Indicator: An indicator is a URL, domain, IP, phone number, email address, QR payload, or wallet address that Fromenance pulls out of a non verified submission deterministically and keeps with first seen, last seen, and a count.
Fraud list: The fraud list is your tenant's set of indicators and fingerprints, added only by an analyst or a confirmed campaign, that makes later matching submissions come back Known fraud from Fromenance.
Analyst override: An analyst override is the audited act of marking a Fromenance submission as fraud (which adds its indicators and fingerprint to the fraud list) or as legitimate (which registers it retroactively and flags a coverage gap).
Site key: A site key is the public, origin bound key your Fromenance verify page or widget sends with each submission; it carries no secret and is rate limited per key and per IP.
Verify page: A verify page is the page you host, usually yourdomain.com/verify, where a Fromenance widget takes pasted text, an .eml file, or a screenshot and shows the verdict in your branding.
Campaign: A campaign is a Fromenance cluster of three or more submissions in 72 hours that share indicators, a kit fingerprint, or fingerprint proximity, which an analyst can name, merge, split, and close; clustering is on the intelligence roadmap.
Communication provenance graph: The communication provenance graph is the dataset Fromenance builds up over time by joining the authoritative record of what institutions sent to the lures their customers submitted and the infrastructure behind them, correlated across institutions on indicators only.