skink.devverified
Sign up

Data Retention & Deletion

Last updated: 2026-08-26

This page describes how long skink keeps different categories of data, and how you can request earlier deletion.

Principles

Minimize what we store, delete on a defined schedule, and honor deletion requests promptly.

Retention schedule

  • Submitted email addresses (readable copy, encrypted at rest by default; a cryptographic hash-only mode is available as an opt-in account setting) — Purpose: deliverability verification on the controller's documented instructions. Retention: 1–365 days per your account's retention setting (365 days by default). Legal basis: legitimate interest (Art. 6(1)(f)), per controller's documented instructions (DPA). Deletion: automatic purge on schedule expiry; deletion on request (including via the per-verification delete control described below).
  • Verification results (status, confidence score, signals) — Purpose: return the deliverability verdict to the controller. Retention: same schedule as the submitted address. Legal basis: same basis as submitted address data above. Deletion: automatic purge on schedule expiry; deletion on request.
  • Internal accuracy ground-truth data (bounce reports, the engine's own probe-derived labels) — Purpose: measure and improve verification accuracy over time. This is separate from, and predates, shared accuracy learning (below). Legal basis: legitimate interest (Art. 6(1)(f)) — accuracy improvement. Retention/deletion: governed by this same schedule; we do not currently run a separate fixed-duration automatic purge for this category beyond the schedule above.
  • Shared accuracy-learning evidence (only created when a customer opts in — see Section 3a of our Privacy Policy) — Purpose: with the customer's affirmative authorization, evaluate and improve verification accuracy using eligible outcome signals from their own account. Data is linked to a domain-level token, not directly to the submitted recipient address. Legal basis: legitimate interest, per the customer's own opt-in authorization. Deletion: turning the setting off stops new contributions immediately; it does not automatically delete evidence already collected. We have not yet defined a fixed retention period for this category — this page will be updated once we do.
  • Bulk upload files and results — Purpose: process your bulk verification job. Retention: until your bulk job and its retention window expire; per-email cache entries within 24 hours of processing. Legal basis: legitimate interest (Art. 6(1)(f)), per controller's documented instructions (DPA). Deletion: automatic expiry and purge.
  • Account and billing records — Purpose: legal, tax, and accounting compliance. Retention: as required by applicable law. Legal basis: legal obligation. Deletion: scheduled purge per legal/tax hold requirements.
  • Backups (on-server and off-site) — Purpose: disaster recovery only. Retention: on-server 3 days; off-site 30 days. Legal basis: security and availability measures (DPA; Security page). Deletion: automatic aging out on schedule.
  • Operational logs (off-site archive) — Purpose: security and abuse investigation. Retention: off-site 180 days. Legal basis: security and availability measures (Security page). Deletion: automatic aging out on schedule.

Deletion on request

  • You can delete an individual verification record directly from the product at any time — see "Per-verification deletion" above for exactly what that does and doesn't remove.
  • For deletion requests covering data outside that self-service control (e.g., every record matching a specific address across your account), contact privacy@skink.dev — we remove matching records by their hash, including any cached copies, subject to the same boundaries described above.
  • Closing your account deletes your data per the schedule above, subject to legal or tax hold requirements. Account deletion is a soft delete: the account row is immediately flagged (deleted_at set, credentials and stored token secrets nulled, the account email obfuscated) so sign-in and API access stop instantly, while the underlying records are then purged on the schedule above. Backups taken before the deletion still contain the pre-deletion data per the Backups section below.

Automatic purging

A scheduled job removes records once their retention period expires. This runs continuously, independent of any manual deletion request.

Backups

Database backups come from two independent layers, both encrypted at rest. An hourly automated backup keeps an on-server copy for 3 days and mirrors a copy off-site retained for 30 days. The off-site layer is treated as disaster-recovery only: backups are not queried, analyzed, or accessed as part of normal operation. Deleting data from the live system (via the retention schedule above or a deletion request) does not retroactively remove it from backups already taken before the deletion — it ages out on its own: the affected hours' on-server copies within 3 days, and the corresponding off-site copies once they pass 30 days. Detailed specifications of the backup environment are available for procurement review under NDA at security@skink.dev.

Note on hashed storage

We identify records by a cryptographic hash of the lowercased email address, not a plain hash — a plain hash is efficiently reversible for email addresses given how predictable their format is, so it wouldn't meaningfully protect what you sent us.

Note on hashed-only storage (opt-out of readable storage)

Storing a readable copy of submitted addresses, encrypted at rest, is on by default. A customer may instead switch to hashed-only storage in account settings. Switching is not retroactive in either direction — verifications already made keep the storage form they were made under; only verifications made after you change the setting follow the new one. Switching to hashed-only does not delete or decrypt copies already stored in readable form; those are still purged on your normal retention schedule.

Zero-retention verification (retain:false)

Zero-retention is available for real-time API requests (POST /v1/verify). When a request sets retain:false, skink returns the verification result without retaining recipient-level verification history for that request, and without scheduling recipient-specific asynchronous follow-up for it. Necessary transient processing to complete the request — for example, the in-memory verification check itself — still occurs; zero-retention describes what is (and isn't) persisted afterward, not the absence of any processing.

Zero-retention does not retroactively delete data already retained from earlier requests, and it does not change your account's default retention setting for requests that don't use it. Bulk verification (POST /v1/bulk) currently requires temporary storage to track job progress and does not support zero-retention mode; a request combining retain:false with a bulk job returns a documented error rather than silently ignoring the flag.

Billing, security, fraud-prevention, and records required by law follow the separate retention requirements described elsewhere on this page and are designed, where possible, to avoid retaining recipient-identifying information they don't need.

Per-verification deletion

Customers can delete an individual verification record from the product (dashboard or API). Deletion removes the recipient-level data associated with that specific verification from our active systems, and cascades to labels created against that specific verification. It does not:

  • delete any other verification record for the same or a different recipient address;
  • delete shared bulk-upload artifacts (the uploaded file or other rows from the same bulk job);
  • delete unrelated shared accuracy-learning evidence, which is linked at the domain level, not to a specific verification;
  • delete account, billing, or security records required to be kept by law; or
  • reach into backups already taken before the deletion (see Backups, below).

Deleting a verification is not a way to request that a recipient's email address be removed from every system it may otherwise appear in — it acts on that one verification record only.

Contact

Questions about this page: privacy@skink.dev.