Postmark holds suppressions and nothing resembling an audience. The address inventory is your users table, and the streams split it by purpose rather than by segment.
Getting the addresses out of Postmark
Postmark holds no marketing contact list. Suppressions can be pulled through the API, and your user database is the list.
At account creation in your product. A transactional sender has no list to clean, so the only useful intervention is refusing to store an address that does not resolve.
What Postmark 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
- There is no contact import for transactional streams.
- Suppressions are per message stream, so an address suppressed on broadcast can still receive transactional mail, which is deliberate and correct.
- The API exposes suppressions for reconciliation against your own records.
- Postmark's onboarding asks about your use case, and answering it honestly avoids a stream being shut down later.
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.
42 typos a month, and the password reset that never arrives
Say your product gets 1,900 signups a month and 2.2% of people mistype their address, which is about 42. Each one is sent a welcome email through Postmark, each bounces hard, and Postmark deactivates the address on that message stream. So far that's tidy.
Trouble starts when the address wasn't a typo. Suppose 6 of those 42 were real mailboxes whose server wrongly answered user unknown during a migration. Two weeks later one of those customers asks for a password reset. Your app calls the API and Postmark declines to send, because the recipient is inactive. The customer sees nothing, tries twice more, and writes to support.
A check at signup catches the 36 real typos while the person is still on the form. For the other 6, have your bounce webhook write the state to the user record so support can see it and reactivate the address from the Suppressions tab.
You can undo a bounce, but not a complaint
Postmark lets you reactivate a hard-bounced address yourself, through the Suppressions tab or the Suppressions API. Spam complaints are treated differently. Their support documentation says that once a complaint is recorded you can't reactivate the address on your own, and you'd need to email their team after the recipient has asked to hear from you again.
Retention is the other detail to plan around. Bounce records and message activity are kept for 45 days by default. After that the suppressed address is still listed and searchable, but the detail explaining why it bounced has aged out. If you want to study failures by signup source over a quarter, store the bounce webhook payloads in your own database from the start.
Billing is per email sent, so a bounce costs what a delivery costs. At transactional volumes that's small money, and the support ticket is the real expense.
Questions people ask
Does Postmark need list cleaning?
Not in the marketing sense. The equivalent work is validating addresses at registration so your database never holds one that does not exist.
Where does verification fit with a transactional sender?
At the signup form, as a real-time check with a short timeout. It stops the bad address entering the database, which is the only place the problem can actually be solved.
What about broadcast streams?
Those behave like ordinary marketing sending and benefit from a normal verification pass before a campaign, with unresolved addresses held back from the first send.