Everything between the send and the answer

• One HTTPS call, nothing to install

  Your application makes one call to us as it sends. You hash the recipient's address and fingerprint the text on your side, using the dependency free code we publish, so raw addresses and bodies never leave your systems. Send up to 1,000 in one batch for the Tuesday statement run. Reserve a code before send when you do not have the body yet.

• ESP webhooks

  Point your ESP's event webhook at us and we register each message from its sent and delivered events. We have adapters for Resend, SendGrid, Amazon SES, Postmark, Mailgun, Salesforce Marketing Cloud, Braze, and a generic webhook for whatever else you run.

• Journal or BCC

  Add journal-{slug}@ingest.fromenance.com as a BCC or journaling target on a sending system. We get the full message, hash the recipient, fingerprint the body, and register it. This is how you cover the core banking and statement vendors nobody wants to touch.

The footer carries the code twice, once in the sentence and once on its own, so at least one copy survives a mail client rewrapping it or a phone camera reading it: "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".

• verify@yourdomain.com

  One mailbox and one redirect rule. We give you click by click guides for Google Workspace, Microsoft 365, Proofpoint, Mimecast, Cisco Secure Email. It has to be a redirect, not a forward, so the customer's own 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 tied to your origin and themed like the rest of your site. Customers paste text, upload an .eml, or upload a screenshot.

• Screenshots from a phone

  Customers who only have a photo of the message still get an answer. OCR runs inside Cloudflare Workers AI, and we treat its output as untrusted text that feeds the same deterministic extractors. Answered within 15 seconds at p95.

• A trust check on every inbound message

  We only process mail to your tenant inbox 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 so we can diagnose it, and never answered.

• Replay detection

  A real footer pasted into a different message, or a real code sent to the wrong person, comes back Not verified for the customer and raises a high priority replay flag for you. We expect attackers to copy the footer. It feeds your intelligence.

• Seconds, not tickets

  Our targets: forward to reply under 10 seconds at p95, web verify under 3 seconds for pasted text, registration under 150 ms. There is no model to wait on.

• Verified

  We found the message in your registry. Either the verify code led us to a registration sent to the person asking, or their address and the content fingerprint matched one inside the retention window.

• Not verified

  Nothing in your registry matches. A real message you never registered lands here too, which is why we say "no record" and never "fraudulent" until you are in Authoritative Mode.

• Known fraud

  One of the message's links, domains, or phone numbers is on your fraud list, or its fingerprint matches a lure your analysts already confirmed.

• Submissions, with everything in one drawer

  The signals we extracted, the registration we matched, the verdict and the rule that produced it, a header summary (DKIM, ARC, SPF), a preview with the links disabled, and the raw MIME for analysts who want it. Override to fraud or legitimate, with a note.

• Analyst override

  Mark a submission as fraud and its indicators and fingerprint join your fraud list, so the next identical lure comes back Known fraud with no lookup. Mark one as legitimate and we register it retroactively and flag a coverage gap on that sending source.

• Indicators and the fraud list

  Every URL, domain, IP, phone number, email address, and QR payload from every non verified submission, with first seen, last seen, and how many times. One click to the fraud list. Entries come only from an analyst, 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, ready for your SIEM, your gateway blocklist, or your takedown vendor.

• Signed webhooks to your SIEM

  verdict.created, submission.replay_detected, and indicator.new to your SIEM or SOAR. Signed with HMAC-SHA256 and a per endpoint secret, retried with backoff for 24 hours, and replayable from the delivery log.

• Source health and coverage

  For each sending source: the last event, events per hour, signature failures, the reserve to complete ratio, and an alert when it goes quiet. Registered volume per day sits next to the volume you told us to expect, so a gap shows up before a customer finds it.

• Authoritative Mode

  Once we have reviewed your coverage together (the working threshold is 95 percent for 30 days), one of our operators flips your tenant to Authoritative Mode and your Not verified replies change from "no registered communication matches" to "we did not send this". It is never self service, on purpose.

• Reply templates with a locked block

  One MJML template per verdict, editable in the admin app, with a locked block that carries the verdict wording and the timestamp. Templates never quote the suspicious message, never include its links, and never use the word your customer would read as a guarantee.

• Retention you set

  Forwarded messages are encrypted in R2 under your tenant's prefix and deleted after your retention window, 90 days by default, with an audit record. Submitter addresses are purged 30 days after the reply. The window is a setting.

• Tenant isolation and encryption

  Every table carries your tenant id and every query goes through a scoped repository. Your data keys are wrapped by a master key that lives only in Workers secrets. API keys are hashed at rest, shown once, scoped, and revocable. Every write lands in the audit log.

• No LLM on the verdict path

  Extraction and matching are regex, MIME parsing, SimHash, and an HMAC comparison. Nothing a lure can say changes a verdict. If we ever use a model to classify lures, 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 never submission content. Every admin and analyst action lands in the audit log.

• Roadmap

  Campaign clustering

  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.

• Roadmap

  IOC enrichment

  URL unshortening and redirect following in an isolated fetcher, landing page screenshots, TLS certificate fingerprints, hosting ASN, WHOIS age, phishing kit fingerprints.

• Roadmap

  Feeds

  campaign.detected webhooks, STIX 2.1 and TAXII 2.1 endpoints, Splunk and Sentinel saved searches, one click export to your takedown vendor.

Read about the intelligence layer

FAQ

Questions we get on the first call

Does the customer ever see the Fromenance name?

No. Everything the customer touches is on your domain and in your branding: verify@yourdomain.com, yourdomain.com/verify, and the reply from your reply identity. Your staff see our name in the admin app and the docs, and that is it.

What do you actually store about a registered communication?

A verify code, a one way hash of the recipient address keyed with your tenant secret, a SimHash and SHA-256 fingerprint of the text, the message id, the visible From, the sent time, the link domains, and optional template and campaign ids. There is no column for the recipient's address. It does not exist.

What happens to a legitimate message we forgot to register?

It comes back Not verified with the words "no registered communication matches", never "fraudulent". An analyst can mark it legitimate, which registers it retroactively and flags a coverage gap on that source. Authoritative Mode, where the reply says "we did not send this", is only switched on after we have reviewed coverage with you.

Which ESPs do you work with?

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 drop it in with the ESP's merge mechanism; matching then leans on the code plus the recipient.

How fast is a verdict?

Our 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 runs against the production API, so you can see the latency for yourself.

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, a hash comparison of the recipient, and a fingerprint within a Hamming threshold. A copied footer comes back Not verified and is flagged as a replay.