Bulk Importing a Suppression List Into SparkPost: 10,000 per Request, 1,000,000 in Total

Chunk the file into batches of 10,000, send each as a bulk PUT with a type on every entry, and resubmit any batch that returns a 5xx. That's the whole job for SparkPost's suppression list API, with two account-level limits to plan around: 1,000,000 imported or manual entries in total, and compliance-added entries that can't be changed. Do it before the first send from the new account, and verify the active list as well, because suppressions only cover addresses you already knew were bad.

Sources, read 2 November 2026: SparkPost's suppression list API reference and Bird's suppressions guide. These describe the SparkPost API (api.sparkpost.com, and api.eu.sparkpost.com for EU accounts); check the reference for your account's region and current Bird docs if you're on Bird's newer email platform.

The limits in one table

Item	Limit or rule
Bulk create or update	PUT /api/v1/suppression-list/, body {"recipients": [...]}
Per request	Up to 10,000 recipients, 50 MB
Per account	Up to 1,000,000 bulk-imported or manually added entries
Entry fields	recipient and type required; description optional
Types	transactional, non_transactional, open_tracking
5xx during bulk load	May be partially written; resubmit the original request
Compliance-added entries	Can't be updated; deleting returns 403
Reading back	per_page 1 to 10,000; page up to 10,000 results; cursor=initial beyond that

Step by step

1. Export the old provider's history: hard bounces, spam complaints, unsubscribes and manual blocks, with the reason for each. The bounced email extractor turns a mailbox of bounce messages into a list if that's all you have.
2. Merge and dedupe. The suppression list merger combines exports from several tools into one file with a reason per address.
3. Prune if you're near the 1,000,000 cap. Very old unsubscribes from lists you'll never mail again can stay in your own records instead of the account.
4. Assign types. Hard bounces and complaints: one entry per type, transactional and non_transactional, so neither kind of mail goes to them. Marketing unsubscribes: non_transactional only. Put the source and date in description; it helps the next migration.
5. Send in chunks of 10,000 with a pause between requests, and log each batch's response. On a 5xx, send the same batch again; on a 4xx, read the error, fix the entries and resend.
6. Read back a sample with the search endpoint to confirm the counts, using a cursor if the list is larger than 10,000.
7. Verify the active list on the verify page and add invalid results as suppressions too, so the first campaign doesn't relearn bounces one by one.

What a suppression import can't settle

It only blocks addresses you already know about. Addresses that went bad since the last send, typos collected by a form, and old contacts that were never mailed from the previous provider aren't in any export. That's what a check of the send list is for. Even then, catch-all domains accept any address and Microsoft consumer mailboxes often don't answer single-mailbox checks reliably, so a share of results comes back risky or unknown. For the migration side of a Bird move, see SparkPost and Bird migration suppressions; for what belongs on the list, suppression list.

Where SimpleVerifier fits

Check the send list on the verify page, or call the API at signup so new typos never reach SparkPost. The first 100 checks are free with a Google sign-in. Pro is $39 a month with the first 100,000 checks a month at full speed, then slower, never cut off; API use has its own limits and isn't unlimited. See pricing.