Bulk Email Verification Workflow: A Practical CSV Checklist

Bulk Email Verification Workflow: A Practical CSV Checklist

The question: you have a large contact list in a spreadsheet. How do you verify it in bulk without losing track of rows, paying again for repeated rows, or misreading uncertain results?

The short answer: export a clean UTF-8 CSV and choose the email column. Review repeated and unreadable rows before you start, let the run finish, and then sort by result. Valid and invalid results are your clear answers. Catch-all, unknown, still-checking, and technical-failure items each need their own handling.

The steps below follow FairValid's current help pages, checked on November 1, 2026: preparing a CSV or text list, understanding verification results, and how credits and returns work.

Step 1: Prepare a file that keeps your rows intact

Start in your spreadsheet tool, not the verifier. The CSV guide says FairValid accepts UTF-8 CSV or TXT files up to 100 MB (100,000,000 bytes) and 1,000,000 data rows. Pasted text can be up to 8 MiB and 100,000 rows. If your list is in a spreadsheet format, save it as CSV first.

A few habits that help:

• Put all addresses in one column. The guide asks you to put addresses in one column and select that column.
• Keep your other columns. Names, owner, source, and internal IDs can stay in the file. The guide says other columns stay attached to their original source row.
• Keep the header row. If the first row holds column names, select "The first row names the columns" when you upload.

If your list goes over the limits, split it at natural boundaries, such as by segment or source. Each file is then a separate import (see Step 3).

Step 2: Choose the column and review the preview

After you upload, look through the full-file preview and pick the email column. The CSV guide also asks you to review unreadable and repeated rows before you start a run.

This is the easiest point to catch mistakes. A wrong column choice or an encoding problem is much simpler to fix now than after a run.

Step 3: Understand how repeated rows are handled

Large lists often contain the same address more than once, for example after two sources are merged. Within a single imported list, a repeated address shares one verification result across its source rows. Repeated rows don't create extra sample or run charges (CSV guide).

This rule has limits. It covers repeated rows inside one import. It does not promise that the same address in a separate upload, a separate submission, or a later recheck will always be free. Where it makes sense, combine overlapping lists into one file before you upload.

Step 4: Plan your credits before you run

The credit rules are short:

• A completed valid or invalid result costs one credit.
• Unknown and unresolved catch-all results have zero net charge. Held credits are released or returned.
• Technical failures and unprocessed work have no net charge. They are not relabeled as Unknown.
• Pending is not a terminal result.

Balances work like this. The original account gets 300 free credits each month on its signup date, and they don't roll over. Additional workspaces don't get an extra free allowance. Free credits are used first. Paid credits don't expire while the account stays open, and returned credits keep their original lot and expiry rules (credits guide).

For planning, a cautious estimate is one credit for each unique address you expect to be verified. Your actual net charge depends on how many of those addresses end as completed valid or invalid results.

Illustrative example (made-up numbers, not a forecast): a 12,000-row CSV contains 1,000 extra repeated rows and 50 unreadable rows, which leaves about 10,950 unique readable addresses. Say 9,800 of them finish as valid or invalid and the rest finish as unknown or unresolved catch-all. The net charge is then 9,800 credits.

Step 5: Let the run finish

While an item shows still checking, it has no final answer yet (results guide). Don't treat it as unknown, and don't drop it. Wait for a final outcome before you decide anything about that row.

Step 6: Read each result for what it means

The results guide treats results as evidence, not as a delivery guarantee:

• Valid: a usable positive check. A valid result never guarantees inbox delivery.
• Invalid: the address did not pass.
• Catch-all: the domain may accept many addresses, so a mailbox-level conclusion may be less certain. Read the detail before you use the result.
• Unknown: the check could not return a dependable answer.
• Technical failures and unprocessed items: these don't create a net verification charge, and they are not relabeled as Unknown (credits guide).

Step 7: Decide what to do with each group

What you do with results is your team's decision, and it depends on your sending practices and risk tolerance. Here is one cautious illustrative approach:

1. Valid: keep for your next send, and keep monitoring bounces and engagement.
2. Invalid: suppress them or remove them from active sending lists.
3. Catch-all: read the detail first. Consider a smaller, separate send or extra confirmation before adding these to a main campaign.
4. Unknown: set these aside. Decide whether a later recheck is worth it. The repeated-row rule does not promise that a later recheck is free.
5. Technical failure or unprocessed: handle these apart from Unknown. They are not the same as an Unknown result.

Your other columns stay attached to each source row, which makes it easier to match each result to the record it came from.

A quick pre-flight checklist

• File saved as UTF-8 CSV or TXT, within the size and row limits
• Header option set correctly and email column chosen in the preview
• Unreadable and repeated rows reviewed
• Overlapping lists merged into one import where practical
• Credit needs estimated from unique addresses
• A plan agreed for catch-all, unknown, and technical-failure groups

Try it on your next list

To try this workflow, start with a small slice of a real list using the monthly free credits. Read the results guide alongside your output before you move on to the full file.