An email address identifies a person, so under the General Data Protection Regulation it is personal data whatever else is known about its owner, and a verification is processing of it. This guide sets out what that processing consists of when the address goes through Spaw: what is stored, for how long, what is derived from it and read across accounts, who else sees it, and how it is erased. Every figure here is the one the code keeps, and the privacy policy publishes the same table with the tests that pin it.
Who is the controller of the addresses you verify
You are. You collected the address, you decide why it is being verified, and Spaw processes it on your behalf to answer your query. That makes you the controller and Spaw the processor for the verification itself, in the terms of Article 4 of the regulation, and the written terms Article 28 requires between the two are the standing data processing addendum on the trust page, which applies to every account without a signature.
Two things Spaw does with an address are its own processing rather than yours, and the privacy policy says so: the pooled readings described below, which are counts derived from many customers' lookups and reported to all of them. For those Spaw is the controller, on the legitimate-interest basis of keeping the verdicts accurate, and they are designed so that nothing about an identifiable person leaves them.
What a verification stores
A single email lookup writes one history row for your account: the address, the verdict, the reasons and score behind it, the signals that fired, and the request id the answer was returned under. It is your own verification history, the CSV export is these rows, and it is deleted after 30 days by a nightly prune, or earlier when you delete your account or the address is erased on request.
Beside the row, a lookup leaves a repeat marker: a hash of the input under your account's own key, with the time it was written, so a repeat inside seven days is free. It is never the input, and it cannot be turned back into the address.
Everything else is something you asked Spaw to keep, and each has its own window.
| What | Window | What ends it |
|---|---|---|
| A bulk run: the list you uploaded and the result file written from it | 30 days | The nightly prune, which deletes the run's whole directory; deleting your account deletes the files explicitly |
| A bulk draft, parsed and not yet started | 24 hours | Starting it, discarding it, or the sweep |
| A monitored list: the addresses you saved and the last run's answer for each | 365 days after its last run | Deleting the monitor; a list still being run is never pruned |
| A delivery outcome you reported: the address as written, what happened, when | 180 days | The nightly prune, deleting your account, or an erasure confirmed from that address |
| A suppression entry: the address and the verdict that earned it | Until you remove it | You, deleting your account, or an erasure. One a verdict or a reported bounce added also leaves when a later verdict or a reported delivery clears it; an import or a spam complaint leaves only when you remove it, and an erasure keeps both. An entry a verdict or a reported bounce added is re-verified rather than trusted once it is older than 90 days; an import or a complaint never goes stale |
| The request log: which endpoint was called and what it answered, never the value looked up | 30 days | The nightly prune |
Nothing is ever sent to an address you verify. The mailbox handshake is an SMTP conversation that ends before any message data is transmitted, and the partner that performs it sees only an address that reached the mailbox step.
What is read across accounts
Four readings cross accounts, and each is a count or a date under a keyed hash, never the address and never who.
How many other accounts looked an address up inside a day. The widely_seen field says whether three or more did. It is kept for that day as a keyed hash of the address with the account ids that saw it and when, then discarded.
Whether a mail server once said the mailbox did not exist. A definitive "no such mailbox" answer is remembered for a year under a keyed hash, so a mailbox that exists again is reported as previously_invalid. A bounce you report with that reason feeds the same memory.
Two figures per domain, never per address. The share of reported sends to a domain that bounced, counted only once the domain has five or more outcomes, and the naming convention the domain's confirmed deliveries follow, tallied as pattern shapes such as first.last. Both feed the confidence estimate for catch-all mailboxes, and both are read as counts.
Recital 26 of the regulation is the relevant line: pseudonymised data that can still be attributed to a person by using additional information remains personal data, while data rendered anonymous is out of scope. Spaw treats the keyed hashes as the former, which is why they are erased with the address rather than kept as if they were nothing.
Who else sees the address
The trust page publishes the subprocessors by role and region: application hosting and the database, content delivery and bot protection, transactional email, payments, the mailbox verification partner, and the public registry lookup that an opt-in request makes. For a verification the partner sees the address that reached the mailbox step and nothing else about you or your customer. Domain-level checks such as SPF, DMARC, DKIM, MTA-STS and the registration record are DNS and registry reads and carry no address at all.
Spaw never sells submitted data and never contacts the addresses you verify.
How an address is erased
Article 17 gives the person the right to erasure, and a verification service has to be able to honour it for an address the person never gave it. Two routes exist.
The self-serve route is the form at /privacy/data-request. It takes an email address only, mails a confirmation link to it, and erases nothing until the link is opened, so a mail gateway that prefetches links cannot trigger a deletion and nobody can erase an address they do not control. The pending request lives in the cache for the 60 minutes the link is valid, a second marker remembers for 15 minutes that a link has gone to that address so asking twice does not send two mails, and the record kept afterwards carries a salted digest of what was erased rather than the address itself.
The other route is support. An operator can run the same erasure for an address, and it is the only route for a phone number or a postal address, where a person checks first.
What the erasure removes, for an email address: the history rows, the reported outcomes and the suppression entries a verdict or a reported bounce added, across every account that held them, matched on the address as typed and on its normalised form, plus the derived memories, the shared handshake answer, the sightings hash, the not-found date and the domain-level counts the address contributed to. What it deliberately leaves alone: an entry a customer imported into their own suppression list, and a customer's record that the address complained about its mail, because deleting either would put the address back in front of the next campaign; a customer's monitored list and uploaded bulk file, which are their records under their own retention; the seven-day repeat marker, a hash and a timestamp that expires by itself; and the one-way hash of an address that claimed the new-account credit bonus, which exists so the bonus cannot be claimed twice. The erasure page names all five beside the form.
What this means for your own compliance
Your records of processing can describe the verification precisely: an address is sent to a processor, answered, and held by that processor in your own history for 30 days, in a bulk file for 30 days if you uploaded a list, and in a monitor for as long as you keep the monitor. Your privacy notice can tell your users that addresses are verified without any message being sent. And your erasure procedure can point users at the self-serve form for the part of their data that sits with Spaw, or run the deletion through your own account: deleting a history row, a suppression entry or a monitor entry is available to you in the dashboard and the API.
The methodology page states the same facts in the product's own terms, and the trust page carries the security controls and the subprocessor list.
What to do next
- Read the retention table in the privacy policy; every window in it is pinned by a test to the code that deletes.
- Send a person who asks about their address to the erasure form.
- Read how the product works for what each check reads and what it never claims.