Privacy Policy

Account data

Your email address, which is how you sign in — we send a single-use link rather than storing a password. Alongside it we keep your workspace membership, your role in that workspace, and sign-in timestamps.

DMARC aggregate report data

Mailbox providers send aggregate reports about mail claiming to come from your domains. Each report contains the IP address of the sending host, SPF and DKIM authentication results for that host, message counts, the policy the provider applied, and the domains involved. Source IP addresses can identify a sender, so we treat them as personal data.

Two enrichments are applied to a source IP: a country is resolved against a GeoLite2 database held locally by our parsing worker, and a reverse DNS lookup is performed against public DNS to give the host a readable name. The address itself is not sent to a geolocation vendor.

We also keep the original report file each provider sent, and a record of each delivery we accepted or rejected.

SMTP TLS report data

If you publish an SMTP TLS reporting record, providers send us daily summaries of how their connections to your mail servers were encrypted. These contain the policy your domain published, the mail hosts involved, connection counts, and the reasons any connection failed. They describe servers, not individual messages.

DMARC forensic (failure) report data

We do not collect this today. The DMARC record we ask you to publish requests aggregate reports only, so mailbox providers have no address to send failure reports to, and the forensic viewer in the product is switched off. If we enable failure reports in future — they can contain subject lines, recipient addresses, and message headers — we will store them separately from aggregate data, restrict them to workspace owners and administrators, log every read, and update this page before turning the collection on. Forensic fields are already excluded from application logs and error reports, and are never included in any AI prompt.

Pilot request form

When you request pilot access we store the email address, name, company, number of sending domains, first domain, current tooling, plan interest, and message you submit. We also store your browser user agent and, when the rate-limit pepper is configured, a keyed HMAC hash of your IP address so repeat submissions can be throttled. The raw IP address is not stored.

Billing data

Subscriptions are processed by Stripe. We keep the subscription and plan state needed to run your account. We never receive or store full card numbers.

Operational data

Server logs, ingestion and processing events, error traces, and an audit log of administrative actions taken in your workspace. Forensic content is scrubbed before an error leaves the application.

To provide the service you asked for: receiving reports at your workspace address, normalizing them, storing them against your domains, and presenting them in the dashboard. To authenticate you, to bill you, to send service notifications and digests, to keep the service secure and rate limited, and to respond to enquiries you send us.

We do not sell your data. We do not sell derived source-IP reputation data to third parties. We do not use your report data or forensic content to train machine learning models, and we do not submit forensic content to any model vendor.

Paid workspaces can generate written insights from their report data. The prompt we send to the model vendor carries the domain name, its published policy, and aggregate figures — compliance percentages, message and failure counts, and a short list of that domain’s busiest sending sources with their volumes and failure rates.

A sending source is identified by its provider name, its organizational domain, or the host’s reverse-DNS name. Where none of those resolved, the source is identified by its raw IP address, and that address is included in the prompt. Forensic content, message bodies, subject lines, and recipient addresses are never included.

Insights are generated on request and are informational. They are not a substitute for reviewing the underlying report evidence.

We use the vendors below to run the service. Each one receives only what its function requires. This list changes when our stack changes, and this page is updated in the same change.

Report data is stored in the United States (AWS us-west-1). Where personal data is transferred out of the EEA or the UK, we rely on the European Commission's Standard Contractual Clauses (SCCs), together with the UK International Data Transfer Addendum where the transfer is from the UK.

Every query that reads workspace data is scoped to a workspace resolved from your session, with row-level isolation enforced in the database underneath it. We do not currently collect forensic (failure) reports at all: the DMARC record we ask you to publish requests aggregate reports only, and the forensic viewer is switched off. Inbound report webhooks are rejected unless they present the credentials we issued for that endpoint. Sign-in links are single-use and short-lived.

No system is immune. If we confirm a breach affecting your data, we will notify you and give you the facts we have, without waiting for the investigation to close.

We keep report data for as long as your workspace is active. We do not currently apply a fixed automatic retention window and we do not automatically delete report data on a schedule — we would rather tell you that plainly than quote a period we do not yet enforce. Pilot enquiry records and audit-log entries are likewise kept until deletion is requested.

How long we keep data and how much of it you can see are different things. Every report screen and export in the product reads the last 30 days only, so reports older than that remain stored but are not visible or exportable through the service.

Deleting a domain from your dashboard is a real deletion, not a hidden flag: it permanently removes that domain’s aggregate reports, the per-source records underneath them, and its SMTP TLS reports from our database, and it cannot be undone. One exception, stated plainly: the original report files providers send us are stored under an address derived from the file’s own contents, so one stored file can be the copy for more than one customer. Those raw files are not removed by a domain deletion.

Deleting a whole workspace or account is handled on request by a person, not by an automated flow. When you ask us to delete one, we remove the workspace’s report data and revoke access. We keep the minimum audit references needed to preserve the record of who did what.

To request a copy of your data, a correction, an export, or deletion, email support@folderly.com. We respond within 30 days. We may need to confirm you control the account before acting.

We set the cookies required to keep you signed in and to keep the application secure. We do not run advertising or cross-site tracking cookies on this service.

Folderly DMARC is a business tool. It is not directed at children and we do not knowingly collect data from them.

If this policy changes materially we will update the date above and tell account holders before the change takes effect. Questions, requests, and procurement reviews go to support@folderly.com, or by post to 8 The Green, STE 300, Dover, DE 19901, United States.