Privacy Policy

Effective date: 2026-08-01 Last updated: 2026-09-02

This Privacy Policy explains how skink ("skink," "we," "us," or "our") collects, uses, discloses, and safeguards information in connection with our email verification API and dashboard (collectively, the "Service"). skink is operated by Kexa Labs (Udyam Reg. No. UDYAM-GJ-22-0652675), a proprietary firm registered under India's MSME Udyam scheme ("Kexa Labs," "we," "us," "our"). Contact us at privacy@skink.dev for any privacy inquiry.

1. Scope and Roles

This Policy covers two categories of data, treated differently:

Account data — information about you or your organization as our direct customer (name, email, billing details, API usage). For this data, skink is the data controller (GDPR) / data fiduciary (DPDP) / business (CCPA).
Submitted address data — the email addresses you submit to our API for verification, which typically belong to your own contacts, leads, or customers. For this data, you (our customer) are the controller / data fiduciary / business, and skink acts solely as a data processor (GDPR) / data processor (DPDP) / service provider (CCPA) on your documented instructions. The terms governing this processor relationship are set out in our Data Processing Agreement ("DPA"), incorporated by reference.

2. Information We Collect

Account data (role: Controller) — name, email address, billing/payment metadata, API key metadata.
Submitted address data (role: Processor) — email addresses sent to /v1/verify and /v1/bulk.
Verification results (role: Processor) — deliverability status, confidence score, signals.
Technical/usage data (role: Controller) — IP address (for rate limiting and abuse prevention), request logs, timestamps.

We do not request or require any information beyond what is necessary to operate the Service — we do not, for example, ask for a phone number, physical address, or government ID to create an account or verify an email address.

We do not collect the following:

No IP-based analytics tracking. Your IP address is used only for rate limiting and abuse prevention (e.g., signup/demo/day limits) — never to profile, track, or target you across sessions or to build an advertising or audience profile.
No browsing history. We operate no third-party marketing, analytics, or tracking scripts on the Service, and do not track the pages you visit or how you navigate it. The one exception is our sign-in page, which automatically loads Google's own Identity Services script (to render the optional "Sign in with Google" button, shown alongside the email sign-in option) — see our Cookie Notice for exactly what that script does.
No device fingerprinting. We collect no canvas, WebGL, user-agent-based fingerprint, or other device-attribute fingerprint data.
No payment card numbers. Card payments are processed entirely through our hosted checkout provider (Dodo Payments); full card numbers never pass through or are stored by our systems, and we keep only the billing metadata needed to reconcile a payment (e.g., billing country).

3. How We Process Submitted Email Addresses

