Product
Communication provenance, end to end
Fromenance is a communication provenance platform: your institution registers every outbound communication at send time, and your customers get a definitive Verified, Not verified, or Known fraud answer when they ask. Every piece below exists to make that answer fast, authoritative, and defensible in front of your compliance team.
Registration: three ways in, all first class
Everything downstream depends on coverage. Registration is the act of telling Fromenance, at send time, that a specific communication went to a specific recipient.
SDK and REST
POST /v1/communications from your application, or use @fromenance/sdk which computes the recipient HMAC and content fingerprint locally so raw addresses and bodies never leave your systems. Batch up to 1,000 per call for statement runs. Reserve a code before send when the body is not available.
ESP webhooks
Point your ESP's event webhook at us. We consume sent and delivered events and register each message. Adapters for Resend, SendGrid, Amazon SES, Postmark, Mailgun, Salesforce Marketing Cloud, Braze, and a generic webhook for anything else.
Journal or BCC
Add journal-{slug}@ingest.fromenance.com as a BCC or journaling target on a sending system. We receive the full message, hash the recipient, fingerprint the body, and register it. This is the path for core banking and statement vendors nobody wants to touch.
| Provider | Rendered body available | Footer mechanism |
|---|---|---|
| Resend | Yes | Custom header or reserve |
| SendGrid | No | Reserve, then custom_args and a substitution tag |
| Amazon SES | No | Reserve, message tag |
| Postmark | Yes | Reserve or metadata |
| Mailgun | No | Reserve, v: variable |
| Salesforce Marketing Cloud | No | Reserve from SSJS, AMPscript merge field |
| Braze | No | Reserve from connected content, Liquid attribute |
| Generic webhook | No | Reserve; post message id, recipient, sent time, from, code |
The footer snippet carries the code twice, once in the sentence and once as a bare reference, so at least one survives client rewrapping and screenshot OCR: "Not sure this email is from Northfield Bank? Forward it to verify@northfieldbank.com or enter code KX73-PQ9G at northfieldbank.com/verify. Reference: KX73-PQ9G".
Verification: two entry points, one trust model
verify@yourdomain.com
One mailbox and one redirect rule. Click by click guides for Google Workspace, Microsoft 365, Proofpoint, Mimecast, Cisco Secure Email. Redirect, not forward, so the customer's address survives and we can reply to them.
yourdomain.com/verify
A hosted verify page and an embeddable widget served from cdn.fromenance.com, keyed by a public site key bound to your origin and themed in your branding. Paste text, upload an .eml, or upload a screenshot.
Screenshot OCR
Customers who only have a photo of the message still get an answer. OCR runs inside Cloudflare Workers AI and its output is treated as untrusted text that feeds the same deterministic extractors. Answered within 15 seconds at p95.
Trust check on every inbound message
Mail to your tenant inbox is processed only when the forwarding hop passes DKIM or ARC for a domain you own and that domain carries a valid _fromenance TXT record. Anything else is held 24 hours for diagnosis and never answered.
Replay detection
A real footer pasted into a different message, or a real code sent to the wrong person, resolves to Not verified for the customer and to a high priority replay flag internally. Copying the footer is expected and it feeds intelligence.
Seconds, not tickets
Targets: forward to reply under 10 seconds at p95, web verify under 3 seconds for text, registration API under 150 ms. Deterministic matching has no model to wait on.
Verdicts
Three outcomes, matched by rules you can read, with wording that is locked in the reply template.
- Verified
The verify code resolved to a registration whose recipient matches the person asking, or the recipient and content fingerprint match a registration inside the retention window.
- Not verified
No registration matches on any rule. Unregistered legitimate mail lands here too, which is why the wording is "no record", never "fraudulent", until the tenant is in Authoritative Mode.
- Known fraud
An extracted indicator is on the tenant's fraud list, or the content fingerprint matches a submission an analyst already marked as fraud.
| Outcome | Condition |
|---|---|
| Verified | The code resolves to a registration whose recipient hash matches the submitter, or (no code) the recipient hash matches and the content fingerprint is within threshold and the send time is inside the registration window. |
| Not verified footer replayed | The code resolves but the recipient does not match and the fingerprint is far. Reported to the customer as Not verified, flagged internally as a replay attack, and sent to the intelligence queue with high priority. |
| Not verified | No registration matches on any rule. In Authoritative Mode the reply reads "we did not send this". |
| Known fraud | Any extracted indicator matches your fraud list, or the fingerprint matches a submission an analyst already marked as fraud. |
See a verdict render
The same widget your customers would use on yourdomain.com/verify, pointed at the demo tenant.
Try it against the real API
Demo tenant: Northfield Bank (demo). Site key sk_pub_demo_northfield. Real API, real latency.
Registered message
This fraud alert was registered at send time to jane.doe@example.com. The footer carries the verify code twice on purpose.
Northfield Bank We noticed a card transaction Hi Jane, A purchase of $412.90 at ACME ELECTRONICS was made with your Northfield Bank Visa ending in 4471 on September 24 at 10:42 AM. If this was you, no action is needed. If you do not recognize this transaction, review it in the app or call the number on the back of your card. Review this transaction: https://www.northfieldbank.com/app/alerts/tx/98812?utm=email Thank you, Northfield Bank Fraud Team Not sure this email is from Northfield Bank? Forward it to verify@northfieldbank.com or enter code KX73-PQ9G at northfieldbank.com/verify. Reference: KX73-PQ9G Northfield Bank, Member FDIC. 100 Main Street, Northfield, VT 05663. Privacy: https://www.northfieldbank.com/privacyNorthfield Bank Urgent: your card has been temporarily restricted Hi Jane, A purchase of $412.90 at ACME ELECTRONICS was attempted with your Northfield Bank Visa ending in 4471 on September 24 at 10:42 AM and has been placed on hold. To avoid permanent suspension of your card, confirm your identity within 24 hours. Confirm your identity now: https://northfield-bank-secure.com/login?ref=8812 Thank you, Northfield Bank Fraud Team Not sure this email is from Northfield Bank? Forward it to verify@northfieldbank.com or enter code QF29-TH40 at northfieldbank.com/verify. Reference: QF29-TH40 Northfield Bank, Member FDIC. 100 Main Street, Northfield, VT 05663.
The reply never quotes the suspicious message or its links. It says only what the institution can stand behind: a registered communication matches, or no registered communication does.
Analyst tools: dense, fast, exportable
The admin app is where a fraud analyst lives during an incident and where an integration engineer spends one afternoon. Tables with column pick, sort, saved filters, and CSV export. Verdict colors used nowhere else.
Submissions with a detail drawer
Extracted signals, the matched registration, verdict and rule, header summary (DKIM, ARC, SPF), a preview with links disabled, and raw MIME download for analysts. Override to fraud or legitimate with a note.
Analyst override
Marking fraud adds the submission's indicators and fingerprint to your fraud list so the next identical lure resolves to Known fraud with no lookup. Marking legitimate creates a registration retroactively and flags a coverage gap on that sending source.
Indicators and fraud list
Every URL, domain, IP, phone number, email, and QR payload extracted from every non verified submission, with first and last seen and submission count. One click to the fraud list. Entries come only from analyst action, never from a single anonymous submission.
CSV and STIX 2.1 export
Indicators export as CSV or STIX 2.1 from the table or through the API with an Accept header, ready for your SIEM, your gateway blocklist, or your takedown vendor.
Outbound webhooks with HMAC signatures
verdict.created, submission.replay_detected, and indicator.new to your SIEM or SOAR. HMAC-SHA256 signed with a per endpoint secret, retried with backoff for 24 hours, replayable from the delivery log.
Source health and coverage
Per sending source: last event, events per hour, signature failures, reserve to complete ratio, and a silence alert. Registered volume per day next to your stated volume so gaps are visible before a customer finds one.
Control and privacy posture
We are asking institutions to route customer mail through us, so the security story was finished before the first pilot. The full list is on the Security page.
Authoritative Mode
Once coverage is reviewed (the working threshold is 95 percent for 30 days), a backoffice operator flips the tenant to Authoritative Mode and Not verified replies change from "no registered communication matches" to "we did not send this". It is never self service.
Reply templates with a locked block
One MJML template per verdict, editable in the admin app, with a locked verdict block that carries the wording and timestamp. Templates never quote the suspicious message, never include its links, and never use the word your customer would misread as a guarantee.
Retention controls
Raw forwarded messages are encrypted in R2 under your tenant prefix and deleted after your retention window (default 90 days) with an audit record. Submitter addresses are purged 30 days after the reply. You set the window in Settings.
Tenant isolation and encryption
Every table carries tenant_id and every query goes through a scoped repository. Per tenant data keys wrapped by a master key in Workers secrets. API keys hashed at rest, shown once, scoped, revocable. Audit log on every write.
No LLM on the verdict path
Extraction and matching are regex, MIME parsing, SimHash, and HMAC comparison. Nothing a lure can say changes a verdict. If a model is ever used for lure classification, its output is a label in a fixed schema and it can never change a verdict from Verified.
Roles and audit
Owner, admin, analyst, integrator, and viewer. Integrators see sources, keys, and templates but no submission content. Every admin and analyst action lands in the audit log.
Intelligence tier
The schema, the indicator store, and the intel queue ship in v1 so nothing is backfilled. The features below are the roadmap and are marked as such.
Campaign clusteringRoadmap
Submissions cluster on shared indicators, fingerprint proximity, and kit fingerprint; three or more in 72 hours becomes a campaign an analyst can name, merge, split, and close.
IOC enrichmentRoadmap
URL unshortening and redirect following in an isolated fetcher, landing page screenshots, TLS certificate fingerprints, hosting ASN, WHOIS age, phishing kit fingerprints.
FeedsRoadmap
campaign.detected webhooks, STIX 2.1 and TAXII 2.1 endpoints, Splunk and Sentinel saved searches, one click export to your takedown vendor.
Questions evaluators ask
- Does the customer ever see the Fromenance name?
- No. Everything customer facing is on your domain and in your branding: verify@yourdomain.com, yourdomain.com/verify, and the reply from your reply identity. Your staff see Fromenance in the admin app and docs only.
- What does Fromenance store about a registered communication?
- A verify code, a one way HMAC of the recipient address keyed with your tenant secret, a SimHash and SHA-256 content fingerprint, the message id, the visible From, the sent time, link domains, and optional template and campaign ids. The recipient address column does not exist.
- What happens to a legitimate message we forgot to register?
- It returns Not verified with the words "no registered communication matches", never "fraudulent". An analyst can mark it legitimate, which creates the registration retroactively and flags a coverage gap on that source. Authoritative Mode, where the reply says "we did not send this", is only enabled after coverage review.
- Which ESPs are supported?
- Resend, SendGrid, Amazon SES, Postmark, Mailgun, Salesforce Marketing Cloud, Braze, and a generic webhook. Where the ESP cannot give us the rendered body, you reserve a code before send and inject it with the ESP's merge mechanism; matching then leans on the code plus the recipient.
- How fast is a verdict?
- Targets are under 10 seconds at p95 from inbound webhook to reply sent, under 3 seconds for a pasted message on the web page, and under 15 seconds for a screenshot. The demo on this page shows real latency against the production API.
- Can a phishing message trick the matcher?
- There is no model on the verdict path to trick. A verdict comes from a checksummed verify code resolving to a registration, an HMAC comparison of the recipient, and a fingerprint within a Hamming threshold. A copied footer resolves to Not verified and is flagged as a replay.
Run a 60 to 90 day pilot on one communication stream.
Fraud alerts or transaction alerts are the best first stream. You get a written report of verification volume, verdict distribution, campaigns discovered, and intelligence yield.