Privacy policy
last updated · September 10, 2026
Spaw is a verification API: you send us email addresses, domains, and similar identifiers, and we answer questions about them. That only works if you can trust what happens to the data you submit, so this policy is short and specific.
What we collect
Your account details (name, email address, password hash), the API keys you create (secret keys are stored hashed), and the data you submit for verification: email addresses, domains, phone numbers, IP addresses, postal addresses, or business identifiers. We also keep standard operational records — credit ledger entries, request timestamps, and the channel a request came from — so your usage page can show you exactly what happened, a request log so you can look up what became of a call by the request id its response carried, the delivery outcomes you report back to us, and anything you write to us through the support form — the message itself, the address you asked us to reply to, and, when you are signed in, which account and plan it came from. If you have paid us there is also the customer reference our payment processor knows you by and the brand and last four digits of the card on file; the card number itself is typed into the processor’s own checkout and never reaches us.
How submitted data is used
Addresses and domains you submit are used for one purpose: answering your query. Verification runs DNS and mailbox-level checks against the relevant mail infrastructure; no message is ever sent to an address you check. We never sell submitted data, and the only thing we pool across accounts is described under outcome reports below, and never contact the addresses you verify.
Retention
One row per thing we keep, because a paragraph is where a promise goes to hide. Every window here is the window the code keeps rather than a target: a prune runs nightly and deletes what is past it, except where the third column names a different trigger, and every figure in the table is pinned by a test to the configuration and the constants that do the deleting, so moving one of those numbers in the code fails the build until this table moves with it. The rows with no number are the ones to read twice — a suppression entry is held until you say otherwise, because it exists to be read back and matched against a later lookup; your account, the keys on it and its credit ledger last as long as the account does; and one salted hash deliberately outlives the account that made it.
| What is kept | How long | What ends it |
|---|---|---|
| Your account itself: your name, the email address you sign in with, a hash of your password, and who else is a member of it with the role each of them has. | The life of the account | Deleting your account from the settings page, which takes the keys, the history, the jobs, the monitors, the suppression list and the signed-in devices with it. Closing a login that other people are members of is refused instead of taking their balance, keys and history with it. |
| An API key you created: its name, the scopes and any daily cap on it, the addresses or origins it may be used from, which member created it and when it was last used. A secret key is stored as a hash and cannot be read back; a publishable key is stored as it is, because it is written to be put in your own page source, and the bot-protection secret it can carry is stored encrypted. | Until you revoke it | Revoking it, or deleting your account. A rotated key keeps its row past the end of its grace window so the key list can still say what became of it. |
| An email lookup you ran: the address, the verdict, the reasons behind it and the request id it answered under. This is your own verification history, and the CSV export is these rows. | 30 days | The nightly prune, deleting your account, or an erasure confirmed from that address. |
| A bulk run: the list you uploaded, the result file written from it, and the row tracking the job. The same for all five bulk products. | 30 days | The nightly prune deletes the row and the run’s whole directory with it. Deleting your account deletes the files explicitly, because a database cascade fires none of our own cleanup and the files, not the rows, are the personal data. |
| A bulk draft: the rows parsed out of a file you were still mapping, before anything was queued or billed. | 24 hours | Starting the run (the draft becomes the job), discarding it, or the sweep. Every read path also refuses an expired draft whether or not the pruner has reached it, so the published number is not a rounding-up of when the scheduler last ran. |
| A monitored list: the email addresses, phone numbers, IP addresses, postal addresses or company numbers you saved to it, and the last run’s answer for each. | 365 days | Deleting the monitor, which takes the saved entries and the stored answers with it. Otherwise 365 days after its last run — a list still being run is never pruned, because every run moves the clock. |
| A delivery outcome you reported for an email address: the address as written, what happened to the message, and when. | 180 days | The nightly prune, deleting your account, or an erasure confirmed from that address. |
| A delivery or abuse outcome you reported for a phone number: the number, the outcome and when it happened. | 180 days | The nightly prune, or deleting your account. For a number, write to us and a person checks first. |
| A delivery outcome you reported for a postal address: the address as you wrote it rather than a hash, because it exists to be matched against a later lookup. | 180 days | The nightly prune, or deleting your account. For a postal address, write to us and a person checks first. |
| An outcome you reported for an IP address: a salted hash of the address, the outcome and a timestamp. Never the address itself, so nothing here can be read back into a list of addresses. | 90 days | The nightly prune, or deleting your account. For an IP address, write to us and a person checks first: the hash is what the erasure matches on, and it is recomputed from the address you give. |
| A suppression entry: the email address, phone number or postal address you suppressed, with the verdict that earned it. | Until you remove it | You remove it, your account is deleted, or an erasure — confirmed from that address when it is an email, checked by a person when it is a phone number or a postal address. An entry you imported yourself is your own do-not-mail list, and an erasure deliberately leaves those alone: deleting one would put that address back in front of the next campaign. An entry older than 90 days is re-verified rather than trusted, which can retire it on its own. |
| A support request: the message, the address you asked us to reply to, and which account and plan it came from when you were signed in. | 180 days | A sweep that runs whenever the inbox is touched — you file one, an operator opens it, or the daily schedule — after which it is deleted whether or not anyone has read it. |
| An erasure request waiting to be confirmed from the form this page links to at the top: the email address typed into it, the reference it was given, and when it was asked for. It is held in the cache rather than the database, and the form that writes it is open to anyone, signed in or not, which is the point of it. | 60 minutes | Confirming the request, which reads the record and consumes it, or the link expiring — and nothing is erased until the link is opened. A second marker remembers for 15 minutes that a link has gone to that address, so asking twice does not send two mails; it holds a hash of the address and nothing else. What outlives both is the record of the erasure itself, which carries a salted digest instead of the address. |
| A request log row: the request id printed in the response header, the endpoint, the status, the typed error code, the credits and how long it took. Never the value the call was about. | 30 days | The nightly prune, or deleting your account. |
| A request timing row, which is what lets the status page publish measured latency instead of a promise: the endpoint group, the milliseconds and the status code. No account, no key, no identifier. | 7 days | The nightly prune. Nothing in the row points at you, so there is nothing here to erase on request. |
| A signed-in device: the session identifier, the IP address the request came from, the browser and operating system its user agent names, and when it was last active. | 120 minutes | Signing out, signing out other devices, changing your password, completing a password reset, or that long without activity. Deleting your account ends every one of them first. |
| An account event: who created, rotated or revoked an API key, and who invited, joined or removed a member. The key’s name or the invited address, never a secret and never a looked-up value. | 365 days | The nightly prune, or deleting the account. It exists because revoking a key destroys the key row, and a shared account still needs to know who revoked it. |
| A pending invitation to join an account: the address it was sent to, the role offered, and a hash of the link’s token. | 30 days after it expires | Revoking it, or sending a fresh invitation to the same address, deletes the row at once; accepting it marks it accepted and leaves the row for the prune. An invitation expires 7 days after it is sent and is refused from then on, whether or not the row has gone yet. |
| The marker that makes a repeat free: a hash of the input under your account’s own key, and the time it was written. Never the input. | 7 days | It expires by itself. Nothing deletes it early, and no identifier can be read back out of it. |
| A credit ledger entry: a grant, a purchase, a plan deposit or a debit, with its reason and the balance after it. | The life of the account | Deleting your account. Nothing prunes it before then: it is your billing record while the account is open. |
| If you have paid us: the customer reference our payment processor knows you by, and the brand and last four digits of the card on file. Never the card number, which is typed into the processor’s own checkout and never reaches us. | The life of the account | Deleting your account, which cancels any live subscription at the same time. |
| A one-way salted hash of the address that claimed the new-account credit bonus. Not the address, and joined to nothing else we hold. | No end | Nothing, deliberately. It outlives the account so the same mailbox cannot claim the bonus again by closing one and opening another. |
Phone and IP lookups
Phone numbers and IP addresses are answered from datasets held on our own servers (numbering metadata, the regulators’ allocation tables, open feeds) and are not written to any history: no row, no log line with the number or address, only the 7-day repeat marker, which is keyed and never lists the input. The request log is not an exception to this: it records that an endpoint was called and what it answered, and names the endpoint rather than the value. There are two exceptions, both of them lists you asked us to keep. A bulk run holds the input list you uploaded and the result file written from it, and both are deleted with the job after 30 days. A monitored list holds the numbers or addresses you saved to it and the last run’s answer for each, for as long as you keep the monitor — delete the monitor and they go with it, and a monitor nobody has run for 365 days is deleted automatically, saved entries and all. Email lookups differ because your own verification history is a feature you can export. SMS outcome reports you send us stay yours: they shape only your own later lookups, except that abuse reports about the same number from several accounts raise that number’s risk for everyone. The reports themselves are never shared or shown; what is read is one count, the number of distinct accounts that reported abuse within thirty days. Outcome reports reach us three ways: the feedback endpoint, your provider’s bounce webhook, and the report buttons in your own dashboard. All three are yours and all three shape your own later lookups, but a report typed into the dashboard is deliberately left out of every figure other accounts feel — the cross-account abuse count, the per-domain bounce ratio — because a score everybody’s lookups feel should move on what your systems observed and filed, not on a button clicked in our interface. Email outcome reports are kept for 180 days with the address, so your own later lookups can learn from them. They are also counted per DOMAIN across accounts: once a domain has at least five delivered-or-bounced reports, the ratio between them nudges the mailbox confidence everyone sees for that domain. It is a figure about a domain, never about an address, and the reports themselves are never shared or shown. IP outcome reports work the same way and are stored as salted hashes of the address with the outcome and a timestamp, never the address itself, for 90 days; the lookups themselves are still never stored.
Postal address, company and consistency lookups
Postal address lookups are answered from registers held on our own servers and are not written to any history: no row, no log line with the address, only the 7-day repeat marker, which is keyed and never lists the input. The same two exceptions apply as for phone and IP — a bulk run holds the list you uploaded and the result file written from it, both deleted with the job after 30 days, and a monitored list holds what you saved to it until you delete the monitor. Addresses have a third: your suppression list and the delivery outcomes you report both store the address as you wrote it rather than a hash, because both exist to be read back and matched against a later lookup. Outcomes are kept for 180 days; suppression entries persist until you remove them. Company lookups read an identifier against the registers held here and write nothing at all — no history row, no log line — and the answer never carries a street address, deliberately: a registered address is very often a home address. Cross-signal consistency stores nothing of its own. It runs the signals you send it, so it writes whatever each of those signals would have written on its own and no more; the comparison itself — which fields agreed and which did not — is returned to you and never kept.
Subprocessors
The full list is published by role and region on the trust page, with what each one actually receives: application hosting and the database, content delivery and bot protection, transactional email, payments, the mailbox verification partner that sees only an address which reached the mailbox step, the public registry lookup an opt-in abuse_contact request makes, and consent-gated analytics on the marketing site. The names of the legal entities behind those roles are not published on a public page, but they go to any customer or prospective customer who asks at [email protected], and a new subprocessor is published before it starts processing. Three things are deliberately absent from that list: there is no third-party file storage, because bulk inputs and results are written to our own server’s disk; there is no processor behind a phone, address, IP or business answer, because those datasets are downloaded and queried here; and the two licensed partners a live carrier check and a postal deliverability check would need are not configured, so neither exists today. We do not share your account data with advertisers or data brokers.
Signed-in devices
While you are signed in we store one row per browser session: an identifier, the IP address the request came from, the browser and operating system your browser names in its user agent string, and when it was last active. Your security settings page shows you that list, which is the point of keeping it — it is how you notice a device you do not recognise, and how you sign it out. Nothing in it is shared, sold, or used to profile you, and it is never joined to the addresses you verify. A row is deleted when that session ends: when you sign out, when you sign out other devices, when you change your password or complete a password reset, and when the session simply expires. Deleting your account deletes every one of them with it.
Cookies
The site uses cookies for signing you in (session and CSRF protection) and for remembering interface preferences like the color theme. Those are necessary for the site to work and are not optional. Analytics is: Google Analytics is not loaded at all until you agree to it, so nothing about your visit reaches Google before you answer the bar at the bottom of the page. If you agree, it sets first-party _ga cookies so we can see which pages are visited and how people find the site; the reports are aggregate, are never used for advertising, and never include the addresses you verify. Your answer is remembered in your own browser and you can change it below. There are no advertising or cross-site tracking cookies.
Your rights
You can export your verification history and suppression list as CSV from the dashboard at any time, and deleting your account from the settings page removes your account data, keys, history, jobs, monitors, suppression list, and the record of the devices you were signed in on. A support request you sent is not among them: it is a message to a person, filed against the address you asked us to reply to rather than against the account, and it ages out on its own 180-day window. One thing outlives it, deliberately: a one-way hash of the address that claimed the new-account credit bonus, kept so the same mailbox cannot claim it again by closing the account and opening another. It is a salted hash and not the address — it cannot be read back, and it is not linked to anything else we hold. For access, correction, restriction or objection, email [email protected]: we answer within 30 days, which is the outer limit the GDPR allows rather than a target, and normally much sooner.
If you never signed up here
A customer may have sent us your email address to be checked, or reported that a message to it bounced, which means we can hold something about you that you never gave us — and for a phone number or an IP address, abuse reports from three or more separate accounts inside thirty days raise that value’s risk score for everybody, which is our own processing rather than any one customer’s. So there is a self-serve route out that does not go through the customer: the form at /privacy/data-request takes an email address, mails a confirmation link to it — which means the address sits in our cache for the 60 minutes that link is live, and nothing is erased until you open it — and on confirmation deletes every row we hold under that address — the lookup history entries, the delivery outcomes, any suppression list it sits on — immediately, showing you the count per table. Nobody is told that you asked. The form takes an email address and nothing else because receiving mail at an address is the only thing a stranger can prove over the web, and it proves control of exactly one identifier: a form that also took a phone number would let anybody erase anybody else’s. For a phone number, a postal address or an IP address, write to [email protected] and a person checks first. Two things an erasure leaves alone, and we would rather name them than let you assume otherwise: a customer’s own monitored list and the file they uploaded for a bulk run are their records, deleted on their own schedule (a bulk job and its files after 30 days, a monitor 365 days after its last run) or when they delete them; and the 7-day repeat marker, which is a hash and a timestamp under an account’s own key and expires by itself.
Contact
Questions about this policy: [email protected].
Your analytics choice
Analytics is not switched on for this deployment, so there is nothing to choose.