How to Read a Verification Report and What to Suppress

Spreadsheet of verification export results with invalid rows marked to suppress

An email verification report is only useful if you do something with it. The file comes back labeled. Someone still has to decide which rows may be mailed, which rows must never return through the next import, and which rows need a second look. This guide shows how to read that report and how to suppress invalid emails without guessing at column titles.

It sits between the vocabulary in email verification results and the operational cleanup in how to remove invalid emails. Uploading the file is walked through in the bulk verification guide. Open kukudze’s email verifier when you want the product itself.

What the report is asking you to do

A verification export, sometimes called email verification CSV results, is a copy of your list plus the outcome of each check. If you open it in Excel, the CSV tutorial shows how to keep IDs intact. Some tools also print a short summary: how many rows were valid or deliverable, how many failed, how many came back unknown, how many carried a caution flag.

The report is not a send button. It is a set of recommendations you still have to apply inside your ESP or CRM. If you download the file and then import every row again as subscribed, you have done the work of checking without gaining the protection.

kukudze labels each row Valid, Invalid, Risky or Unknown, and a Valid row on a domain that accepts all mail gets a note. Other tools use other words. Treat the categories below as industry language and map them onto whatever headings your download uses. Avoid inventing export headings in the internal runbook.

Start with the summary, then sample the rows

Before you build filters, look at the totals:

  • If invalid or undeliverable rows are a large share, the source of the file may be old, purchased, or poorly typed. Plan more time for suppression and for a conversation about how addresses enter the database.
  • If unknown rows dominate, the destination servers may have been slow or guarded. Plan a retry rather than a mass delete.
  • If caution flags (catch-all, disposable, role) are common, you need a written policy before anyone starts deleting by feel.

Then open a sample of each category. A summary that says “12 percent invalid” should match what you see when you filter that label. If the numbers and the rows disagree, stop and check that you are reading the right column.

Translate each label into an action

Use the results glossary for definitions. This page focuses on the next action.

  • Valid or deliverable. Eligible to stay in the sendable audience, assuming you also have permission to contact the person. The report does not create that permission.
  • Invalid or undeliverable. Suppress first, then archive or delete according to your ESP’s own guidance. These are the rows most reports exist to remove from future campaigns.
  • Unknown. The check did not finish. Retry later. Do not sweep them into the invalid pile, and do not drop them unexamined into a large first send.
  • Catch-all (sometimes called accept-all). The domain accepted the recipient without proving that inbox. If you include those rows, park them in a named catch-all group.
  • Disposable. For newsletters and account notices, the usual first move is suppression, unless you have a written reason to allow a short-lived relationship.
  • Role. A shared function inbox. Decide by channel: operational mail may need billing@; a broadcast newsletter often should not lean on it.
  • Spam-trap or do-not-mail flags, when a vendor prints them. Honor the vendor’s instruction not to mail those rows. Do not keep a few extra rows by second-guessing a trap label.

Which of those flags appear in your file depends on the tool that produced the report. kukudze runs the same 4 checks on every plan: format, whether the domain can receive mail, the mailbox answer, and whether the domain accepts all mail. It does not flag disposable, role or spam-trap addresses. If you need those, filter role prefixes and known temporary domains in the sheet yourself. If a flag you expected is missing from the export, check what the tool covers, not only the spreadsheet.

kukudze’s Free plan runs those same 4 checks, with 100 checks a month and lists up to 50 rows. A report from Free has the same labels as one from a paid plan.

What to suppress, correct, or hold

Suppression means the address remains on a block list so a later spreadsheet cannot quietly restore it to a campaign. Correction means you have a better, consented value to use instead. Holding means you will retry or review, not mail at full volume today.

A practical split:

What the report showsFirst actionThen
Invalid or undeliverableAdd to suppressionArchive or delete using your ESP’s process
Clear typo with a known fixConfirm the corrected value with the owner of that inboxRe-check the new value; keep the broken string off sends
Unknown after one passHold and retryIsolate any leftovers you later decide to mail
Catch-allHold in a named segmentSend only if you accept additional bounce risk
Disposable, when that flag is presentSuppress for marketingAllow only under a written exception
Role, when that flag is presentSegmentInclude only if that channel needs a function inbox
Unsubscribe or complaint, if present from your ESP rather than the verifierSuppressNever re-import as subscribed