Encrypted readable storage by default. Submitted addresses are persisted in readable form, encrypted at rest (AES-256-GCM), so the Controller can review its own verification history and exports. The plaintext address also exists transiently in memory during the live verification check and in a short-lived deduplication cache (bounded TTL, not indefinite).
Hashed-only storage available from day one. A Controller may instead elect, in its own account settings, to store only a cryptographic hash of each submitted address (unreversible via dictionary or rainbow-table lookup against common email patterns). This is a Controller-configured processing instruction under Section 4.
No enrichment. We do not append names, job titles, social profiles, or any other identity data to what you submit. The API returns a deliverability verdict — nothing more.
No resale, no marketing use. We do not sell submitted addresses, use them for marketing, or disclose them to any third party except the sub-processors listed in Section 8, strictly to perform the verification itself (e.g., a live SMTP handshake with the recipient's own mail server, which is inherent to how email verification works).
Retention. Verification records are automatically deleted on a schedule the Controller sets in its account settings, from 1 to 365 days (365 days by default). See our Data Retention schedule for the full breakdown by data type.
Zero-retention verification. Real-time API requests may set retain:false to receive the verification result without recipient-level history being retained for that request, and without recipient-specific asynchronous follow-up being scheduled. Necessary transient processing to complete the request still occurs. This does not retroactively delete data already retained from earlier requests, and bulk verification does not currently support it. See our Data Retention page for the full description.
Per-verification deletion. A Controller can delete an individual verification record directly from the product. This removes the recipient-level data tied to that specific verification and cascades to labels created against it; it does not delete other verification records, shared bulk-upload artifacts, unrelated shared accuracy-learning evidence, or account/billing/security records required by law. See our Data Retention page for the exact boundaries.

3a. Shared Accuracy Learning (optional)

Shared accuracy learning is currently disabled. skink does not use customer verification data for shared accuracy learning while this feature is unavailable. When available, it is a separate, optional feature: if a Controller enables it in account settings, eligible verification and delivery-outcome signals from that Controller's own account may be used to evaluate and improve skink's verification accuracy across the Service.

Enabling this setting is the Controller's own authorization to participate in the feature. It is not, and does not constitute, consent obtained from the underlying email recipients, and Controllers should not describe it to their own data subjects as such.

The evidence this feature generates is linked to a domain-level token derived from the recipient's email domain, not directly to the submitted recipient address — but because it is tied to a specific customer account, specific integration, and a narrow time window, it remains pseudonymous and potentially re-linkable in context, not anonymous, and we do not describe it as anonymous.

Disabling the setting stops new contributions from that account according to skink's current processing design. It does not automatically erase evidence already collected before it was disabled; retention of that evidence is described on our Data Retention page.

Under the CCPA/CPRA, skink does not use data contributed under this feature for any purpose outside the accuracy-improvement purpose disclosed here, and does not combine one customer's contributed evidence with another customer's submitted address data. - Automated processing. The deliverability verdict returned by the Service (status, confidence score, and supporting signals) is generated by an automated process. This output is provided to the Controller for the Controller's own downstream use; skink does not use it to make any decision producing legal or similarly significant effects concerning the Data Subject, and the Controller remains solely responsible for any such decision it makes using the output. skink provides this verdict as information to the Controller; the Controller is responsible for determining how it uses that output, including whether its own downstream use is subject to Art. 22 GDPR or similar automated-decision-making requirements in its jurisdiction. - Indirect collection notice. Where we process an email address submitted to us by our customer rather than obtained directly from the address owner, we do not independently contact that person to provide notice of this processing, in reliance on the exemption for disproportionate effort (GDPR Art. 14(5)(b)) — given the transient, high-volume, non-profiling nature of the processing and our lack of any independent means to contact that person beyond the submitted address itself. If you believe your email address has been submitted to our Service and wish to exercise a data protection right, contact privacy@skink.dev with the address in question, and we will route your request to the submitting customer or respond directly where required by law.

Account data — Operate the account, provide the Service, and handle billing. Legal basis: contract performance (Art. 6(1)(b)) — we need it to provide the Service you signed up for.
Submitted address data — Deliverability verification, performed strictly on the controller's documented instructions (the DPA). As the Controller for this data, our customer determines its own lawful basis for submitting each address (which may be legitimate interest under Art. 6(1)(f), consent, contract, or another basis depending on the customer's own relationship with the data subject) — skink does not determine or substitute its own basis for the controller's processing.
Verification results — Return the deliverability verdict to the controller. Legal basis: derived from, and processed under the same basis as, the submitted address data.

Customers warrant that they hold an independent lawful basis for every address they submit — see our Acceptable Use Policy.

skink does not currently meet the threshold for mandatory appointment of a Data Protection Officer under Art. 37 GDPR (core activities do not involve large-scale processing of special-category data or data relating to criminal convictions), and none is therefore appointed.

See our GDPR page for a plain-language summary of how we meet these obligations.

5. India — Digital Personal Data Protection Act, 2023 (DPDP)

