Verify before Postmark sends, not after the bounce
Postmark automatically suppresses an address the moment it hard-bounces or draws a spam complaint, so it stops mailing a known-bad recipient after the first failure — but it can't judge an address before that first send. And Postmark is a transactional and API sender: there's no hosted audience to export and scrub, because the addresses come straight from your own signup forms, checkout flows, and API calls. That first send is usually the message that matters most — a password reset, a receipt, a verification email — and it's exactly where a never-verified typo or dead mailbox bounces. Qualisend closes that gap: verify every address at the point of capture and before any batch send, then suppress the failures so junk never triggers a Postmark send in the first place. Here's the workflow that works today, plus the API and no-code options.
One-click Postmark sync is paused while we rebuild the platform
We've deliberately paused our one-click native connectors while we re-engineer the sync layer they run on — hardening how we authenticate, respect each platform's rate limits, and write results back — so that when the native Postmark integration returns, it stays dependable at any list size rather than fragile at scale. None of this touches how Qualisend verifies an address.
Everything you need works today: the CSV export → verify → reimport loop below, and the API for verifying at signup, are both fully supported and running in production — that's how teams keep Postmark clean right now.
What Postmark cleans for you
Postmark's native hygiene runs on a Suppression List, kept per Message Stream. An address is added to it after a hard bounce, a spam complaint, an unsubscribe, or a manual suppression, and once suppressed it's automatically deactivated — the next send through that stream simply disregards it. That protects your standing with the mailbox providers and keeps you from repeatedly hammering a dead address. Reactivation is deliberate: hard bounces and unsubscribes can be reactivated from the stream's Suppressions tab or by deleting the suppression through the Suppressions API, but spam complaints can't be undone by you — Postmark won't let you reactivate an address that marked your mail as spam without contacting support. For addresses Postmark has actually sent to, that's reliable, automatic hygiene.
What it can't catch
The catch is that every one of those mechanisms is reactive — it needs a send and a failure to fire. Postmark only suppresses an address after it has already hard-bounced or been reported, which means the credit is spent and the reputation hit is taken before the list gets any cleaner. And because Postmark is a transactional sender rather than a marketing platform, the blind spot is wider than it looks: it has no signup-list of its own to pre-check, so a signup typo (jane@gmial.com), a disposable address accepted at checkout, a role address like info@ or support@, or a mailbox that has quietly decayed all arrive from your app looking perfectly healthy, and Postmark has no signal on any of them until your code fires the first message. A recipient batch you assemble for a broadcast stream is the sharpest case — it lands with no bounce history at all, so addresses that were already failing elsewhere look brand new, and Postmark will dutifully deliver each one straight into a hard bounce.
Why a clean Postmark list matters
On Postmark the stakes are unusually concrete. Postmark polices deliverability with hard numbers: it wants your bounce rate under 10% and your spam-complaint rate under 0.1% on every Message Stream, it turns the stream's metrics orange as you approach those limits and red once you cross them, and it reserves the right to pause or suspend sending on a server whose rates stay too high. A wave of never-verified invalids is the fastest way to push a stream into the red — and on a transactional account that bounce lands on the receipts, password resets, and verification emails your users are actively waiting for, the mail you can least afford to have paused. There's a billing angle too: Postmark bills by emails sent, not by contacts stored, with no rollover, so every message delivered into a hard bounce burns paid volume (or overage) on mail that was never going to arrive. Verifying before the send does both jobs at once — it keeps your bounce rate well under Postmark's threshold and stops you paying to deliver into dead mailboxes. It's the same bounce and complaint math Gmail and Yahoo's 2024 sender rules now judge you on directly.
The workflow that works today
Postmark has no hosted contact list to export and reimport — the addresses come from your own app and API, so the honest fix is to verify them before Postmark ever sends, then suppress the failures.
Verify at the point of capture
Catch the address where it enters your system — the signup, checkout, or account form — before you store it or let it trigger its first Postmark send. A single Qualisend API call at that moment stops typos and disposable addresses from ever becoming a recipient, which is the highest-leverage place to verify on a transactional sender.
Verify any recipient batch before you send it
Sending a broadcast stream or a bulk run through the API? Verify the recipient list first. Upload the file to Qualisend bulk cleaning — up to 1,000,000 addresses per job, duplicates charged once — or paste addresses directly. The free plan's 100 one-time credits, which never expire, cover a first sample before you commit.
Read the results
Every address returns deliverable, risky, undeliverable, or unknown with a reason code, a 0–100 score, and sub-flags (catch-all, disposable, role, full mailbox), plus the MX provider and probe detail as evidence. Download the cleaned file, or read the verdict inline from the API response.
Suppress the failures in Postmark
Take everything that came back undeliverable and make sure it can never trigger a send. Add those addresses to the relevant Message Stream's Suppression List as manual suppressions — through the stream's Suppressions tab or the Suppressions API, up to 50 addresses at a time — and record the verdict in your own database so your app never re-queues them. That does the reputation-saving work before the send instead of after the bounce.
Or automate it at signup
The point-of-capture check is built for automation. Call the Qualisend REST API (scoped keys, rate limits, webhooks) inside your signup or checkout handler so an address is verified before it's stored or handed to Postmark, or wire a no-code flow through Zapier, Make, or n8n so every new lead is checked the moment it arrives. You can close the loop the same way — chain a verdict of undeliverable straight into Postmark's Suppressions API so the address is manually suppressed automatically, before your app ever asks Postmark to mail it.
What Qualisend flags on every address
- Never-verified invalid addresses that would hard-bounce on their first Postmark send — often a password reset or receipt
- Disposable / throwaway domains accepted at signup or checkout that were built to expire
- Role addresses (info@, support@) that draw complaints and skew engagement on broadcast streams
- Catch-all domains, flagged so you can route them to a separate stream and send cautiously
- A 0–100 confidence score and machine-readable reason code for every address, ready to write back as a manual suppression
A native, one-click Postmark connector is part of the platform we're rebuilding — it's returning, not deprecated. Until it ships, the API and the verify-before-send workflow above are the fully supported path, and they work with any Postmark plan.
What to do with each result
Every address comes back with a verdict and sub-flags. Here's the action that keeps your Postmark list clean without throwing away contacts you can still reach.
deliverableSend as normal — transactional or broadcast.deliverable + role flagFine for account and transactional mail; keep off engagement-judged broadcast sends.risky + catch-all flagRoute to a separate stream and send cautiously — the domain accepts everything at the door, so the mailbox can't be confirmed.risky + disposable flagAdd as a manual suppression — the inbox was built to expire.unknownLet it through and re-verify next time — usually greylisting or a rate-limit, not a verdict on the mailbox.undeliverableAdd to the stream's Suppression List now; don't let it bounce on a receipt and push your rate toward Postmark's 10% limit.Related reading
Clean recipients are half of deliverability — authenticate your Postmark sending domain too.
Verify at the point of capture so junk never triggers a Postmark send.
Spot-check a sample of your recipients before you wire up the API.
Postmark caps your bounce rate at 10% per stream — here's why that number bites.
Why one bad send on a transactional stream costs more than a wasted credit.
The 2024 bounce and complaint thresholds your Postmark sends are judged against.
Postmark verification FAQ
Clean your Postmark list in minutes
Start free with 100 credits that never expire — no card required. Export, verify, reimport, and protect your next campaign.