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, the channel a request came from, and the IP addresses your account has signed in or called the API 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 never contact the addresses you verify. Two things about an email address are read across accounts, both as counts and dates and never as the address: widely_seen says whether three or more other accounts looked the address up in the last day, kept for that day as a keyed hash of the address with the account ids that saw it and when; and a mail server’s "no such mailbox" answer is remembered for a year under a keyed hash so a mailbox that later exists again can be reported as previously invalid. Neither says who asked, both are erased with the address, and the only other pooled reading is described under outcome reports below.
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, unless a later answer or report of yours clears one a lookup or a failure added, 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. |
| An SMS outcome you reported for a phone number — delivered, undelivered, verified, abused or opted out: 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. |
| One row per lookup we answer for nobody — a free tool or try-it widget on the public pages, or the sign-up form checking the address you entered: which of the two it was, what kind of lookup, when, how long it took, what the answer’s status was, a salted hash of the value you typed, of the address you came from and of your browser session, and, if you were signed in, your account. Never the value or the address itself, so nothing here can be read back into a list of who looked up what. Alongside them, what our own IP intelligence says about the connection — the country, the network operator, and whether it is a datacenter, Tor or a VPN — because a lookup that anyone can run for free has to be watchable for abuse. | 90 days | The nightly prune. A guest’s row is joined to no account; a signed-in visitor’s row carries their account until then, and the table cannot be read back into a list of who looked up what — but a hash is still recomputable from the value that made it, so it is not anonymous and we will not pretend otherwise. To have rows removed before the prune, write to [email protected] and a person checks first: the hash is what the erasure matches on, and it is recomputed from what you give us. |
| 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 so is a phone number whose recipient opted out of your messages or an email address whose recipient marked your mail as spam; an erasure deliberately leaves all three alone, because deleting one would put that address or number back in front of the next campaign. An entry a lookup or your reports of failed deliveries added also leaves when a later answer or report clears it; an import leaves only when you remove it. An entry a lookup or your reports of failed deliveries added that is older than 90 days is re-verified rather than trusted, and one a lookup added leaves when the fresh answer no longer earns it. An import never goes stale, because it is your own decision rather than a measurement, and neither does an opt-out, a spam complaint or an abuse report you made, which records what a person did: no later lookup or report clears it, even when you made it about an entry you imported (an erasure of the number, checked by a person, still deletes an abuse entry that is not an import). |
| 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 IP address your account has been seen from: the address itself, which door it came through (the website, the API, or — for our own staff — the admin panel), when it was first seen, when it was last seen and how many requests came from it, not counting the ones your browser made on its own to guess where you might go next. It is a security record — it is how we answer "is this the same person" when somebody writes in — and it is never joined to the addresses you verify, never shown to another customer, and never used to profile you. | 180 days | The nightly prune, counted from when the address was last seen, so an address you use every day is kept and one you used once is not. Deleting your account takes every one of them with it. |
| 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, plus a second one for a phone number whose live carrier check you paid for. Never the input. | 7 days | It expires by itself. Nothing deletes it early, and no identifier can be read back out of it. |
| For your single and browser phone lookups: the numbers looked up in each 1,000-number range and, when you send the address of the person behind a lookup (or a visitor uses your browser key), the numbers tried from that address. Each number is a truncated keyed hash under your account’s own key, with when it was seen; the range and the address are keyed hashes too. Never a number, a range or an address, and never read for another account. | 60 minutes | It expires by itself 60 minutes after the last lookup it counted, and a hash older than that is dropped whenever it is next read. An erasure of a phone number takes the number out of every account’s range counts; a count kept per address is filed under the address, so it cannot be found from the number, and simply expires. |
| For your single and browser phone lookups: how many went to each country in each hour, and how many of those were invalid. Counts only, never a number, which is what the new-destination field, the destination alerts and your usage page read. | 30 days | The nightly prune, or deleting your account. Being counts, they hold nothing an erasure could match. |
| The complaints the US Federal Trade Commission publishes about unwanted calls, for North American numbers: the number the complaint names as the caller, the day it was filed, whether it was a recorded message and the subject the consumer picked, plus a count per number. Nothing you sent us and nothing about the consumer who complained: we download the FTC’s public files each weekday. Three complaints on two different days raise that number’s risk score for every account, and caller ID is easily spoofed, so a complaint can name a number whose owner made no call. | 90 days | The nightly sync and prune, counted from the day each complaint was filed. An erasure of the number, checked by a person, deletes its complaints and its count; a complaint the FTC publishes afterwards is counted like any other. |
| A phone number a public SMS-receiving website publishes, where anybody can read the texts sent to it, and the day one of the open lists of those sites last showed it. Nothing you sent us: we download the lists daily. A number the lists still carry is scored as disposable for 365 days after it was last seen, one they have all dropped for 90 days after it was last seen, and either as a weaker stale listing after that. | 730 days | Dropped 730 days after a list last showed it; a number the lists still carry is kept while they do. An erasure of the number, checked by a person, deletes a listing the sites no longer publish; one they still publish comes back at the next daily sync. |
| 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. What a lookup leaves behind is keyed and never lists the input: the 7-day repeat marker; for an IP address, the count behind seen_by_you, filed the same way under a hash; for a phone number, the readings of your own traffic described below; and, when a phone lookup asks for the live carrier check, the network’s answer, held for a day under a keyed hash of the number so a repeat does not ask again. 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. Phone lookups keep two short-lived readings of your own traffic, and neither holds a number: for your single and browser lookups, a truncated keyed hash of each number, grouped under a keyed hash of its 1,000-number range and of the client address you send us (your visitor’s, on a browser key), for the short velocity window; and how many lookups went to each country in each hour, and how many were invalid, as counts. Both belong to your account alone, are never read for another, and are in the retention table above. 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; a suppression entry you imported persists until you remove it, and one your reports added also leaves once a delivery is reported or the reports behind it age out. 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. Separately from that list, and outliving it, we keep one row per IP address your account has been seen from — the address, which door it came through, when it was first and last seen, and how many requests came from it. That one is not shown to you; it is read by our own staff when somebody writes in about their account, because “is this the same person” is a question we would otherwise have no honest way to answer. It is in the retention table above with its window, it is never joined to the addresses you verify, and it goes when your account does.
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 cookie notice. 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, where the cookie preferences dialog can be opened as well. 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. Two public datasets about phone numbers are our own processing too, and they are in the retention table above: the complaints the US Federal Trade Commission publishes about unwanted calls, which raise a North American number’s risk score for everybody once three of them on two different days name it as the caller — although caller ID is easily spoofed, so a complaint can name a number whose owner made no call — and the numbers public SMS-receiving websites publish, which we keep after the sites drop them so a recently used one still reads as disposable. An erasure of a number deletes its complaints and a listing the sites no longer publish. For an email address the pooled readings are the two named above — how many accounts checked it inside a day, and whether a mail server once said it did not exist — kept as counts and dates under a keyed hash, and the erasure below removes both. 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 the rows we hold under that address — the lookup history entries, the delivery outcomes, the suppression entries a lookup or a bounce put it 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. Five things an erasure of an email address 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; the 7-day repeat marker, which is a hash and a timestamp under an account’s own key and expires by itself; a one-way hash of the address that claimed the new-account credit bonus, if it did, which exists so the bonus cannot be claimed twice and cannot be read back; an entry a customer imported into its own suppression list, which is that customer’s own do-not-mail list and only that customer can remove; and an account’s record that the address complained about its mail, a do-not-contact entry that exists to keep the address out of that account’s next campaign, which only that account can remove. For a phone number the erasure leaves the first two and a customer’s imported entry alone too, and four more: its keyed hash in an account’s count of the numbers one visitor’s address tried, which is filed under that address rather than the number, so it cannot be found from the number, and it expires with its short window; an account’s record that the number opted out of its messages, a do-not-contact entry that exists to keep the number out, which only that account can remove; a listing on a public SMS-receiving website’s list while the site still publishes the number, because it is listed again at the next daily sync; and a complaint the FTC publishes after the erasure, which is counted like any other, because its files are public. A postal address keeps the first two and a customer’s imported entry, and an IP address keeps the first two.
Contact
Questions about this policy: [email protected].
Your analytics choice
Analytics is not switched on for this deployment, so there is nothing to choose.