Retention and privacy
Fromenance is a communication provenance platform that handles customer mail on your behalf, so what it keeps and for how long is a setting you control and a list you can read here. This page is written for the person answering your vendor security questionnaire.
By the end you will know every stored field, every retention clock, and the four things that are never stored.
Retention setting
Section titled “Retention setting”Settings, Retention, or PATCH /v1/tenant with retention_days (7 to 730, default 90). It drives:
| Data | Lifetime |
|---|---|
| Registrations | Expire at expires_at, which defaults to send time plus retention_days. Expired registrations no longer match; a registration you pass an explicit expires_at for keeps that value |
Raw MIME of forwarded messages and uploaded .eml files |
Deleted after retention_days, with a deletion record in the audit log |
| Screenshots | Same as raw MIME |
| Submissions, verdicts, indicators | Kept for the life of the tenant; they hold hashes, results, and extracted indicators, not message content |
Independent of the setting:
| Data | Lifetime |
|---|---|
| Submitter address (the customer who forwarded or typed their address) | Encrypted with your tenant key, kept only to send the reply and link repeat submissions, purged 30 days after the reply |
| Subject of a forwarded message | Encrypted with your tenant key, follows the raw MIME lifetime |
| Rejected inbound (mail that failed the trust check) | 24 hours, then deleted |
| Idempotency keys and stored responses | 24 hours |
| Uncompleted reservations | 24 hours by default (1 to 72 per call), then marked expired |
| Webhook deliveries and payloads | Kept in the delivery log for the life of the tenant. Payloads contain verdicts and indicators, never message content |
| Audit log | Kept for the life of the tenant |
What is stored
Section titled “What is stored”Per registration: the recipient hash, message id, From address, send time, subject and content fingerprints (one way hashes), link domains, your template and campaign ids, the provider, the verify code, and expiry.
Per submission: entry point, timestamps, the code found, the submitter hash, the recipient hash found in the innermost To header, the content fingerprint, whether headers were present, DKIM, ARC, and trust results, the sending domain, the raw MIME key (until deletion), the encrypted submitter address (until purge), and the extracted indicators.
Per verdict: outcome, rule, confidence, signals, the matched registration id, reply time, and any override with its note.
What is never stored
Section titled “What is never stored”- A raw recipient address on a registration. The API rejects anything that is not already an HMAC; the SDK hashes locally. The column does not exist in the schema.
- The normalized text used for fingerprinting. It exists in memory for the duration of one call and is discarded; only the SimHash and SHA-256 are kept.
- Quoted message content in replies. Replies never include the suspicious message, its links, or its sender. The verdict block is locked text.
- Your message bodies from the API path.
register()sends fingerprints. Only the journal path and ESP body retrieval see a body, and then only to fingerprint it before it is discarded.
Encryption
Section titled “Encryption”Each tenant has its own data key. Encrypted columns (submitter addresses, subjects, source configuration, webhook and source secrets, the recipient hashing secret) are AES-256-GCM ciphertext under that key. Raw MIME and screenshots in object storage are encrypted under the tenant key as well and stored under a per tenant prefix. Keys are wrapped by a master key that lives only in the runtime’s secret store. See Security.
Exporting and deleting
Section titled “Exporting and deleting”- Indicators export as CSV or STIX 2.1 from the admin app or
GET /v1/indicators/export; every table exports CSV. - Raw MIME is downloadable by analysts, admins, and owners while within retention, and every download is audited.
- Deleting the tenant (owner only) removes registrations, submissions, verdicts, indicators, raw objects, and keys; only the audit record of the deletion remains. Ask your Fromenance contact for a signed deletion confirmation if your policy requires one.
Data residency
Section titled “Data residency”All storage and processing is in the United States in v1. A DPA is available from day one; see Security for the subprocessor list.