There is no list. Users arrive from your warehouse and your product, and what you would export is a query result rather than an audience somebody curated.
Getting the addresses out of Iterable
The data export or the API returns user records with their fields. Iterable is API-first and the CSV path is the less-used one.
In the ingestion pipeline, as a step between your warehouse and the user upsert. Fixing it downstream means fixing the same rows again after the next sync.
What Iterable does with the file you bring back
The import rules decide what a re-import actually changes, which is worth knowing before you upload.
The short version
- Users upsert on email or a user ID, so the same person updates rather than duplicating.
- A hard-bounced user stays unsubscribed from email through subsequent updates.
- User fields carry arbitrary data, so a verification verdict and its date fit naturally.
- Bulk API updates are the normal path rather than a CSV import.
The mistake to avoid
Some addresses come back unresolved, and that is a fact about the receiving server rather than a gap in the check. We label those and never bill for them. What that means, and why roughly 28% of business addresses land there, is set out on our page about catch-all domains.
600 signups a month that lose email on day one
Say your product takes 40,000 signups a month and 1.5% of them mistype their address. That's 600 people. Each one triggers a welcome message from a transactional channel, and each of those hard bounces within seconds.
Iterable's bounce documentation describes what comes next. A hard bounce unsubscribes the user from the channel the message came from and from your marketing email channels too, and that applies even when the bounce came from a transactional send. So 600 new users a month lose lifecycle email before onboarding starts, while push and SMS stay subscribed.
A real-time check in the signup form catches most of them while the person can still retype the address. For the rest, store the verdict and the date as user fields, and keep the unknowns out of your first journey step until they've opened something.
Hard-bounce unsubscribes don't show up where you'd look
You might expect 600 extra unsubscribes a month to be visible in reporting. They aren't. Iterable's docs say unsubscribes caused by a hard bounce are left out of the unsubscribe metrics in campaign analytics. To find them, query for emailUnSubscribe events where unsubSource is HardBounce, or look at the bounce event's recipientState property.
Run that query over the last ninety days before you plan any cleanup. The count tells you how much of your base has already lost email, and grouping it by signup source usually points at one form.
There's something to confirm with your own project settings as well. Projects can identify users by email, by user ID, or by a hybrid of the two, and that choice decides what happens when someone corrects a typo. In an email-keyed project, a change of address goes through the update email endpoint, so check whether the corrected user gets their subscriptions back or needs resubscribing in code.
Questions people ask
Where should verification sit with Iterable?
In the pipeline that creates user records. Checking at ingestion stops the bad address entering, which is the only durable fix in a system where the list is generated from your data.
Can verification results be stored as user fields?
Yes, and they should be. A field holding the verdict and the date lets segments exclude unresolved addresses without deleting the user.
How often should stored verdicts be refreshed?
Treat a verdict as good for a few months. B2B addresses decay faster because people change jobs, so refresh before any large send to an older cohort.