India's Digital Personal Data Protection framework is being brought into force in phases under notifications issued by the Ministry of Electronics and Information Technology (MeitY), rather than all at once. Not every obligation described in the Act is yet a current legal requirement. Where we say below that we provide a right or control, that reflects skink's own practice — voluntarily, or ahead of the applicable commencement date — not necessarily a statutory obligation already in force. We will update this section as further provisions commence.

For submitted address data, our customer is the Data Fiduciary; skink acts as Data Processor strictly on the Data Fiduciary's instructions, per the DPA.
skink does not currently meet the volume threshold that would make it a Significant Data Fiduciary under the Act.
Grievance contact: privacy@skink.dev handles Data Principal grievances concerning submitted address data, routing them without undue delay to the responsible Data Fiduciary (our customer) where skink acts as a processor. We do not cite a fixed statutory response deadline here, since the Act leaves detailed grievance-redressal timelines to be prescribed; we aim to acknowledge promptly and respond without undue delay.
Data Principal rights — access, correction, erasure, grievance redressal, and nomination — are honored, to the extent applicable and where skink is not acting purely as a processor bound by a customer's instructions, through the request process in Section 7 below.
Cross-border transfer follows DPDP's restricted-country model as and when that provision takes effect (transfers permitted except to jurisdictions the Central Government notifies as restricted); we review the notified list before enabling any new processing location.

Primary sources: Ministry of Electronics and Information Technology, Gazette of India notifications dated 13 November 2025 on phased commencement of the DPDP Act, 2023 (certain provisions effective immediately; specified provisions effective 12 months later; the remaining substantive obligations, including most of Sections 3–17, effective 18 months later) and of the DPDP Rules, 2025 (Rules 1, 2, and 17–21 effective on publication; Rule 4 twelve months later; Rules 3, 5–16, 22, and 23 eighteen months later).*

6. United States — CCPA/CPRA and State Privacy Laws

The CCPA/CPRA's obligations apply only to a "business" meeting Cal. Civ. Code §1798.140(d)'s thresholds (annual gross revenue over $25 million, or processing the personal information of 100,000+ California consumers/households annually, or deriving 50%+ of annual revenue from selling/sharing personal information). skink does not currently meet any of these thresholds for account data. This section describes our practices and states our commitment to CCPA-consistent handling regardless, and will apply as a matter of law if and when any threshold is met.
For submitted address data, skink acts as a Service Provider under Cal. Civ. Code §1798.140(ag), not a "business" with a direct relationship to the underlying email owner — our customer is the business.
skink does not sell or share personal information as defined by the CCPA, and does not retain, use, or disclose submitted address data for any purpose outside performing the verification service specified by the customer, including not combining it with data from other sources, per §1798.140(ag)(1)–(4). No "Do Not Sell or Share My Personal Information" mechanism is required, as no such sale or sharing occurs.
The same underlying practice satisfies the comparable service-provider/processor carve-outs in other state laws (e.g., Virginia VCDPA, Colorado CPA, Connecticut CTDPA).

7. Your Rights and How to Exercise Them

Depending on your jurisdiction, you may have the right to access, correct, delete, restrict, or port your personal data, and to object to certain processing. To exercise any of these rights, contact privacy@skink.dev. We identify records by the submitted address or its hash (for accounts using hashed-only storage) — please include the specific address(es) at issue in your request. We respond to access and portability requests with the data we actually hold for the address(es) — derived signals and, unless the account elected hashed-only storage, the submitted address itself; addresses stored only as a cryptographic hash cannot be returned in plaintext. Under GDPR/UK GDPR, we respond without undue delay and ordinarily within one month of receipt, subject to the extensions Art. 12(3) permits for complex or numerous requests; under the CCPA, within 45 days, extendable once by a further 45 days where reasonably necessary.