The table is an operations aid, not legal advice. Transactional messages (receipts, password resets) may still need a path that marketing mail should not use.

How to move the decisions into your sending tool

Once the verification export is filtered, load actions rather than raw rows.

Mailchimp already parks many bounce failures in a cleaned state. Its help article about cleaned contacts says those rows reached that state after either a hard bounce or several soft bounces, that audience campaigns will not go to them, and that viewing, exporting, or archiving those rows is supported. When the invalids come from a verifier file rather than from Mailchimp’s own bounce handling, use Mailchimp’s article on importing a suppression list. That article walks through loading the addresses so they arrive with unsubscribed status and are not created later as subscribed people. Mailchimp warns the suppression import will not flip anyone who is already subscribed; for that case it directs you to bulk unsubscribe. Keep the two paths distinct: cleaned status for failures Mailchimp saw itself, and a suppression import for an outside block list.

In HubSpot, hard-bounced contacts are already dropped from future marketing emails, according to HubSpot’s page on deleting contacts who no longer receive marketing email. If you want a verifier-invalid file kept out of one send without erasing records, HubSpot documents a Don’t send to control in the email editor. A static segment of report-invalid rows is a practical thing to attach there.

Other ESPs have their own suppression or exclusion lists. The pattern is the same: apply the report as a block list, then tidy the database if your retention policy requires it. More of that operational detail lives in the remove invalid emails guide.

Keep a record so suppressed rows stay suppressed

Three things make a report useful six weeks later:

  1. The original labels, kept on the contact record or inside the segment’s title. “Verifier-invalid, March 2027” is clearer than a silent delete.
  2. A count before and after. How many rows entered, how many were suppressed, how many were held, how many remained sendable.
  3. The source file name and date. When someone asks why an address is missing from a campaign, you can answer from the record instead of from memory.

If a teammate later uploads last quarter’s enrichment file, the suppression record is what prevents the same invalids from coming back. Reading the report without writing those decisions down is how lists refill.

Watch for these reading mistakes

A few habits turn a useful export into a wasted one.

Do not invent extra columns because a template you used at another vendor had them. If the download has no trap flag, that may be because the tool you ran does not check for spam traps, not because you failed to scroll far enough.

Do not mail a “safe looking” slice of invalids as a test. The label already told you those rows should not be sent. Testing them against a live campaign is how you buy bounces you already paid to avoid.

Do not skip the sample step when the summary looks clean. Open a handful of valid rows and a handful of invalid rows and confirm the labels match what you see in the address itself. A reversed filter, or a sort that hid a result column, is easier to catch in ten rows than after the send.

If two people will handle the file, write the action next to each category before the spreadsheet changes hands. “Suppress,” “retry later,” or “segment as catch-all” is clearer than leaving a teammate to interpret colors.

FAQ

What if I do not recognize the column titles?

Match them to the categories above (failed versus unfinished versus caution). On kukudze, Invalid means failed, Unknown means unfinished, and Risky needs a closer look. If a heading is unclear, do not guess: ask the tool’s support before you act on it.

Should I suppress every row that is not marked valid?

No. Unknown is unfinished. Catch-all is unproven, not failed. Role and disposable are caution flags that need a policy. Suppressing every non-green row will drop people you can still reach.

Can I send to the “valid” tab without looking at permission?

No. The report speaks to deliverability at check time. Unsubscribes, complaints, and people who never opted in belong off the campaign even when the mailbox exists.

Do I need to re-read the report after I suppress?

Yes, at least the counts. Confirm that the sendable file no longer contains the invalid rows, and that your ESP suppression path actually received them. Then mail a typical-size campaign and review leftover bounces. Feed new hard failures back into the same suppress path.

Will a syntax-only export look like a full report?

Not in any useful sense. Format review can mark broken strings. It cannot label abandoned mailboxes. kukudze has no syntax-only export: every plan, Free included, also checks the domain and the mailbox. Choose a tool whose checks match the decisions you need to make from the file.

Wrapping up

To read an email verification report, start with the totals, sample each label, and turn those labels into suppress, correct, hold, or send. Keep invalid rows on a block list so the next import cannot revive them. Do not bulk-delete unknown or catch-all rows. Match caution flags to the tool that produced the file, and match the export headings to the file you downloaded rather than to invented column names. The report is finished when the sendable audience has changed, not when the CSV has been downloaded.

Check your list before you send. Try the verifier with one address or a CSV list.

Start verifying