# Fromenance: full text of the public site Source: https://fromenance.com. Generated from the built pages at build time. Definitions are on https://fromenance.com/glossary. --- Page: Make every customer communication verifiable URL: https://fromenance.com/ Communication provenance # Make every customer communication verifiable. Your customer is looking at an email that says it is from you, and they cannot tell, which is exactly the moment Fromenance, a communication provenance platform for banks, credit unions, insurers, and utilities, is built for. It gives that customer a straight answer from you in seconds: "did you really send this?" answered by the only party who actually knows. Here is the whole idea. You register every outbound message as you send it. When a customer is unsure, they forward it to verify@yourbank.com or paste it at yourbank.com/verify. We check it against what you sent and reply in your voice with one of three answers: Verified, Not verified, or Known fraud. Talk to us about a pilot See what is in the box - Verified "Verified: this message matches a communication we registered and sent to you on September 24, 2026 at 10:42 AM UTC." - Not verified "Not verified: no registered communication matches this message. That does not by itself mean it is fraudulent, but treat it with caution." - Known fraud "Known fraud: this message matches an impersonation attempt our fraud team has confirmed. Do not interact with it." How it works ## Three steps, one answer ### You register the message as you send it One HTTPS call from your application, an ESP webhook, or a BCC from the system that sends your statements. We keep a verify code, a one way hash of the recipient's address, and a fingerprint of the text. We never get the address and we never get the body. ### Your customer asks you They forward the message to verify@yourbank.com, or paste it at yourbank.com/verify. A screenshot from their phone works too. No account, nothing to install, and our name is nowhere on it. ### They get a straight answer in seconds We match the code, the recipient, and the fingerprint against what you actually sent. The reply comes from your domain, in your branding, with what to do next. Every message that fails becomes intelligence for your fraud team. Verdicts ## Three answers, and we do not let anyone soften them The verdict block in every reply is fixed text. Your fraud team cannot water it down and your marketing team cannot inflate it. It says exactly what you can stand behind, and nothing more. - Verified "Verified: this message matches a communication we registered and sent to you on September 24, 2026 at 10:42 AM UTC." 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 "Not verified: no registered communication matches this message. That does not by itself mean it is fraudulent, but treat it with caution." 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 "Known fraud: this message matches an impersonation attempt our fraud team has confirmed. Do not interact with it." 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. A real message you forgot to register comes back Not verified with the words "no record", never "fraudulent". Once we have reviewed your coverage together, Authoritative Mode changes that reply to "we did not send this".What Authoritative Mode takes . Demo ## Try it yourself, on the production API This runs on a demo tenant with a public site key. Paste the real alert or the lure and watch the verdict come back. The latency is real, the verdict path is real, and there is no model anywhere in it. Why provenance ## What DMARC does not answer SPF, DKIM, and DMARC are necessary. We depend on them. They just answer a different question than the one your customer is asking. ### DMARC checks a domain, not a message A lure from jtmerlin-secure.com with your logo pasted in passes SPF, DKIM, and DMARC, because it really did come from jtmerlin-secure.com. Nothing in that chain tells your customer whether you sent it. ### Gateways and classifiers give you a probability An 87 percent phishing score is useful to your SOC. It is useless to a customer holding the phone, who needs a yes or a no that your legal team can stand behind. ### Brand protection finds the lookalike on a lag Takedown vendors discover impersonation infrastructure after it is live. The customer who just received the lure is the earliest sensor you have, and nobody is listening to them. Intelligence ## Every failed verification is a phishing sample, delivered by its target A Not verified or Known fraud submission arrives carrying the attacker's domains, links, phone numbers, and QR codes, sent to you by the exact person the lure was written for. We pull those out deterministically, keep them in your tenant, and let you export them as CSV or STIX 2.1 today. Clustering them into campaigns, enriching the infrastructure, and warning other institutions early is the intelligence tier, and it is on the roadmap rather than in the box. The intelligence layer What we keep and for how long Solutions ## Built for the person who owns impersonation ### Banks Fraud alerts, transaction alerts, wire notices. ### Credit unions Member alerts, with a five person fraud team. ### Insurance Claims, policy, and billing messages. ### Utilities Outage, billing, and disconnection notices. --- Page: Product URL: https://fromenance.com/product Product # Everything between the send and the answer Fromenance is a communication provenance platform, and this page is the whole of it: you register every outbound message as you send it, and when a customer asks, they get Verified, Not verified, or Known fraud from you in seconds. Every piece below exists to make that answer fast, certain, and something your compliance team is comfortable putting your name on. Talk to us about a pilot How the matching works - Verified "Verified: this message matches a communication we registered and sent to you on September 24, 2026 at 10:42 AM UTC." - Not verified "Not verified: no registered communication matches this message. That does not by itself mean it is fraudulent, but treat it with caution." - Known fraud "Known fraud: this message matches an impersonation attempt our fraud team has confirmed. Do not interact with it." Registration ## Three ways to tell us what you sent Everything downstream depends on coverage, so we made registration cheap in all three shapes we have seen at institutions: an application that can make a call, an ESP that can fire a webhook, and a vendor system that can only BCC. ### 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. | Provider | Rendered body available | How the code gets into the footer | | 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 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". Verification ## Two ways for a customer to ask, one trust model ### 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. Verdicts ## Three answers Matched by rules you can read, with wording that is locked in the reply template so nobody can soften it or oversell it. - 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. | Outcome | When | | Verified | The code leads to a registration whose recipient hash matches the person asking. Or, with no code, the recipient hash matches and the fingerprint is within threshold and the send time is inside the window. | | Not verified footer replayed | The code is real but the recipient does not match and the content is far off. The customer sees Not verified; you see a replay flag with high priority in the intelligence queue. | | Not verified | Nothing matches on any rule. In Authoritative Mode the reply reads "we did not send this". | | Known fraud | One of the extracted indicators is on your fraud list, or the fingerprint matches a submission an analyst already marked as fraud. | Demo ## Watch a verdict come back The same widget your customers would use on yourdomain.com/verify, pointed at the demo tenant on the production API. Analyst tools ## Dense, fast, and built for an incident The admin app is where a fraud analyst lives during a campaign and where an integration engineer spends one afternoon. Tables with column pick, sort, saved filters, and CSV export. The verdict colors appear nowhere else in the app. ### 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. Control and privacy ## What we did before asking anyone to route mail through us We are asking institutions to send us customer mail, so the security story was finished before the first pilot, not after. The full account is on the Security page. ### 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. Intelligence tier ## What comes next, marked as such The schema, the indicator store, and the intelligence queue ship in v1 so nothing has to be backfilled. The pieces below are the roadmap, and we label them that way everywhere. 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. --- Page: How it works URL: https://fromenance.com/how-it-works How it works # A registry, a trust check, and a verdict function you can read This is the page for the person who wants to know exactly how Fromenance does communication provenance before they let it near customer mail. Short version: we match what a customer sends us against a registry of what you actually sent, using a checksummed verify code, a hash of the recipient's address, and a fingerprint of the text, and there is no model anywhere on the path. The answer is a lookup, not a probability, which is why your compliance team can stand behind it. What is in the box Read the docs Trust model ## Before we read a single forwarded message We first establish that it came through your infrastructure. Four things make that true. ### One TXT record anchors your tenant _fromenance.yourdomain.com TXT "v=fromenance1; t=; k=". We poll DNS every 60 seconds until it resolves, re-check it daily, and pause inbound for that domain if the record disappears. That is your whole DNS footprint. ### The forwarding hop has to authenticate We process mail to @verify.fromenance.com only when it carries a DKIM signature that verifies for a domain you own, or an ARC chain whose last seal is by such a domain, and that domain's TXT token matches. We run DKIM, ARC, and SPF ourselves, inside the Worker, on the raw MIME. ### Everything else is held, not answered A message that fails any part of the trust check is kept for 24 hours as rejected inbound, where our operators can see why (usually an onboarding mistake). It is never processed, never replied to, and then deleted. ### Redirect, not forward The rule on verify@yourdomain.com redirects to your tenant inbox, so the customer stays the sender and the original headers survive. We have guides for Google Workspace, Microsoft 365, Proofpoint, Mimecast, Cisco Secure Email, and the setup wizard sends a test and refuses to go live until the rule is right. Registration ## What a registration carries Your application computes everything sensitive on your side, with the normalization code we publish. We never receive a raw recipient address or a message body. POST /v1/communications { "channel": "email", "recipient_hash": "hmac-sha256:9f2c...", "message_id": "", "from_address": "alerts@jtmerlin.com", "sent_at": "2026-09-24T14:42:10Z", "content_fingerprint": { "simhash": "0x9a4d...", "sha256": "e3b0..." }, "link_domains": ["jtmerlin.com"], "template_id": "fraud-alert-v3", "provider": "api" } 200 OK { "id": "com_01J...", "verify_code": "KX73-PQ9G", "expires_at": "2026-12-23T14:42:10Z" } What comes back is a verify code that belongs to this registration and this recipient. You put it in the footer. Codes are unique within your tenant, change with every message, and expire with your retention window, 90 days by default. If your ESP cannot hand us the rendered body, you reserve the code before you send, drop it into the template with the ESP's merge field, and the ESP's send event completes the registration. A reservation that is never completed within 24 hours expires, and we report it to you as a coverage gap. Every creating call takes an idempotency key we keep for 24 hours, so a retry never double registers. Rate limits are 600 registrations per minute per key and 6,000 batch items per minute. Extraction ## What we pull out, strongest signal first Deterministic, in this order, on every submission from either entry point. ### 1. The verify code Eight Crockford base32 symbols, shown as XXXX-XXXX. The eighth is a checksum, so the extractor only accepts codes that validate, even out of OCR text. A code that leads to a registration is the strongest signal we have. ### 2. The recipient The customer's address from the redirect envelope, plus the innermost To header of the quoted message when it is there. We hash both with your tenant secret and compare them to the hash on the registration. The address itself never reaches us on the API path. ### 3. The content fingerprint The quoted body goes through the same normalization you ran at registration and becomes a 64 bit SimHash. A match is Hamming distance 6 or less, a threshold you can tune per tenant and that we validate in the pilot. ### 4. Headers Only there when the customer forwarded as an attachment or their client kept them. When they are, we verify DKIM for your sending domains against the original message. ### 5. Links and indicators Every URL, domain, phone number, email address, and QR payload, with your own domains skipped. Stored on the submission, used now for Known fraud matching, clustered later. Normalization ## How both sides end up with the same fingerprint You run this at registration and we run the same code at verification, so a forwarded copy lands next to the original. This is the pipeline. - 01 Strip HTML to text and drop tracking pixels - 02 Unwrap gateway links (Proofpoint v2 and v3, Microsoft Safe Links, Google redirects) - 03 Remove forward chrome: Forwarded message markers, From/Sent/To/Subject blocks, "wrote:" lines, quote markers, device signatures - 04 Remove our own footer block - 05 Cut at the signature delimiter - 06 Replace every URL with its bare registered domain - 07 Collapse whitespace and lowercase - 08 SimHash over word 3-gram shingles with FNV-1a 64, identical bits in Node, Bun, and Workers The verdict ## The verdict function It is a pure function: no I/O, no model, no randomness. It implements the matching rules table and a test covers every row, including replay. In order: - Known fraud first, when an indicator is on your fraud list or the fingerprint matches a lure your analyst confirmed. - Verified when the code leads to a registration and the recipient matches, unless both fingerprints exist and are far apart, in which case the customer gets Not verified and we flag a replay. - Not verified when the code is real but the recipient does not match. Flagged as a replay when the fingerprint is far or missing; a close fingerprint from the wrong mailbox is someone forwarding from a second account, not an attack. - Verified with no code at all, when the nearest registration for that recipient inside the window is within the fingerprint threshold. - Not verified otherwise, worded as "we did not send this" only when you are in Authoritative Mode. Pipeline ## What happens to a forward, in three hops One Hono API on Cloudflare Workers fronts everything. Queues keep the mail pipeline off the request path, so a burst of forwards never slows down registration. Neon Postgres is the system of record, D1 is the edge mirror, R2 holds the raw messages. ### Ingest Resend hands us the raw MIME through a Svix signed webhook. We copy it to R2 under your tenant prefix, encrypted, and put it on the queue. ### Match Parse, authenticate, extract, look the code up in the edge mirror, compare the recipient hash, compute the fingerprint, run the verdict function. ### Reply Render your template for that verdict with the locked block and timestamp, send it from your reply identity, fire your webhooks, and queue the intelligence job. FAQ ## Questions we get on the first call **Why does a registry beat a classifier?** Because they answer different questions. A classifier estimates whether a message looks like phishing. A registry knows whether you sent this message to this person. The first is a probability that better writing can beat; the second is a lookup an attacker cannot insert themselves into. **What survives a forward?** The verify code almost always does, which is why it is our primary signal and why it appears twice in the footer. The recipient survives when the rule redirects rather than forwards. The body survives well enough that Gmail, Outlook, Apple Mail, and Proofpoint rewritten forwards of the same message land within Hamming distance 6 of the original. Headers survive only in attachment forwards. **What if an attacker copies our verify footer?** They will, and it helps you. The copied code belongs to one registration and one recipient. Pasted into a different message it fails the fingerprint; sent to a different person it fails the recipient. The customer gets Not verified and we flag a replay with high priority, which means the lure was delivered to your fraud team by its own target. **Is there any machine learning in the verdict?** No. Extraction and matching are regex, MIME parsing, a hash comparison, and a SimHash distance. The only model in the system reads screenshots, and we treat what it produces as untrusted text that feeds the same deterministic extractors. **How fast is it?** 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 150 ms for a registration. Code lookups are served from a D1 edge mirror with Neon behind it. **What does the customer see if we have not registered the message?** Not verified, worded as "no registered communication matches this message. That does not by itself mean it is fraudulent, but treat it with caution." We never say a message is fraudulent unless one of your analysts confirmed it, and never say "we did not send this" unless you are in Authoritative Mode. --- Page: Intelligence URL: https://fromenance.com/intelligence Intelligence # Every failed verification is a sensor Here is the part of Fromenance that we think matters most over time. Communication provenance answers the customer, and every time the answer is Not verified or Known fraud, you have just received a real impersonation attempt from the exact person it was written to fool. We pull the indicators out from day one; clustering them into campaigns, enriching the infrastructure, and warning other institutions early is the intelligence tier, and it is on the roadmap. Intelligence tier pricing What is in the box Why this signal ## A sensor nobody else has Threat intelligence vendors answer whether a piece of infrastructure is malicious. We answer whether you sent this message, and along the way we end up holding both halves of the picture: the authoritative record of what you sent, and the lures your own customers received and doubted. ### What you sent Every message you registered as you sent it, with a recipient bound code and a fingerprint of the text. Ground truth, not inference. ### What your customers doubted Lures convincing enough that a real customer paused and asked. Not a honeypot sample, not a feed of everything on the internet: the attacks actually reaching your customers this week. In the box ## What you get from the first submission The schema, the indicator store, and the intelligence queue are there from day one, so nothing ever has to be backfilled. ### Indicators from every non verified submission URLs, domains, IPs, phone numbers, email addresses, QR payloads, and wallet addresses, normalized, with first seen, last seen, and how many times. Your own domains are skipped. Everything stays in your tenant. ### The fraud list and Known fraud An analyst marks a submission as fraud and its indicators and fingerprint join your fraud list. The next customer who gets that lure hears Known fraud in seconds. Entries never come from a single anonymous submission. ### Replay flags A copied verify footer is the attacker telling you which template they are imitating. We flag replay attempts with high priority and count them on your overview. ### The template they are imitating Every Not verified submission records the nearest registered template by fingerprint, so you can see which of your own messages a campaign is copying. ### CSV and STIX 2.1 export From the Indicators table or through the API. Bulk add to the fraud list from the same view. ### Signed webhooks verdict.created, submission.replay_detected, and indicator.new to your SIEM, SOAR, or takedown vendor. HMAC-SHA256 with a per endpoint secret, 24 hours of retries with backoff, replay from the delivery log. Roadmap ## The intelligence tier We build this after a tenant is paying for verification, and the network layer after an analyst has confirmed a campaign from real submissions. That is a commitment to sequence, not to dates, and we would rather tell you that plainly. Roadmap ### IOC enrichment URL unshortening and redirect chain following in an isolated fetcher, a screenshot of the landing page to R2, TLS certificate fingerprint, hosting ASN, WHOIS age, and a phishing kit fingerprint from the landing page structure. Roadmap ### Campaign clustering Submissions cluster on shared indicators, fingerprint proximity (distance 10 or less), and kit fingerprint. Three or more in 72 hours becomes a campaign. Analysts name, merge, split, and close them. Roadmap ### Campaign view Timeline, members, shared infrastructure, a summary of the lure, the registered template it imitates, status, and one click export to your takedown vendor's webhook. Roadmap ### Feeds campaign.detected webhooks, STIX 2.1 and TAXII 2.1 endpoints, CSV, and Splunk and Sentinel saved searches in the docs. Roadmap ### Automatic Known fraud Once an analyst confirms a campaign, its indicators and fingerprints join the fraud list so later customers hear Known fraud in seconds. Confirmation stays with a person. Roadmap ### Cross institution early warning Correlation on indicators and kit fingerprints only, never on submissions or content. "Infrastructure associated with this campaign was observed targeting another financial institution 72 hours ago." No tenant ever learns who the other one is. Opt in. Closing the loop ## Where the indicators can go Once you know about an attack, the indicators can feed the systems you already run. - SIEM - SOAR - Email gateway blocklists - Web and DNS security - Takedown vendors - Fraud platforms - Contact center scripts - Customer alert banners --- Page: Communication provenance for banks URL: https://fromenance.com/solutions/banks Fromenance for banks # Your customer is staring at an email and cannot tell if it is you. Fromenance gives your bank communication provenance: you register every fraud alert, transaction alert, and wire notice as you send it, and a customer who forwards a suspicious one to verify@yourbank.com hears back from you in seconds with Verified, Not verified, or Known fraud. It is the layer above DMARC that your customer can actually see, and every lure they forward lands on your fraud team's desk with the indicators already pulled out. Talk to us about a pilot See how the matching works - Verified "Verified: this message matches a communication we registered and sent to you on September 24, 2026 at 10:42 AM UTC." - Not verified "Not verified: no registered communication matches this message. That does not by itself mean it is fraudulent, but treat it with caution." - Known fraud "Known fraud: this message matches an impersonation attempt our fraud team has confirmed. Do not interact with it." The week your team is having ## What lands in your customers' inboxes These are the lures fraud teams at banks tell us about, and what happens to each one once a customer can simply ask. ### The fake fraud alert "We noticed a card transaction" from jtmerlin-secure.com, your logo, a link to a login page that looks like yours. It passes DMARC, because the attacker owns that domain. Forwarded to verify@, it comes back Not verified, and the domain is in your indicators before the second customer calls. ### The copied footer Attackers copy your real verify footer to look legitimate. The code belongs to one registration and one recipient, so a copied code on a different message comes back Not verified and raises a replay flag. The lure just walked itself into your fraud team. ### The wire recall lure A commercial customer gets "your wire is on hold, confirm the details". Your registered wire notices verify in seconds. This one returns no record, and once you are in Authoritative Mode, the reply says you did not send it. ### The compromised vendor account Mail from a real but compromised third party domain passes SPF and DKIM cleanly. It is not in your registry, so it cannot verify. Your customer gets a definitive answer and the sending address becomes an indicator. ### The QR code statement A PDF or image with a QR code pointing at a lookalike. Your customer uploads a screenshot on yourbank.com/verify; OCR reads it into the same deterministic extractors and the QR payload is stored as an indicator. ### The "is this real" call Every contact center call tagged "is this real" costs you roughly $8 to $15, and the agent often cannot answer with certainty anyway. The verify@ reply answers in seconds, on your domain, with your fraud contact for anything that still looks off. Where to start ## Register these streams first Coverage is the whole game. Start with the messages your customers already squint at, because those are the ones they will forward. - 01 ### Fraud alerts The stream customers scrutinize most and forward most. The best first stream for a pilot, and where you will see footer replay first. - 02 ### Transaction and card alerts High volume, template driven, easy to register from the ESP webhook. Customers already know what a real one looks like, so a lure stands out when it fails. - 03 ### Wire and ACH notifications Lower volume, highest value per message. Register them with one call from the core banking or treasury platform, or through the journal path. - 04 ### Statements and account notices Batch runs from a statement vendor. Use the batch endpoint (up to 1,000 per call) or add journal-{slug}@ingest.fromenance.com as a BCC on the vendor's sending system. What changes ## Numbers you can take upstairs We capture every one of these inside the product, so the pilot report is an export, not a spreadsheet you build on a Friday. ### Fewer calls "Is this real" call volume on the pilot stream, before and during. You bring the contact center tags; we bring verification attempts split by forward and web. ### Abuse mailbox triage that becomes review Volume before and during, and analyst time on suspicious message triage per week. Submissions arrive with the indicators pulled out and a verdict already attached, so triage becomes review. ### Fewer takeovers to clean up Account takeover events traced to phishing of the pilot stream, plus the card reissues, disputes, and reimbursements that follow. Earlier Known fraud verdicts shorten the window in which a campaign works. ### Campaigns you found first Unique campaigns and the time from first submission to analyst confirmation. Lookalike domains discovered. Intelligence yield: the indicators your existing feeds did not have. ### Customers who keep reading your mail Every campaign teaches customers to distrust real mail, which drags on digital servicing. A verifiable footer on every alert gives them a reason to keep opening yours. ### An answer you can stand behind "We sent this to you on September 24 at 10:42" or "no registered communication matches". Wording your legal and compliance teams reviewed once and that never drifts in production. Examiners ## What to tell your examiner Fromenance is a customer facing fraud control with a paper trail. Every verdict is immutable, every analyst action is logged, and every registered communication carries a record of when it was sent and to whom, as a one way hash. That lines up with what examiners ask about under FFIEC guidance on customer authentication and fraud response, and it gives your incident reports a timestamped source of truth. We do not claim a certification. We give you the evidence and let your compliance officer frame it. Pilot ## What the pilot feels like 60 to 90 days on one stream, for a fixed fee that is credited to your first annual contract. We help with onboarding and write the report. ### Week 0 We sign the contract and the DPA and create your tenant. You publish one TXT record and one redirect rule. The wizard sends itself a test message and tells you when the rule is right. ### Week 1 You register one stream and paste the footer into that template. Replies go out from your own domain. The first customers usually ask that week. ### Weeks 2 to 12 It runs. We sit with your fraud lead for 30 minutes a week over Submissions and Indicators, and you get a report at day 30, 60, and 90. FAQ ## Questions we get on the first call **Do we have to route customer mail through Fromenance?** Only the messages your customers choose to forward to verify@yourbank.com, and only after the forwarding hop passes DKIM or ARC for your domain and your TXT record checks out. If your security review would rather start smaller, the web verify page needs no mail routing at all. **What does the customer actually see?** A reply from verify@verify.yourbank.com, or a subdomain you choose, in your branding, with the locked verdict and a next step. Our name is nowhere on it. On the web page, the same template renders in place. **How does this fit with our DMARC, gateway, and brand protection?** It sits above them. DMARC authenticates your domain, the gateway filters what reaches your staff, brand protection takes down lookalikes. None of them answer the customer holding the phone. We do, and we feed indicators back to all three. **Which stream should a bank pilot first?** Fraud alerts and transaction alerts. Customers already scrutinize them, they are template driven, and an ESP webhook or a single call at send time registers them without touching the core. **Our core banking vendor cannot call an API. Now what?** Add journal-{slug}@ingest.fromenance.com as a BCC or journaling target on the vendor's sending system. We receive the full message, hash the recipient, fingerprint the body, and register it. Pair it with a static per template code or the reserve flow so the footer still carries a code. --- Page: Communication provenance for credit unions URL: https://fromenance.com/solutions/credit-unions Fromenance for credit unions # A definitive answer for every member, with nobody on your team in the loop Fromenance gives credit unions communication provenance sized for a five person fraud team: register your member alerts as you send them, and a member who forwards a suspicious one to verify@yourcu.org hears back in seconds with Verified, Not verified, or Known fraud, while your team reviews only what failed. Setup is one TXT record, one redirect rule, and one footer. Talk to us about a pilot See how the matching works - Verified "Verified: this message matches a communication we registered and sent to you on September 24, 2026 at 10:42 AM UTC." - Not verified "Not verified: no registered communication matches this message. That does not by itself mean it is fraudulent, but treat it with caution." - Known fraud "Known fraud: this message matches an impersonation attempt our fraud team has confirmed. Do not interact with it." The week your team is having ## What lands in your customers' inboxes These are the lures fraud teams at credit unions tell us about, and what happens to each one once a customer can simply ask. ### The member alert lookalike "Unusual sign in on your account" from yourcu-alerts.com with your logo. It passes authentication for the attacker's domain. Forwarded to verify@, it comes back Not verified, and the domain is an indicator before the second member calls. ### The shared branch confusion Your members get real mail from partners, processors, and card vendors and cannot tell it apart from a lure. Register the vendor stream through the journal path and those messages verify too. ### The text to email pivot A lure arrives by SMS and points at a page that emails a "confirmation". The emailed confirmation is not in your registry. The web verify page answers in seconds. SMS itself, with the same code in a shorter footer, is on the roadmap. ### The copied footer A lure that copies your verify footer comes back Not verified and raises a replay flag. Attackers teach your members to use verify@, and then deliver their own lure to your fraud team through it. ### Five people, thousands of members A small fraud and security team cannot triage every "is this real" email. Submissions arrive with the signals, the indicators, and a verdict already attached, and the reply already went out. ### The "is this real" call Each one costs roughly $8 to $15 and the agent cannot answer with certainty. Every member who forwards to verify@ instead is a call that did not happen. Where to start ## Register these streams first Coverage is the whole game. Start with the messages your customers already squint at, because those are the ones they will forward. - 01 ### Fraud and card alerts The stream members scrutinize most. The best first stream for a pilot; register it from the ESP webhook or with a single call at send time. - 02 ### Account and transaction alerts High volume, template driven, and where lures most often imitate you. - 03 ### Loan and payment notices Auto loan, mortgage, and payment due notices from the loan servicing platform, registered through the journal BCC path when the vendor cannot call an API. - 04 ### Statements and e-notices Batch runs through the batch endpoint, or a journal target on the statement vendor's sending system. What changes ## Numbers you can take upstairs We capture every one of these inside the product, so the pilot report is an export, not a spreadsheet you build on a Friday. ### Fewer calls, fewer tickets Contact center "is this real" volume and abuse mailbox volume on the pilot stream, before and during, reported at day 30, 60, and 90. ### Analyst hours back Suspicious message triage per week, before and during. Submissions come pre-extracted and pre-decided; the analyst reviews and overrides, they do not parse. ### Earlier detection Time from first member submission to analyst confirmation of a campaign, and lookalike domains discovered from member forwards rather than from a monitoring feed. ### Fewer takeovers Account takeover events traced to phishing of the pilot stream, and the reimbursement and card reissue costs that follow them. ### Members who keep reading A verifiable footer on every alert gives members a reason to trust real mail, which protects e-statement adoption and digital servicing. ### Intelligence yield Indicators not present in your existing feeds, verified by your team, exportable as CSV or STIX for your gateway, SIEM, or takedown vendor. Examiners ## What to tell your examiner Examiners ask how members are protected from impersonation and how the credit union responds. Fromenance gives you a documented, member facing control: verdicts are immutable, analyst actions are audited, registered communications carry a timestamp and a recipient hash, and retention is a setting you own. Reports export from the admin app. We give you the evidence; your compliance officer frames it under NCUA guidance. Pilot ## What the pilot feels like 60 to 90 days on one stream. We help with onboarding, because we know how small the team is. ### Week 0 We sign the contract and the DPA and create your tenant. You publish one TXT record and one redirect rule. The wizard sends itself a test message and tells you when the rule is right. ### Week 1 You register one stream and paste the footer into that template. Replies go out from your own domain. The first customers usually ask that week. ### Weeks 2 to 12 It runs. We sit with your fraud lead for 30 minutes a week over Submissions and Indicators, and you get a report at day 30, 60, and 90. FAQ ## Questions we get on the first call **We have a five person team. How much work is this, honestly?** One TXT record, one mailbox with a redirect rule, one footer paste, and one ESP webhook or a single call at send time. The setup wizard walks through the six steps and sends a test message before you go live, and the docs give click by click steps for Google Workspace and Microsoft 365. After that the reply is automatic and the analyst's job is review. **How is it priced for a credit union?** Annual contracts banded by protected members. The small credit union band, up to 250K, is $20K to $40K per year for the Verification tier with 2 domains, 3 sources, 5 users, and 90 day retention. The pilot is a fixed fee credited to the first contract. **Does it help with NCUA examinations?** It gives you a customer facing fraud control with an immutable verdict log, an audit trail of every analyst action, and a written pilot report with before and during numbers. That is evidence for your program, not a certification. **What happens when a vendor message is not registered?** The member gets Not verified with the words "no registered communication matches", never "fraudulent". An analyst can mark it legitimate, which registers it retroactively and flags the coverage gap on that source so you can add the vendor stream. **Can members use it without email?** Yes. yourcu.org/verify takes pasted text, an .eml file, or a screenshot and renders the verdict on the page in your branding. No account, nothing to install. --- Page: Communication provenance for insurance carriers URL: https://fromenance.com/solutions/insurance Fromenance for insurance carriers # Claims, billing, and policy messages your policyholders can check in seconds Fromenance gives insurance carriers communication provenance: register claims, billing, and policy communications as you send them, and a policyholder who forwards a suspicious one to verify@yourcarrier.com hears back in seconds with Verified, Not verified, or Known fraud. Adapters for Salesforce Marketing Cloud and Braze cover the enterprise sending stack, and every lure forwarded lands with your SIU as an indicator. Talk to us about a pilot See how the matching works - Verified "Verified: this message matches a communication we registered and sent to you on September 24, 2026 at 10:42 AM UTC." - Not verified "Not verified: no registered communication matches this message. That does not by itself mean it is fraudulent, but treat it with caution." - Known fraud "Known fraud: this message matches an impersonation attempt our fraud team has confirmed. Do not interact with it." The week your team is having ## What lands in your customers' inboxes These are the lures fraud teams at insurance carriers tell us about, and what happens to each one once a customer can simply ask. ### The claims payout lure "Your claim has been approved, confirm your bank details" from yourcarrier-claims.com. Your registered claims messages verify. This one comes back Not verified and the payout page domain becomes an indicator for your SIU. ### The premium overdue notice A fake billing notice with a payment link, timed to renewal season. Your registered billing notices verify in seconds; the lure fails and its phone number and URL are pulled out. ### The policy document with a QR code A PDF "policy update" with a QR code to a credential page. Policyholders upload a screenshot on yourcarrier.com/verify; OCR reads it into the same deterministic extractors and the QR payload is stored. ### The agent impersonation Mail that looks like it comes from a captive or independent agent, sent from a free mail account. Not in your registry, so Not verified, and the sending address is an indicator you can share with the agency channel. ### The copied footer A lure that copies your verify footer comes back Not verified and raises a replay flag. The attacker just showed you which template they are imitating. ### The contact center question "Did you send me this?" is a call that costs roughly $8 to $15 and ends without a certain answer. verify@ answers in seconds, from your domain. Where to start ## Register these streams first Coverage is the whole game. Start with the messages your customers already squint at, because those are the ones they will forward. - 01 ### Claims communications Claim received, adjuster assigned, payout issued. Highest fraud value and highest scrutiny. Register from the claims platform with one call at send time, or from SFMC through the reserve flow. - 02 ### Billing and premium notices Payment due, payment received, autopay changes. Template driven, high volume, and the most imitated around renewal. - 03 ### Policy changes and renewals Endorsements, renewals, cancellation warnings. Register through the ESP adapter; Salesforce Marketing Cloud and Braze work with a pre-send reserve call. - 04 ### Documents and statements Batch runs from the document vendor: the batch endpoint, or a journal BCC on the vendor's sending system. What changes ## Numbers you can take upstairs We capture every one of these inside the product, so the pilot report is an export, not a spreadsheet you build on a Friday. ### Fewer "is this real" calls Contact center volume on the pilot stream before and during, split by forward and web verification. ### Faster claims fraud response A claims payout lure is found by the policyholder it targeted, in the first hour, with the payout domain already extracted for your SIU. ### Agency channel protection Indicators from agent impersonation lures, exportable as CSV or STIX to share with agencies and your gateway. ### Analyst time back Suspicious message triage per week, before and during. The verdict and the indicators arrive attached. ### Digital adoption that holds Policyholders who can verify a message keep opening real ones, which protects paperless and self service adoption. ### A record you can defend Immutable verdicts and a timestamped registry give your compliance team a record of what was sent, when, and what the policyholder was told. Examiners ## What to tell your examiner Carriers answer to state insurance regulators and, for many lines, to data security rules modeled on the NAIC Insurance Data Security Model Law. Fromenance gives you a documented, policyholder facing fraud control: immutable verdicts, an audited analyst trail, configurable retention, US data residency, and a DPA with a subprocessor list. We provide the evidence; your compliance team maps it to each state's requirements. Pilot ## What the pilot feels like 60 to 90 days on one stream. We help with the SFMC or Braze reserve flow, which is the part that takes an afternoon. ### Week 0 We sign the contract and the DPA and create your tenant. You publish one TXT record and one redirect rule. The wizard sends itself a test message and tells you when the rule is right. ### Week 1 You register one stream and paste the footer into that template. Replies go out from your own domain. The first customers usually ask that week. ### Weeks 2 to 12 It runs. We sit with your fraud lead for 30 minutes a week over Submissions and Indicators, and you get a report at day 30, 60, and 90. FAQ ## Questions we get on the first call **We send from Salesforce Marketing Cloud. Does that work?** Yes. SFMC cannot hand us the rendered body, so a pre-send SSJS call reserves a verify code, an AMPscript merge field places it in the footer, and the send event completes the registration. Matching then leans on the code plus the recipient. Braze works the same way through connected content and a Liquid attribute. **Which stream should a carrier pilot first?** Claims communications or billing notices. Policyholders scrutinize both, attackers imitate both, and both are template driven enough to register from the ESP or the claims platform without a large project. **How does this relate to state insurance regulators?** Regulators increasingly ask about customer facing fraud controls and incident response. Fromenance gives you a documented control with an audit trail, retention you configure, and a data protection addendum. It is evidence for your program; your compliance team maps it to each state's requirements. **What does the policyholder see?** A reply from your reply identity in your branding with the locked verdict and a next step, or the same template rendered on yourcarrier.com/verify. Our name is nowhere on it. **What do you store about a policyholder?** On a registration: a one way hash of their address and a fingerprint of the text, never the address or the body. On a submission: the forwarded message encrypted for your retention window, and the submitter's address encrypted and purged 30 days after the reply. --- Page: Communication provenance for utilities URL: https://fromenance.com/solutions/utilities Fromenance for utilities # Outage, billing, and disconnection notices your customers can check before they pay Fromenance gives utilities communication provenance: register billing, outage, and disconnection notices as you send them, and a customer who forwards a suspicious one to verify@yourutility.com hears back in seconds with Verified, Not verified, or Known fraud. Disconnection lures fail the moment they arrive, and their phone numbers and domains land with your team as indicators. Talk to us about a pilot See how the matching works - Verified "Verified: this message matches a communication we registered and sent to you on September 24, 2026 at 10:42 AM UTC." - Not verified "Not verified: no registered communication matches this message. That does not by itself mean it is fraudulent, but treat it with caution." - Known fraud "Known fraud: this message matches an impersonation attempt our fraud team has confirmed. Do not interact with it." The week your team is having ## What lands in your customers' inboxes These are the lures fraud teams at utilities tell us about, and what happens to each one once a customer can simply ask. ### The disconnection threat "Your service will be disconnected today unless you pay now", with a payment link or a phone number. The most common utility lure there is. Your registered disconnection notices verify; this one fails and the phone number is pulled out as an indicator. ### The overpayment refund "You overpaid, claim your refund", pointing at a card harvesting page. Not in your registry, so Not verified, and the domain is on your fraud list after one analyst click. ### The outage update During a real outage, lures ride the news. Your registered outage notices verify in seconds, so customers can tell the real update from the fake one while the lights are still off. ### The smart meter or rebate notice Program enrollment lures on a lookalike domain. Screenshot upload handles the ones that arrive as images. ### The copied footer A lure that copies your verify footer comes back Not verified and raises a replay flag. It tells your team which notice template is being imitated. ### The "is this real" call Each one costs roughly $8 to $15, and they peak exactly when the contact center is busiest. verify@ answers in seconds without an agent. Where to start ## Register these streams first Coverage is the whole game. Start with the messages your customers already squint at, because those are the ones they will forward. - 01 ### Billing notices Bill ready, payment due, payment received, autopay changes. Highest volume, most imitated. Register from the ESP webhook or the billing platform's journal BCC. - 02 ### Disconnection and collections notices The lure attackers reach for first. Register these and Authoritative Mode becomes reachable for the stream customers fear most. - 03 ### Outage and service notices Planned work, outage updates, restoration. Register through the ESP adapter so real updates verify during an event. - 04 ### Program and rebate communications Energy efficiency, smart meter, and rebate enrollment messages. Batch endpoint, or the journal path from the program vendor. What changes ## Numbers you can take upstairs We capture every one of these inside the product, so the pilot report is an export, not a spreadsheet you build on a Friday. ### Call deflection at peak Contact center "is this real" volume on the pilot stream before and during, including during outages, when it matters most. ### Fewer payment scams that complete Customers who check before paying do not pay the lure. Time from first submission to analyst confirmation of a campaign shortens the window. ### Abuse mailbox triage Volume before and during, and analyst time per week. Submissions arrive with indicators and a verdict. ### Intelligence yield Phone numbers, domains, and payment page URLs from lures, exportable as CSV or STIX for your gateway and for law enforcement referrals. ### Trust in real notices Customers who can verify a disconnection notice keep reading them, which protects collections and paperless billing. ### A documented control Immutable verdicts and audited analyst actions give your customer protection program a record for regulators and commissions. Examiners ## What to tell your examiner Public utility commissions and consumer protection offices ask utilities how customers are protected from payment scams and impersonation. Fromenance gives you a documented, customer facing control with immutable verdicts, an audited analyst trail, configurable retention, and exportable indicators for referrals. We provide the record; your regulatory team frames it for your commission. Pilot ## What the pilot feels like 60 to 90 days on one stream, timed so the pilot spans at least one full billing cycle. ### Week 0 We sign the contract and the DPA and create your tenant. You publish one TXT record and one redirect rule. The wizard sends itself a test message and tells you when the rule is right. ### Week 1 You register one stream and paste the footer into that template. Replies go out from your own domain. The first customers usually ask that week. ### Weeks 2 to 12 It runs. We sit with your fraud lead for 30 minutes a week over Submissions and Indicators, and you get a report at day 30, 60, and 90. FAQ ## Questions we get on the first call **Which stream should a utility pilot first?** Billing notices or disconnection notices. Both are imitated constantly, both are template driven, and customers already scrutinize them. Outage notices come second, because real updates need to verify during an event. **Our customers get lures by phone and text too. Does this help?** Phone numbers and QR codes in forwarded email lures are extracted as indicators today. The SMS channel, with the same code in a shorter footer and verification by short code or web paste, is on the roadmap. Voice is scoped later. **How much DNS do we have to touch?** One TXT record for trust. If you want replies from a subdomain such as verify.yourutility.com, three more records for the sending domain. The web verify page needs none. **What does the customer see?** A reply from your domain in your branding with the locked verdict and a next step, or the same template rendered on yourutility.com/verify. Our name is nowhere on it. **Our billing vendor cannot call an API. Now what?** Add journal-{slug}@ingest.fromenance.com as a BCC or journaling target on the vendor's sending system and we register from the full message. Pair it with a static per template code or the reserve flow so the footer still carries a code. --- Page: Fromenance vs DMARC and BIMI URL: https://fromenance.com/compare/dmarc Compare # Fromenance vs DMARC and BIMI If you have DMARC at reject, good, keep it, and Fromenance depends on it. Communication provenance answers a different question than DMARC does: DMARC tells a receiving server that a message really came from your domain, and Fromenance tells your customer whether you actually sent that message to them. A lure from a lookalike domain passes SPF, DKIM, and DMARC because it really did come from the lookalike, and that is exactly where your customer needs the second answer. How the matching works What is in the box Side by side ## What each one does | Question | DMARC (with SPF, DKIM, BIMI) | Fromenance | | What does it check? | A domain. SPF says the sending server is allowed to send for the domain; DKIM signs parts of the message for a signing domain; DMARC insists the two line up with the visible From. | A communication. Did this institution send this message to this person at this time? We check a verify code, a hash of the recipient's address, and a fingerprint of the text against your registry. | | Who sees the result? | Receiving mail servers, and you, through aggregate and forensic reports. The customer sees nothing, unless BIMI is set up and their client shows a logo. | The customer, in a reply from your domain or on your verify page, in seconds. | | Does it stop lookalike domains? | No. A message from jtmerlin-secure.com with correct SPF, DKIM, and DMARC for that domain passes. DMARC only governs your real domain. | A lookalike message is not in your registry, so it comes back Not verified, and the lookalike domain becomes an indicator. | | Does it stop free mail and compromised accounts? | No. Mail from a Gmail account, or from a vendor whose account was taken over, authenticates cleanly for that domain. | Same answer: not registered, so Not verified, and the sending address is pulled out as an indicator. | | Does it handle display name impersonation? | No. DMARC never looks at the display name. | The display name does not matter to us either way. Only the registry counts. | | What does the customer learn? | Nothing they can act on. Authentication results live in headers most clients hide. | A locked verdict, a next step, and your fraud contact. | | What do you learn? | Aggregate reports about who is sending as your real domain. Genuinely useful for catching unauthorized senders and misconfigured vendors. | Every lure a customer doubted, with its indicators, delivered by the person it targeted. Replay flags show you which templates are being copied. | | What does it take to deploy? | DNS records and a policy ramp from none to quarantine to reject, which usually means months of finding out who sends on your behalf. | One TXT record, one redirect rule, one footer, one registration path. We require the forwarding hop to pass DKIM or ARC, so we build on your DMARC work rather than replacing it. | The gap ## Why a lure passes DMARC DMARC is good at what it does. It stops direct spoofing of your protected domain, and attackers noticed years ago. ### What they send instead - Lookalike domains: bank-security.com, bankalerts.net, Unicode homoglyphs - Free mail accounts with your display name - Compromised legitimate domains, including your vendors' - Legitimate SaaS sending infrastructure with your logo pasted in - SMS, QR codes, and images that never touch DMARC at all Each of these authenticates correctly for the domain it was sent from. DMARC is doing its job. The job is just not your customer's question. ### What BIMI adds, and what it cannot BIMI puts your logo next to messages that pass DMARC with a strict policy, in clients that support it, if you hold a verified mark certificate. It is a real positive signal, and some customers in some clients will notice it. What it cannot do is give the customer anything to do about a message that lacks the logo, which is every lure. And logos are exactly what attackers paste in. We give the customer an action instead: forward it, paste it, get an answer. Both ## Why you want both We are built on your DMARC work. We only process mail to your tenant inbox when the forwarding hop passes DKIM or ARC for a domain you own, and the reply identity we recommend is a DKIM signed subdomain. So keep DMARC at reject, and add the layer your customer can see. --- Page: Fromenance vs brand protection and takedown vendors URL: https://fromenance.com/compare/brand-protection Compare # Fromenance vs brand protection and takedown vendors Brand protection vendors are good at what they do: they find impersonation infrastructure from the outside and get it taken down. Fromenance is communication provenance, which starts from the other end: the customer holding the lure gets an answer from you, and the lure itself becomes intelligence. Different sensor, different moment in the attack, and institutions run both and connect them. The intelligence layer What is in the box Side by side ## What each one does | Question | Brand protection and takedown | Fromenance | | What is the sensor? | Crawlers, domain registration feeds, certificate transparency logs, app stores, social platforms, and sometimes your abuse mailbox. | The customer who just received the lure. Every submission is a real impersonation attempt that was convincing enough for its target to pause and ask. | | When does it see an attack? | When the infrastructure becomes visible: a domain is registered, a certificate is issued, a page gets crawled. Sometimes before mail goes out, sometimes after. | When the first customer forwards it, which is usually inside the first hour of a campaign reaching inboxes. We do not see infrastructure that never reaches a customer. | | What does the customer get? | Nothing directly. The customer is not part of the workflow. | A definitive Verified, Not verified, or Known fraud reply from your domain, in seconds, with a next step. | | What does it do about the attack? | Files takedowns with registrars, hosts, and platforms, with a lag measured in hours to days depending on who is on the other end. | Answers the customer, pulls out the indicators, adds confirmed lures to your fraud list so the next customer gets Known fraud in seconds, and exports the indicators to your takedown vendor, gateway, and SIEM. | | Does it know what you actually sent? | No. Brand protection works from the outside in and has no record of your legitimate communications. | Yes. The registry is the authoritative positive set. That is what makes Verified possible at all. | | Which channels? | Web, domains, social, app stores, marketplaces. Broad, and focused on infrastructure. | Email in v1, plus the indicators from lures across any channel a customer forwards. SMS, documents, and voice are on the roadmap. | | How do they work together? | Receives indicators and campaign exports from us through signed webhooks and STIX 2.1, and gets the earliest possible signal: the lure itself. | Uses your takedown vendor as the enforcement arm. We do not file takedowns. | The gap ## A different sensor Monitoring and takedown platforms earn their keep, and we export to them. The gap is the person on the other end of the message. ### Outside in Monitoring works from public signals: new domains that resemble yours, certificates, cloned pages, fake apps. It finds infrastructure. It cannot tell your customer whether the message in their inbox is yours, and it only sees the campaigns whose infrastructure a crawler can reach. ### Inside out We start from what you sent. A submission that does not match is, by construction, a message that reached a real customer and claimed to be you. Its domains, links, phone numbers, and QR codes are pulled out in seconds, and you can push them to your takedown vendor through a signed webhook or a STIX export. The vendor gets the lure before their crawler would have found the page. Both ## Why you want both Keep your takedown vendor; they are the enforcement arm. Add us as the answer your customer gets and the earliest sensor you have, and connect the two with the indicator.new and verdict.created webhooks. On the roadmap, a confirmed campaign exports to your takedown vendor with one click. --- Page: Fromenance vs consumer scam detector apps URL: https://fromenance.com/compare/scam-detector-apps Compare # Fromenance vs consumer scam detector apps Scam detector apps and the AI features showing up in mail clients do something useful: they estimate whether a message looks like a scam, for every sender at once. Fromenance is communication provenance, which is a different primitive: the institution itself answers whether it sent the message, from a registry of what it actually sent. One is a probability from a third party. The other is a record from the sender, and only the second is something a bank can put its name on. Why a registry beats a classifier What is in the box Side by side ## What each one does | Question | Scam detector apps and AI inbox features | Fromenance | | Who answers? | A third party app, or an AI feature in the mail client, trained on what scams tend to look like. | The institution the message claims to be from, using its own registry of what it sent. | | What is the answer? | A score or a label: likely scam, suspicious, probably fine. Useful guidance. Still a probability. | Verified, Not verified, or Known fraud. A lookup, not an estimate, with wording that is locked so it never claims more than the registry supports. | | What happens with a well written lure? | AI written phishing took away the tells, the grammar and the odd phrasing, that classifiers and people leaned on. A polished lure scores lower. | Writing quality does not enter into it. A lure is not in the registry no matter how good it reads, and a copied footer fails the recipient or the fingerprint check. | | What happens with your real messages? | Legitimate alerts get flagged often enough that customers learn to ignore the warning, or worse, the alert. | A registered message verifies, with the time you sent it. Your customer learns that real mail from you can be checked, which protects trust in the real alerts. | | Can the answer be gamed? | Models can be probed and lures tuned until they pass. Prompt injection is a live concern for AI inbox assistants. | There is no model on the verdict path. Regex, MIME parsing, a hash comparison, and a fingerprint distance. Nothing a lure can say changes a verdict. | | What do you learn? | Nothing. The app belongs to the customer or the mail provider. | Every lure a customer doubted, with indicators, replay flags, and the template it imitates, in your fraud team's admin app within seconds. | | What does the customer install? | An app, an extension, or a mail client feature, with its own permissions over their inbox. | Nothing. Forward to verify@ or paste on your verify page. No account, no install, and our name is nowhere on it. | | Who stands behind the answer? | The app vendor's terms disclaim the result. | You do, with "matches a communication we registered" and "no registered communication matches". The reply never uses stronger language than that. | The gap ## Detection and provenance Both have a place. They are different questions. ### Detection asks - Does this message look malicious? - Is this domain suspicious? - Does this resemble scams we have seen? Good detection catches a lot. It cannot catch a lure that looks exactly like the real thing, and it cannot confirm that the real thing is real. ### Provenance asks - Do we have a record that this institution sent this exact message to this person? That is a lookup only the institution can make. Customers already forward messages to a friend, search online, and call support. We point a habit they already have at the one party that knows. Honestly ## The honest limit We only answer for institutions that register their communications. A scam detector app covers every sender at once, at the cost of never being certain. For the institutions that adopt it, Fromenance is certain about what they sent, and it is the only approach that turns the customer's question into intelligence for the institution. --- Page: Pilot URL: https://fromenance.com/pilot Pilot # Sixty to ninety days, one stream, one real answer A Fromenance pilot puts communication provenance on one live stream of your messages for 60 to 90 days, for a fixed fee of $10K to $15K that we credit to your first annual contract. You get help with the setup, thirty minutes a week with us, and a written report of who asked, what they were told, which campaigns turned up, what your feeds missed, and the operational numbers you actually care about. Start the conversation What it costs after the pilot Week by week ## What it feels like ### Week 0: paperwork and plumbing We sign the contract and the DPA and create your tenant. You publish the TXT record and the redirect rule. The wizard sends itself a test message, and you go live the moment it comes back clean. ### Week 1: the first customers ask You register one stream and paste the footer into that template. Replies leave from your own domain. Somewhere in that week a customer forwards a real alert, and then a lure, and you watch both come back. ### Weeks 2 to 12: it runs Thirty minutes a week with your fraud lead over Submissions and Indicators. Interim reports from the Overview export at day 30 and 60. At day 90, the pilot report, the Authoritative Mode readiness review, and a proposal. Your side ## What you bring We kept this list deliberately short. The setup wizard walks through the six steps and will not let you go live until the forwarding test passes. ### One TXT record _fromenance.yourdomain.com, with the token the setup wizard gives you. We poll every 60 seconds until it resolves. ### One mailbox and one redirect rule verify@yourdomain.com, redirected (not forwarded) to your tenant inbox. We have guides for Google Workspace, Microsoft 365, Proofpoint, Mimecast, and Cisco Secure Email. ### One stream, registered Fraud alerts or transaction alerts. An ESP webhook, one HTTPS call at send time, or a journal BCC, and the footer pasted into that one template. ### A reply identity A DKIM signed subdomain such as verify.yourdomain.com (three DNS records), or our reply domain with your display name and logo, which we only allow for the pilot. ### Your baseline numbers Contact center "is this real" call volume and abuse mailbox volume on the pilot stream for the period before, so the report has a before and a during. ### Thirty minutes a week A weekly look at Submissions and Indicators with your fraud lead. We watch coverage and trust rejections every day from our side. Our side ## What you walk away with Every number below is captured by the product as it runs. The report is an export, not a spreadsheet exercise. ### Verification volume How many customers asked, split by forward and web, and what they were told: Verified, Not verified, Known fraud, and replay flags. ### Campaigns and lookalikes Unique phishing campaigns discovered, the time from first submission to your analyst confirming it, and lookalike domains found from customer forwards. ### Intelligence yield Indicators that were not in your existing feeds, checked by your team. Exportable as CSV or STIX 2.1. ### The operational deltas Call volume, abuse mailbox volume, analyst triage time per week, and account takeover events traced to the pilot stream, before and during. ### Coverage and readiness Registered volume against the volume you told us to expect, per source, the trust check rejection rate, and an Authoritative Mode readiness review at day 90. ### A proposal The annual contract for your band with the pilot fee credited, and a plan for the second stream. Our targets ## The numbers we hold ourselves to during the pilot | Metric | Target | | Reply time, inbound to reply sent, p95 | under 10 seconds | | Web verify, submit to verdict, p95 | under 3 seconds (text), under 15 seconds (screenshot) | | Verify code found rate on forwards | above 85 percent with the footer deployed | | Match rate on legitimate submissions | above 95 percent | | False Verified (overridden to fraud) | zero tolerated; each one is an incident | | Registration API p95 | under 150 ms | | Trust check rejection rate, healthy tenant | under 1 percent | | Coverage per registered stream | above 90 percent | Talk to us ## Start the conversation Tell us which stream you would register first and what the pilot would have to prove to you. --- Page: Pricing URL: https://fromenance.com/pricing Pricing # Bands, not a calculator We price Fromenance the way institutions buy fraud infrastructure, not the way they buy seats: communication provenance for everyone you send to, on an annual contract banded by how many customers you protect. There is a Verification tier and an optional Intelligence tier, and almost everyone starts with a 60 to 90 day pilot on one stream, with the pilot fee credited to the first contract. See the pilot Talk to us Bands ## Annual bands Verification tier prices are annual ranges. The Intelligence tier is an add on to the same band. The top band is quoted. | Band | Protected customers | Verification tier | Intelligence tier | Includes | | Small credit union | Up to 250K protected customers | $20K to $40K per year | +$15K per year | - 2 domains - 3 sending sources - 5 users - 90 day retention | | Mid-size credit union or bank | 250K to 1M protected customers | $40K to $80K per year | +$25K per year | - 5 domains - Unlimited sending sources - 15 users - 180 day retention - SSO | | Regional bank | 1M to 3M protected customers | $75K to $150K per year | +$50K per year | - Unlimited domains - 50 users - 1 year retention - SSO - Outbound webhooks - STIX and TAXII feeds | | Large regional bank or carrier | 3M+ protected customers | $150K to $300K+ per year | Quoted | - Everything above - Relay tier - Dedicated support - Custom DPA | Every band includes the API, the ESP adapters, the journal path, verify@ forwarding, the hosted verify page and widget, screenshot OCR, the analyst tools, exports, and a DPA. We meter registrations and verifications for reporting and fair use only. Pilot ## Where almost everyone starts How long 60 to 90 days One stream of your messages. What it costs $10K to $15K Fixed, and credited to your first annual contract. What comes with it Setup help and a report Thirty minutes a week with us, reports at day 30, 60, and 90. FAQ ## Questions we get on the first call **What counts as a protected customer?** A customer of yours who could receive a registered message. We set the band on that count, not on how many messages you send. We count registrations and verifications for reporting and fair use, and we do not bill per unit. **What is in the Verification tier?** The whole verification product. Registration through the REST API, the ESP adapters, and the journal path; verify@ forwarding and the hosted verify page and widget; screenshot OCR; the three verdicts with replay detection; reply templates; the admin app with submissions, overrides, the fraud list, indicators, and CSV and STIX export; source health; retention controls; and the domains, sources, users, and retention listed for your band. **What is in the Intelligence tier?** The intelligence features as they ship: campaign clustering, IOC enrichment, the campaign view, campaign.detected webhooks, STIX 2.1 and TAXII 2.1 feeds, automatic Known fraud on campaigns your analysts confirm, and opt in cross institution early warning. These are roadmap items, and we sell the tier as a commitment to build them in that order, not as a promise of dates. **How does the pilot work?** 60 to 90 days on one stream for a fixed fee of $10K to $15K, which we credit to your first annual contract. It comes with help on the setup and a written report. **Can we sign up ourselves?** No. You are an institution and this is a conversation, not a checkout. This site books calls. **How does billing work?** Stripe holds the customer record and invoices annually or quarterly. If you outgrow your band we talk about it at renewal, not in the product. **What about the top band?** Large regional banks and carriers with more than 3M customers get a quote. That band includes the relay tier, dedicated support, and a custom DPA. --- Page: Security URL: https://fromenance.com/security Security # The answers your vendor review will ask for We are asking you to let customer mail pass through Fromenance, so we finished the security work before we asked anyone to pilot communication provenance with us. This page answers the questions a bank's third party risk review asks, in the order they usually ask them: what we store, how long we keep it, how tenants are kept apart, and who our subprocessors are. The DPA makes all of it contractual. Read the DPA security@fromenance.com Data ## What you store about our customers ### Do you receive our customers' email addresses? Not on the API path. Your application hashes the lowercased, trimmed address with your tenant secret and sends us only the hash. Our communications table has no column for an address. Where we have to see one, on a forward or through the journal path, it is encrypted with a key specific to your tenant and purged 30 days after use. ### What happens to the forwarded messages? The raw MIME of every submission goes into R2 under your tenant's prefix, encrypted with a tenant scoped key that lives in Workers secrets and rotates yearly. We keep it for your retention window, 90 days by default, and then delete it and write a deletion record to the audit log. ### Can a fingerprint be turned back into a message? No. We hold the normalized text only long enough to compute a SimHash and a SHA-256, and we do not persist it. Fingerprints are one way. ### Does the reply repeat the suspicious message? Never. The verdict reply does not quote the message, does not include its links, and does not name its sender. The verdict block is locked text. ### What can you see across tenants? Indicators and counts. Our backoffice intelligence view, and the network layer on the roadmap, never touch submissions, raw MIME, or content. ### Where is the data? In the United States, all of it, in v1. Our subprocessors are listed below and in the DPA. Retention ## What we keep, and for how long | Data | Form | Retention | | Registered communication | Verify code, recipient HMAC, SimHash and SHA-256 fingerprint, message id, From address, sent time, link domains, template and campaign ids | Your retention window, default 90 days | | Forwarded or uploaded message | Raw MIME or screenshot, encrypted in R2 under your tenant prefix | Your retention window, default 90 days, deleted with an audit record | | Submitter address | HMAC for matching; encrypted copy for the reply only | Encrypted copy purged 30 days after the reply | | Verdict | Outcome, rule, signals, matched registration id, override trail | Life of your account | | Indicators | Kind, normalized value, first and last seen, counts | Life of your account | | Rejected inbound | Mail that failed the trust check, with the reason | 24 hours | | Audit log | Actor, action, target, before and after | Life of your account | Trust and abuse ## How you stop it being gamed ### How do you know a forward really came from us? We drop mail to your tenant inbox unless the sending hop passes DKIM or ARC for a domain you own with a valid _fromenance TXT token. Rejected mail is held 24 hours so we can diagnose it, then deleted. ### What if someone copies a real verify code? A valid code on the wrong message or the wrong recipient comes back Not verified for the customer and raises a high priority replay flag for you. ### How is the verify page protected from abuse? Rate limited per IP (60 per minute) and per site key, only from an origin you allow, and escalated to Cloudflare Turnstile when a site key exceeds its normal rate. ### Could someone poison our fraud list? Anyone can forward anything to your inbox through your own rule, so fraud list entries come only from an analyst's action or, on the roadmap, a confirmed campaign. Never automatically from a single submission. ### Is there an LLM anywhere in the verdict? No. Extraction is regex, MIME parsing, and SimHash; matching is an HMAC comparison and a Hamming distance. Screenshot OCR runs in Workers AI and its output is untrusted text that only feeds those extractors. Any future lure classifier produces a fixed schema label and can never change a verdict from Verified. ### How do you handle replayed or duplicate requests? Every provider webhook signature is verified with a 5 minute replay window. Every creating call takes an idempotency key we keep for 24 hours. Platform ## How the platform itself is secured ### How do your staff and ours sign in? Admin app users sign in with Better Auth using email magic link and passkeys. Our backoffice sits additionally behind Cloudflare Access with a hardware key requirement. SSO (SAML and OIDC) is on the roadmap. ### How are keys handled? API keys are hashed at rest, shown once, scoped (register, read, admin), revocable, and tracked by last use. Site keys are public, tied to your tenant and your page's origin, and carry no secret. ### How are tenants kept apart? Every tenant owned table carries a tenant id and every query goes through a scoped repository that requires it. R2 prefixes are per tenant. An automated suite asserts that no endpoint reads across tenants, on every change. ### What is encrypted, and with what? Encrypted columns hold AES-256-GCM ciphertext produced with a per tenant data key wrapped by a master key that lives only in Workers secrets. TLS everywhere. Secrets never appear in configuration or source. ### Is there an audit trail? Every write in the admin app and the backoffice is logged with actor, action, target, before, and after. When our operators look at your tenant, it is read only and audited. ### How do you run the platform? Secrets live in Workers secrets only. Neon and R2 credentials rotate quarterly. Dependencies are scanned. Deploys happen only from CI on the main branch. We watch it through Workers Logs, Analytics Engine, and Sentry. Subprocessors ## Who else touches the data At runtime, nothing runs outside Cloudflare, Neon, and Resend. Stripe holds billing and Sentry receives error events. We tell tenants 30 days before we add anyone, as the DPA describes. | Subprocessor | Purpose | Location | | Cloudflare, Inc. | Hosting, edge compute, edge storage (D1, R2, Queues), Workers AI for screenshot OCR, Turnstile | United States | | Neon, Inc. | Postgres system of record | United States | | Resend, Inc. | Inbound and outbound email | United States | | Stripe, Inc. | Billing | United States | | Functional Software, Inc. (Sentry) | Error monitoring | United States | Compliance ## SOC 2 and disclosure ### Where are you on SOC 2? We are targeting SOC 2 Type 1 within 12 months of our first paying tenant. Until then, this page, the DPA, and a completed vendor security questionnaire are what we offer your third party risk review. Send us yours and we will fill it in. ### How do we report a vulnerability? Email security@fromenance.com . We acknowledge within two business days, keep you informed, and do not pursue researchers who act in good faith, avoid privacy violations and service disruption, and give us reasonable time to fix. Please do not test against tenant inboxes or production tenant data; the demo tenant on this site is there for that. If we confirm a security incident that touches your data, we tell you without undue delay and no later than 72 hours after we confirm it. --- Page: About URL: https://fromenance.com/about About # Why I built this Fromenance started with a phone call my mother made two months ago. Communication provenance is the answer I could not find for her that day: when a customer asks a bank "did you send this?", the bank should be able to say yes or no, in seconds, and mean it. The call ## What happened to my mother In July my mother got an email that looked exactly like her bank. Same logo, same tone, a warning that her account had been hacked and a link to secure it. She was careful. She did not type anything into the email. She clicked through to see what was going on, landed on a page that looked exactly like the bank, and that page gave her a phone number to call. So she called it. A calm, professional voice answered with the bank's name and walked her through "securing" the account. Her account had not been hacked. It was being hacked, right then, by the people on the phone, and the warning that brought her to them was the crime itself. By the time she hung up, thousands of dollars were gone. Every step she took was reasonable. She was skeptical enough to want to speak to a person, and she called the number she was given. What she never had was a way to ask the only question that mattered and get a real answer: did my bank actually send this? The bank had DMARC, but the email did not use the bank's domain. The spam filter had guessed and guessed wrong. The copycat site came down later, which helped the next person and did nothing for her. And if she had reached a real agent, the agent would have looked at the same email and guessed too. I started building Fromenance within days. The bank is the only party that knows for certain what it sent, so the record has to live on the bank's side, and the answer has to reach the customer before they pick up the phone. I wrote the whole story in The phone call my mother made . What we believe ## Three things we are sure about 01 ### Only the sender can answer Nobody else has the record. A classifier can say a message looks wrong. Only the institution can say "we sent this to you at 10:42" or "we have no record of this". So we built the registry on the sender's side and left the guessing to everyone else. 02 ### The answer should be definitive, and take seconds Not a score. Not a ticket that comes back on Thursday. Verified, Not verified, or Known fraud, with wording that is locked so it never claims more than the registry supports, delivered before the customer has put the phone down. 03 ### The fraud team should get the lure Every message that fails verification was convincing enough that a real customer paused and asked. That is a phishing sample delivered by its target. It should land on your fraud team's desk in seconds, with the domains and phone numbers already pulled out, not in an abuse mailbox someone reads on Friday. Who we are ## A small team, on purpose Fromenance is built by George Rios and a small team at Many Software Enterprises . George spent his career in enterprise software and insurtech, which is where he watched institutions buy control after control and still have to tell a customer "we can't be sure". Then it happened in his own family. We stay small because the product is infrastructure and the buyer is an institution. The sale is a conversation with the person who owns impersonation, and we would rather have that conversation ourselves. We write the way we build. If a page on this site makes a claim, the product makes the same claim in its tests. If we do not know a number, we do not print one. How we work ## What a pilot with us is like - We add to your stack, we do not replace it. Keep DMARC at reject. Keep your gateway and your takedown vendor. We sit above them, and we feed them what your customers send us. - Your customers never see our name. The address is on your domain, the page is on your domain, the reply is in your branding. Fromenance shows up in your admin app and our docs, and nowhere else. - Security first, then pilots. We finished the data handling story, the DPA, and the subprocessor list before the first pitch, because a bank's vendor review was always going to ask. - We build in order. The intelligence tier is built after a tenant is paying for verification. Cross institution warnings are built after an analyst has confirmed a campaign from real submissions. No calendar dates, just gates. --- Page: Glossary URL: https://fromenance.com/glossary 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. TXT "v=fromenance1; t=; k=", 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-@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. --- Page: Brand URL: https://fromenance.com/brand Brand # Fromenance, said and written correctly Fromenance is a communication provenance platform, and this page is the one reference for its name, mark, colors, type, and voice. Everything here is downloadable and stable; if you are quoting us, linking to us, or printing the name on a slide, use what is on this page. ## The name Fromenance is pronounced FROM-uh-nence : FROM as in "who is this from", then the ending of "provenance". IPA: /ˈfrʌm.ə.nəns/ . The stress is on the first syllable and the last two are unstressed, exactly as in "provenance". The word is a portmanteau of FROM and PROVENANCE . Provenance is the documented origin of a thing; Fromenance is the provenance of who a communication is from. The name says what the product does: it answers the question "did this really come from you?" with a record rather than a guess. **Spelled** Fromenance. One word, capital F, nothing else capitalised. **Said** FROM-uh-nence **IPA** /ˈfrʌm.ə.nəns/ **Category** communication provenance (lower case, two words) **Never** FromEnance, FROMENANCE in running text, Fromenance.com as the name, "the Fromenance" ## The mark and the wordmark The mark is a rounded square with a small accent square inside it, the same accent square that marks the current tenant in the app shell. The wordmark is the mark followed by the name set in the site typeface at weight 600. On dark backgrounds On light backgroundsSolid variant on photography or unknown backgrounds ### Downloads - fromenance-mark-on-dark.svg Mark for dark backgrounds - fromenance-mark-on-light.svg Mark for light backgrounds - fromenance-mark-solid.svg Solid mark for photography and unknown backgrounds - fromenance-wordmark-on-dark.svg Wordmark for dark backgrounds - fromenance-wordmark-on-light.svg Wordmark for light backgrounds - colors.json Color tokens for both themes All files are SVG or JSON. No PNG is provided; render from the SVG at the size you need. ## Logo usage ### Clear space Keep one mark height of clear space on every side of the mark or the wordmark. Nothing else, including text, other logos, or a page edge, enters that space. ### Minimum size Mark: 24 px. Wordmark: 96 px wide. Below that, use the mark alone or write the name in text. 24 px 96 px ### Backgrounds Use the on-dark variant on dark backgrounds and the on-light variant on light ones. On photography, illustrations, or any background you do not control, use the solid mark. ### What not to do - Do not recolor the mark or wordmark beyond the two variants and the solid mark. - Do not stretch, rotate, skew, or crop either asset. - Do not add shadows, gradients, outlines, glows, or any other effect. - Do not rewrite or retype the wordmark, and do not set the name in another typeface as a substitute. - Never pair the mark with a padlock, shield, or checkmark icon; Fromenance is provenance, not a security seal. - Never place the mark or wordmark inside a customer's email footer as if it were a seal of approval. The footer uses the customer's own name and address, and "verify with Fromenance" is the only permitted mention. ## Color Two palettes, one accent, and three reserved colors. Green, amber, and red belong to the verdicts Verified, Not verified, and Known fraud and are never used decoratively, in charts, or for status of any other kind. Dark theme (default) | | --bg | #0b0c0f | Page background | | | --fg | #e8e8ea | Text | | | --muted | #9a9aa3 | Secondary text | | | --line | #24252b | Borders and rules | | | --card | #121317 | Raised surfaces | | | --accent | #4f8cff | Links, buttons, the mark's square | | | --verified | #34c27a | Verified only | | | --not-verified | #e0a92b | Not verified only | | | --known-fraud | #e5484d | Known fraud only (border and tint) | | | --known-fraud-fg | #f26b70 | Known fraud text on the tinted badge | Light theme | | --bg | #ffffff | Page background | | | --fg | #0b0c0f | Text | | | --muted | #5c5c66 | Secondary text | | | --line | #e3e3e8 | Borders and rules | | | --card | #f4f4f6 | Raised surfaces | | | --accent | #1d5fd6 | Links, buttons, the mark's square | | | --verified | #116b36 | Verified only | | | --not-verified | #7a4f00 | Not verified only | | | --known-fraud | #b3161c | Known fraud only (border and tint) | | | --known-fraud-fg | #b3161c | Known fraud text on the tinted badge | Verdict colors, as rendered in the current theme: Verified Not verified Known fraud ## Typography ### Typeface Inter when available, otherwise the system stack: ui-sans-serif, system-ui, -apple-system, "Segoe UI", Roboto, sans-serif. Inter loads without blocking rendering, so the system face is what you see for the first few hundred milliseconds and that is fine. Weights: 400 for body, 500 for labels and buttons, 600 for headings and the wordmark. No other weights. Code, tokens, and verify codes are set in the system monospace stack. Make every customer communication verifiable. Medium 500 for labels and buttons Regular 400 for body copy, at 15 to 16 px with a 1.6 line height. KX73-PQ9G · sk_pub_demo_jtmerlin · --accent ## Voice and words ### Voice - Direct, technical, specific. Written for fraud and security professionals. - Headlines say what the product does, not how it feels. Every claim is one the product makes in its tests. - No exclamation marks. No em dashes. No marketing filler: if a word could appear in any vendor's deck, cut it. - Short sentences, concrete nouns, numbers where we have them. ### Words - Fromenance is always one word with a capital F. Never "FromEnance", never "Fromenance.com" as the name. - The category is "communication provenance". Not anti-phishing, not email security. - The verdict words are exactly Verified , Not verified , and Known fraud , in that capitalisation. - A verdict never says a message is harmless. The word for that is not in our vocabulary and does not appear in any reply, page, or slide. - Authoritative Mode, verify code, recipient hash, content fingerprint, replay: as defined on the glossary . ## How to refer to Fromenance in customer facing copy ### Permitted phrases - Verified with Fromenance - Powered by Fromenance - verify with Fromenance Text only, in the customer's own typeface. No mark, no wordmark, no icon. ### The footer line format The footer in a registered message belongs to the institution. It uses the institution's name and addresses, carries the verify code twice, and may end with the permitted mention: 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 with Fromenance. The last line is optional. Nothing else about Fromenance appears in the footer, and the mark never does. ## Press kit Mark for dark backgroundsfromenance-mark-on-dark.svg Mark for light backgroundsfromenance-mark-on-light.svg Solid mark for photography and unknown backgroundsfromenance-mark-solid.svg Wordmark for dark backgroundsfromenance-wordmark-on-dark.svg Wordmark for light backgroundsfromenance-wordmark-on-light.svg Color tokens for both themescolors.json Everything above plus this page: https://fromenance.com/brand (the color table and the usage rules). Boilerplate: Fromenance is a communication provenance platform for banks, credit unions, insurers, and utilities. Institutions register every outbound communication at send time; a customer who forwards a suspicious message to the institution's verify address gets Verified, Not verified, or Known fraud in seconds, and every failed verification becomes threat intelligence. Fromenance is a trademark of Many Software Enterprises LLC. --- Page: Communication provenance explained URL: https://fromenance.com/blog/communication-provenance-explained Blog # Communication provenance explained Communication provenance is sender side evidence that an institution issued a specific communication to a specific recipient. Fromenance explains the primitive, how it differs from authentication and detection, and why it produces a definitive answer. George Rios 2026-08-18 3 min read 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 . communication provenance category Next Why DMARC passes on phishing --- Page: The phone call my mother made URL: https://fromenance.com/blog/the-phone-call-my-mother-made Blog # The phone call my mother made Fromenance exists because of one email, one copycat page, and one phone number. The founder's account of the scam that took thousands of dollars from his mother, and why communication provenance is the answer he could not find that day. George Rios 2026-09-27 5 min read I started Fromenance because of a phone call my mother made two months ago. Everything the product does, and the reason we call the category communication provenance, comes back to the minutes she spent on that call, so I want to tell the story plainly before I say anything about software. ## The email It arrived on an ordinary day in July and looked like every other message her bank had ever sent her. Same logo. Same colors. A line saying there had been suspicious activity on her account and that she needed to secure it right away. A link. She is careful, and she did what careful people are told to do: she did not reply to the email and she did not type her password into it. She clicked the link to see what was going on. The link took her to a page that looked like the bank. Not close to the bank. Like the bank. It repeated the warning, and it did the thing that made all the difference. It gave her a phone number to call. ## The call She called it. A calm, professional voice answered with the bank's name, thanked her for calling so quickly, and walked her through "securing" the account. The person on the line had been expecting her, because they had written the email, built the page, and put their own number on it. Over the next few minutes they asked for the things a bank might plausibly ask for, and she gave them, because she believed she was talking to the people whose job it was to protect her. Here is the part that still gets me. The email said her account had been hacked. It had not been. It was being hacked, right then, while she was on the phone with the people doing it. The urgency was not a warning about a crime. It was the crime. By the time she hung up, feeling relieved, thousands of dollars were gone. ## What she did right, and why it did not matter I have gone over it many times, and I keep landing in the same place. She did not fall for anything stupid. She got a message that looked legitimate, she was skeptical enough to want to speak to a person, and she called the number she was given. Every step was reasonable. The problem was that at no point did she have a way to ask the only question that mattered, and get a real answer: did my bank actually send this? The bank had DMARC. The email did not come from the bank's domain, so DMARC had nothing to say about it. Her mail provider's filter had let it through, because it looked like a thousand real ones. The copycat site was taken down eventually, which helped the next person and did nothing for her. Every control in the chain was doing its job. None of them could tell her, in the moment she needed it, whether the message in front of her was real. And the honest answer is that the bank could not have told her either, even if she had found the real number and reached a real agent. The agent would have looked at the same email she was looking at and guessed. ## The question nobody could answer That is the gap I could not stop thinking about. The one party that knows for certain whether a message is real is the institution that did or did not send it. Banks send millions of messages and keep no record that a customer can check against. So the customer is left to judge appearance, and appearance is exactly what the attacker controls. Fromenance is my answer to that afternoon. An institution registers every communication as it goes out, with a short code inside it. When a customer wonders, they forward the message to an address on the bank's own domain, or type the code on the bank's own page, and within seconds they get one of three fixed answers: it matches a communication we registered, no registered communication matches, or we did not send this. No score, no "probably", and no words that overpromise. The reply is written so that it never claims more than the record supports. If my mother had been able to forward that email to her bank and get "no registered communication matches" back in a few seconds, she would not have called the number. I am fairly sure of that, because the reason she called was that she wanted someone to confirm what was going on. She was looking for exactly this, and it did not exist. ## The other half There is a second thing in that story that I did not appreciate until later. The email, the copycat page, and the phone number were a complete phishing kit, delivered straight to a real customer of the targeted bank. If she had forwarded it to the bank, the bank's fraud team would have had the lure, the domain, and the number within seconds, while the campaign was still running. Instead it went into a spam folder, and the number kept ringing for whoever called next. So Fromenance does that too. Every message that fails verification goes to the tenant's fraud team with the domains and phone numbers already pulled out. Customers who are worried enough to ask become the fastest source of intelligence the bank has, and the number my mother called could have been blocked before the next person dialed it. ## Why I am telling you this I am not sharing this to make anyone feel sorry for her. She is fine, she is sharper about this than most people I know now, and she gave me permission to write it. I started building Fromenance within days of that call, and it has been the whole of my working life for the two months since. I am sharing it because when I talk to security teams about impersonation, the conversation tends to stay abstract: takedown rates, DMARC coverage, classifier accuracy. Those numbers are real and they matter. But the customer on the phone, being told her account is hacked by the people hacking it, is what the numbers are for. Fromenance is a communication provenance platform, and it was built so that the next person in her position can ask one question and get a straight answer before they pick up the phone. If you run fraud or security at an institution and this story sounds familiar, I would like to hear yours. founder communication provenance vishing Previous When attackers copy the verify footer --- Page: What survives an email forward URL: https://fromenance.com/blog/what-survives-an-email-forward Blog # What survives an email forward Fromenance matches forwarded messages against a communication provenance registry, so it matters exactly what Gmail, Outlook, Apple Mail, and a Proofpoint gateway do to a message on the way through. Here is what survives and what does not. George Rios 2026-09-10 3 min read We spent a surprising amount of the early build forwarding the same email to ourselves from every mail client we could find, and this post is what we learned. A forwarded email arrives with the original wrapped in the client's forward chrome, its links rewritten by a gateway, its headers mostly gone, and its footer possibly rewrapped. Fromenance builds communication provenance on what reliably survives that trip, which is why the verify code is our primary signal, the recipient comes from the redirect envelope, and the content fingerprint is computed only after a normalization pass strips off everything the forward added. ## What each client does Gmail wraps the original in a ---------- Forwarded message --------- block with From, Date, Subject, and To lines, converts the body to its own HTML, and keeps links intact. The original headers are gone unless the user picks "Forward as attachment". Outlook (desktop and web) inserts a From/Sent/To/Subject header block, often prefixed with -----Original Message----- , and may rewrap long lines in plain text. Safe Links, if the tenant has Microsoft Defender, rewrites every URL through safelinks.protection.outlook.com . Apple Mail adds "Begin forwarded message:" and a header block, and quotes the body with > markers in plain text. Device signatures ("Sent from my iPhone") get appended. Proofpoint and Mimecast at the customer's employer rewrite links through urldefense.com (v2 and v3 encodings) or Mimecast's URL protection, sometimes strip images, and sometimes add banners. ## What reliably survives - The verify code. An 8 symbol code in a sentence of plain text survives every client and every gateway. It appears twice in the footer, once in the sentence and once on its own, so at least one copy survives aggressive rewrapping and a screenshot read by OCR. The eighth symbol is a checksum, so the extractor ignores anything that merely looks like a code. In practice we find the code on well above 85 percent of forwards once the footer is deployed. - The customer's address. When your verify@ rule redirects (rather than forwards) to the tenant inbox, the customer stays the envelope sender and their address survives. This is why the setup wizard tests the rule and refuses to go live on a forward. A forward swaps the sender for the mailbox and loses the customer. - The visible text. Most of it. Words survive; formatting, images, tracking pixels, and link targets do not. ## What does not survive - The original headers , unless the customer forwards as an attachment. When they do, we verify DKIM on the original for your sending domains. - Link targets , which gateways rewrite and sometimes strip. This is why normalization replaces every URL with its bare registered domain before fingerprinting, and unwraps Proofpoint v2 and v3, Safe Links, and Google redirects first. - Whitespace, case, and line breaks. Collapsed. ## The normalization pipeline The normalization that runs at verification is published in the docs as a dependency free TypeScript file, so a registration computed with it and the verification computed by the API produce the same bits: - HTML to text, dropping tracking pixels - Unwrap gateway links - Remove forward chrome: forwarded message markers, From/Sent/To/Subject blocks, "wrote:" lines, quote markers, device signatures - Remove the verify footer itself - Cut at the signature delimiter - Replace every URL with its registered domain - Collapse whitespace and lowercase - SimHash over word 3-gram shingles with FNV-1a 64 A match is Hamming distance 6 or less out of 64 bits. Our test fixtures for the same message forwarded from Gmail, Outlook, Apple Mail, and through a Proofpoint rewrite all land within that distance of the original; an unrelated lure lands around 30 bits away. ## Why the order of signals matters The code is strongest because it belongs to one registration and one recipient and survives everything. The recipient is second because it survives a redirect. The fingerprint is third because it survives most forwards but degrades under aggressive gateways. Headers are last because they rarely arrive at all. The verdict function evaluates in that order and reports which rule fired, so an analyst can see whether a Verified came from code+recipient+content or from recipient+fingerprint alone. More on the trust model and the verdict function . matching fingerprinting Previous Why DMARC passes on phishing Next When attackers copy the verify footer --- Page: When attackers copy the verify footer URL: https://fromenance.com/blog/when-attackers-copy-the-verify-footer Blog # When attackers copy the verify footer Attackers will copy an institution's verify footer into their lures. Fromenance communication provenance is designed for that: the code is bound to one registration and one recipient, so a copied footer fails and hands the lure to the fraud team. George Rios 2026-09-22 3 min read The second question we get on almost every call, right after the DMARC one, is "won't attackers just copy the footer?" Yes. They will, and Fromenance communication provenance is built on the assumption that they will. A copied footer says "forward this to verify@bank.com ", which is an instruction to deliver the lure straight to your fraud team, where it fails, because the code belongs to a registration and a recipient the attacker does not control. ## Why the footer gets copied The footer is the most trustworthy looking sentence in a real message: "Not sure this email is from JT Merlin Bank? Forward it to verify@jtmerlin.com or enter code KX73-PQ9G at jtmerlin.com/verify." A lure that includes it looks more legitimate to a customer, so copying it is the rational move. It is also the last thing the attacker wants the customer to actually do. ## What happens when they do The verify code belongs to one registration, which carries one recipient hash and one content fingerprint. When a copied footer arrives on a lure: - The code resolves to the original registration. It is a real code. - We compare the recipient. If the lure went to a different person, the hash of their address does not match the registration. Not verified, flagged as a replay. - We compare the content. If the lure went to the same person (the attacker harvested the original), the fingerprint of the lure is far from the fingerprint of the real message. Not verified, flagged as a replay. Either way the customer hears "no registered communication matches this message", and your fraud team gets a submission marked replay with high priority, carrying the lure's domains, links, and phone numbers as indicators, and the registered template it was imitating. ## What the attacker learns That codes belong to a recipient and to a message, so copying one does not work. The likely adaptations are to make up codes or to drop the footer. A made up code has to pass the checksum to be extracted at all, and a code that passes the checksum but leads nowhere is treated as no code: the submission falls through to the recipient plus fingerprint rule, which the lure also fails. Dropping the footer removes the thing that made the lure look legitimate in the first place, and a customer who has learned to look for it notices. ## What you learn Every replay tells you which template is being imitated and how quickly. Replay counts show up on your overview, replay events go out as submission.replay_detected webhooks to your SIEM, and the imitated template guess on each Not verified submission tells your analyst which stream to watch. ## The one thing to get right None of this works unless the code belongs to the recipient. A footer with a static per template code proves only that someone once had a real message from that template. We issue one code per message, computed at registration with the recipient hash, and the reserve flow does the same for ESPs that cannot give us the body. The static code is a stopgap for journal fed vendor streams, and we document it as one. Definitions for replay attack and footer replay are in the glossary . The full rule table is on how it works . replay threat model Previous What survives an email forward Next The phone call my mother made --- Page: Why DMARC passes on phishing URL: https://fromenance.com/blog/why-dmarc-passes-on-phishing Blog # Why DMARC passes on phishing Fromenance explains a communication provenance basic: a lure from a lookalike domain passes SPF, DKIM, and DMARC because those controls authenticate the attacker's domain, not your message. George Rios 2026-08-31 3 min read The first question we get from almost every fraud lead is some version of "we already have DMARC at reject, so what does this add?" It is a fair question, and the honest answer is that DMARC passes on most phishing because DMARC authenticates a domain, and attackers stopped using yours. Fromenance exists because communication provenance, evidence that your institution sent this message to this person, is a different question from domain authentication, and it is the one your customer is actually asking. ## What DMARC actually checks SPF answers whether the sending server is allowed to send for the domain in the envelope. DKIM answers whether parts of the message were signed by a key published under a signing domain. DMARC requires that one of those domains lines up with the domain in the visible From header, and tells receivers what to do when neither does. That is the whole test. There is no check of the display name, the logo, the body, the links, or whether the domain in the From header has anything to do with your institution. ## What attackers send instead Spoofing jtmerlin.com directly fails DMARC at a bank with a reject policy, so attackers do not bother. They send from: - Lookalike domains: jtmerlin-secure.com , jtmerlinalerts.net , Unicode homoglyphs - Free mail accounts with "JT Merlin Bank Fraud Team" as the display name - Compromised legitimate domains, including your vendors' and your customers' employers' - Legitimate SaaS sending infrastructure, where the platform configured SPF and DKIM correctly Every one of these authenticates cleanly for the domain it was sent from. jtmerlin-secure.com has valid SPF, a valid DKIM signature, and an aligned From header. DMARC passes. DMARC is doing its job. Its job just is not your customer's question. ## What BIMI adds BIMI puts your logo next to messages that pass DMARC with a strict policy, in clients that support it, if you hold a verified mark certificate. It is a real positive signal, and some customers in some clients will notice it. What it cannot do is give the customer anything to do about a message that lacks the logo, which is every lure. And logos are exactly what attackers paste in. A missing logo is not an answer. ## The question nobody in the chain answers The customer holding the message wants to know one thing: did my bank send this to me? SPF, DKIM, and DMARC cannot answer it because they have no record of what your bank sent. A gateway can estimate. A brand protection vendor can look for the lookalike domain later. The only party with the record is you. That is what a communication provenance registry is for. You register each message as you send it, with a recipient bound verify code and a fingerprint of the text. When the customer forwards the lure to verify@jtmerlin.com , there is no registration for it, and the reply says so: no registered communication matches. When they forward a real alert, the reply says you sent it, and when. ## Keep DMARC at reject None of this replaces DMARC. We depend on it: we only process mail to a tenant inbox when the forwarding hop passes DKIM or ARC for a domain the tenant owns, and the reply identity we recommend is a DKIM signed subdomain. DMARC keeps your real domain from being spoofed. Provenance answers your customer about everything else. Read the full comparison or how the matching works . dmarc email authentication Previous Communication provenance explained Next What survives an email forward