Plan the Send Order for a Verified List: Valid First, Then Risky, Then Never

Send a verified list in order: valid rows first, a small test batch of risky rows second, and never the invalid rows. The result of a check is not a yes or no. It sorts the list into groups with different odds, and the order you send them in decides how much a bad group can hurt you.

Start from the result file

Upload the list on the verify page and download the result. Each row has a status (valid, risky or invalid) and a reason. If you want a view of the list before you check it, the email list send tier splitter sorts addresses by shape into company, free provider, role and fix-first tiers. Those tiers describe how the address looks, not whether the mailbox exists. The send order below comes from the verification result.

The four groups

Group	What it is	What to do
Valid	A mailbox the check could confirm	Send first
Risky: accepts all addresses	The domain takes mail for any name	Small test batch, after the valid rows
Risky: role address or other reason	A shared inbox such as info@	Decide by purpose; often fine for a store, poor for a personal pitch
Invalid	No mailbox, no mail server, a typo domain	Suppress. Do not send

Valid, risky, invalid and catch-all: how to read the report explains each reason in full.

Step 1: Suppress the invalid rows now

Put the invalid addresses on your suppression list before anything else, in the sending tool and in any other tool that can email them. A suppressed address that comes back on a later import is the usual way the same bounce happens twice. How to build a cold email suppression list shows how to keep it from leaking.

Step 2: Size the batches for the valid rows

For a small list, send the valid rows in one go. For a large one, grow the batches over days so no mailbox provider sees a sudden jump from a sender it barely knows. The daily batch splitter gives each address a send day on a growing schedule, with domains mixed through each day. Verify a large list in daily batches covers matching the check to the send.

Step 3: Read the first batch before the second

Send the first batch and wait. Bounces from dead mailboxes come back within minutes to hours; some servers retry for days before giving up. Look at three things before you send the next batch:

1. The hard bounce rate on that batch. The target is under 2%, and ideally under 1% (benchmarks, with sources).
2. Which domains bounced. Two or three domains accounting for all the bounces means a domain-level issue, not a list-wide one.
3. Replies and complaints. A spike in either is a reason to pause.

If the rate is above your ceiling, stop. What to do after a high bounce rate is the next page to read.

Step 4: Size the risky test batch with arithmetic

Risky rows are the ones a check could not confirm, so some will bounce. Work out how many you can afford: take the number of emails in the campaign, multiply by your ceiling (say 2%), and subtract the bounces you already expect from the rest of the list. The catch-all send limit calculator does the sum from your numbers. How many catch-all emails can you send explains the reasoning.

Send that batch on its own, after the valid rows, and read its bounces the same way. If it behaves, send a larger one. If it does not, you have lost a small batch, not the whole domain's standing.

Step 5: Treat provider-limited domains as their own group

Some providers do not let a check confirm a mailbox honestly, so their rows come back risky however good the address is. Outlook and Hotmail rows currently behave this way, and Yahoo rows are hard to confirm. Why do Outlook and Hotmail emails come back risky explains it. Do not read a block of risky Outlook rows as a bad list; send them as their own batch and see.

A plan you can copy

For a list of 10,000 rows that comes back with a mix of groups:

1. Day 0: suppress invalid rows. Pick the valid rows.
2. Days 1 to 4: send the valid rows in growing batches, reading bounces after each.
3. Day 5: send a risky test batch sized by the calculator, plus a separate small batch of provider-limited rows.
4. Days 6 on: if both behaved, send the rest of the risky rows in steps; if either did not, stop and read the bounces.
5. After the campaign: add every new bounce to the suppression list.

What this plan does not do

It does not make a list permission-based, and it does not replace the pre-send checklist. A well-ordered send to people who did not ask for it is still unwanted mail.

Common mistakes

• Sending everything the day the result arrives. The result is a sort, not a green light for the whole file.
• Reading the first batch's open rate and ignoring its bounces. Bounces tell you about the list; opens tell you about the message.
• Mixing risky rows into the first batch to save time. If it goes wrong you will not know which group caused it.
• Forgetting to suppress new bounces from batch one before batch two goes out.

Check the list

Upload the list on the verify page and get the result file to plan from: 100 free checks, Google sign-in, no card.