UK — right to complain to us first. Since this requirement came into force in June 2026 under the Data (Use and Access) Act 2025, UK-based individuals have a statutory right to raise a data protection complaint with us before or alongside the ICO. We provide this route at privacy@skink.dev; we acknowledge receipt within 30 days, investigate appropriately, keep you informed of progress, and provide the outcome without undue delay. You may complain to the ICO (ico.org.uk) or your local EU/EEA supervisory authority at any time regardless of whether you've complained to us first. Primary source: Information Commissioner's Office, "New data protection complaints law now in force," June 2026.

8. Sub-processors

We use the following categories of sub-processor to operate the Service. A current, named list is available on request at privacy@skink.dev and is kept in step with our infrastructure as it changes:

Hosting/infrastructure — the server(s) running the API and database.
Object storage — for bulk verification file uploads/downloads (customer-accessed when a bulk job references an uploaded file) and for off-site database backups, encrypted at rest (backups are disaster-recovery only, never customer-accessible).
Payment processing — for billing (Dodo Payments), which never receives raw email address data.
Mailbox-provider endpoints queried during verification and enrichment/breach-presence signal services — contacted only to determine mailbox existence or breach presence for the address being verified, not stored by them on our behalf. A current, named list of partners is available on request at privacy@skink.dev.
Transactional email delivery — for sending account-related emails (sign-in links, account confirmation, and operational notifications) to the addresses stored on customer accounts; these providers never receive submitted verification addresses.

9. International Data Transfers

skink and its sub-processors may process data in the United States, Germany, India, and other locations listed in our current Subprocessor Register. Personal data originating in the EEA, UK, or Switzerland that reaches infrastructure outside those regions is transferred outside the EEA/UK under GDPR/UK GDPR Chapter V, and we rely on Standard Contractual Clauses (2021 EU SCCs, Module Two: Controller to Processor) or the UK International Data Transfer Addendum, together with a transfer risk assessment covering each destination. Personal data that stays within the EEA requires no additional transfer safeguard for EEA-origin data; the UK's and Switzerland's own adequacy findings for the EEA mean no additional safeguard applies to UK- or Swiss-origin data staying within the EEA either. Separately, because skink is operated from India, remote access to and administration of this infrastructure from India is itself an additional transfer to a third country — applicable regardless of which region the data resides in — also covered by the same SCCs. India-origin data is governed by DPDP's restricted-country transfer model (permitted unless the destination is on the Central Government's notified restricted list — none of our current processing locations are, as of this writing). We will update this disclosure if our processing locations or operating jurisdiction change; see our Subprocessor Register for the current, authoritative list.

10. Security

See our Security page for the technical and organizational measures we apply, including hashing, encryption in transit and at rest, least-privilege access controls, and key rotation.

Where skink acts as a processor, we notify the controller of a personal data breach affecting the controller's data without undue delay and no later than 72 hours after becoming aware (see DPA, Section 8). Where skink acts as a controller (account data), we notify affected individuals and supervisory authorities as required by applicable law.

CERT-In (India Cyber Security Directions, 2022)

skink is operated from India, so for incidents reportable under the Indian Computer Emergency Response Team (CERT-In) Directions, 2022, we additionally notify CERT-In within 6 hours of becoming aware of or being notified of the incident. Operational logs are retained on a rolling basis, including a 180-day security-log window, and server clocks are synchronized to a reliable time source to keep log timestamps accurate.

11. Data Retention

See our Data Retention schedule for the exact retention period per data type and our deletion-on-request process.

12. Children's Privacy

The Service is intended for business use and is not directed at, and we do not knowingly collect personal data from, individuals under the age of 18 (or the age of majority in their jurisdiction) in their capacity as our direct customers. The Service currently performs no age verification or age gating; this section reflects our design intent and the account holder's representation of age, not a technical age-verification mechanism.

13. Changes to This Policy

We will update this Policy as our practices or applicable law changes, and will update the "Last updated" date above. Material changes affecting existing customers will be communicated by email or in-product notice before taking effect.

14. Contact

Privacy inquiries, Data Principal/Data Subject requests, and Grievance Officer (India DPDP §13) correspondence: privacy@skink.dev.