Bulk HTX Email Checker: CSV Upload and Result Export Guide
Most notification lists on a crypto exchange were not built in one sitting. They accumulated: signup batches from 2019, a CSV from a marketing agency in 2021, addresses scraped from support tickets, a merge after the Huobi-to-HTX rebrand. Nobody audited the merge. The bulk check is where the accumulated damage becomes visible, and the CSV is how you make it auditable. Bulk HTX Email Checker is the ZelNum page designated for this job: HTX Email Checker.
Quick answer
Build the file with one email per row plus a record ID that points back to the source system. Run the check. Export with registration status and domain risk per row. The risky-domain rows are your repair queue; the invalid rows are your replacement queue. Then put a re-check date on the calendar, because a notification list that was clean in Q1 is a guess by Q4.
The column contract
Keep the file boring. Boring files survive handoffs between teams and years.
| Column | Rule |
|---|---|
record_id |
The key back to your source system, stored as text. If the source uses numeric IDs, pad them or prefix them — Excel will happily turn 00871 into 871 and silently break the join. |
input_email |
The original value, byte for byte. No trimming, no lowercasing. If the account has [email protected] on file, that is what goes in the file. |
source_batch |
Optional but worth it: which import the row came from. When 6% of rows fail, the batch column tells you whether the damage is spread evenly or concentrated in one old agency file. |
registration_status |
Filled by the check: registered, risky, unknown, or invalid. |
domain_risk |
Filled by the check. This is the column that catches typo domains, and it deserves its own section below. |
checked_at |
Timestamp. Without it, a re-check six months later has nothing to compare against. |
Why the domain-risk column earns its place
Format validation checks whether an email looks like an email. It says nothing about whether the domain can receive mail. Three patterns pass every format check and still fail:
- Typo domains.
gmial.com,hotmial.com,protonmai.com. The address is syntactically perfect and the inbox does not exist. - Dead throwaway services. A disposable-email provider that shut down leaves thousands of addresses that were valid at signup and resolve to nothing now.
- Parked domains. Registered, resolving, no mail service. Every row returns "registered" if you only check registration.
The domain-risk flag is what separates these from genuinely clean rows. In practice, a list that has been through an agency handoff or a platform migration carries a few percent of typo domains, and those rows are the ones that look fine in the CRM and bounce anyway.
Reading the export
Take a realistic run: 8,800 addresses on a notification list that has been merged three times. The export comes back 72% registered and clean, 15% risky domain, 9% unknown, 4% invalid. (The numbers shown are illustrative, and they are not a vendor benchmark.)
The temptation is to start with the 4% invalid rows. Wrong order. The 15% risky-domain slice is where the recoverable damage is: a gmial.com row can often be corrected in one pass if the intended gmail.com address is unambiguous, and a typo fix restores an existing account holder's notices. The invalid rows usually need the account holder to supply a new address, which is a slower process with no guaranteed answer. Work the repair queue while the replacement queue works its own queue.
Routing the export
- Registered, clean → keep. Log the timestamp and move on.
- Risky domain → repair attempt. If the correction is obvious (one transposition from a major provider), fix it and re-run just those rows. If not, suppress with the reason recorded.
- Invalid → replacement. Suppress the row, flag the account for an updated address at next contact.
- Unknown → hold. Unknown is a retry queue, not a verdict. Re-run after a few days before deciding anything.
One rule that saves arguments later: do not deduplicate the file before the check. Two rows with the same address may come from different source systems, and the check reports per row. Merge after you see the results, so each duplicate carries its own evidence trail.
The re-check rhythm
A notification list decays at a few percent per quarter — people abandon addresses, providers shut down, corporate domains get retired after acquisitions. A list checked once a year carries up to a year of silent rot, and the failure is invisible until the day a withdrawal notice needs to arrive.
Quarterly is the baseline for a list of this size. Add two trigger-based checks: before any security review, and after any merge or migration touching the file. The second one matters more than teams expect — merges are where typo domains and lost record IDs get introduced, and catching them in the merge week costs minutes.
Mistakes to avoid
- Treating "registered" as "reachable." The address exists. The inbox may be abandoned, full, or behind a provider that blocks bulk senders. Registration is the floor, not the goal.
- Dropping the domain-risk column in the export. Some teams export only the status. That deletes the field that catches the typo domains, and the next person to audit the file has to re-run the whole check to recover the information.
- Fixing the file without fixing the source. If
gmial.comentered through a signup form, correcting the CSV row fixes one symptom. The form keeps producing them.
FAQ
Why keep the original email value untouched in the file?
Because the original is what the account has on file. If you lowercase or trim before the check, a mismatch later is impossible to diagnose — you cannot tell whether the discrepancy came from the check or from your own preprocessing.
What is a notification registry, in plain terms?
The set of addresses that are supposed to receive withdrawal confirmations and risk warnings for their accounts. Its health is measurable: the share of addresses that can actually receive those notices today.
Can this export support an internal audit?
Yes, and that is most of its value. Status plus domain risk plus timestamps per row is the evidence an auditor wants: not "we manage our list," but "here is the December run, 4% failed, here is what happened to each failed row."
Should unknown rows be retried automatically?
On a schedule, yes. Unknown results cluster around transient provider issues, so a re-run a few days later resolves most of them. What you want to avoid is treating unknown as invalid and suppressing rows that were only ever sleeping.
How does this relate to the Huobi rebrand?
Lists merged during the Huobi-to-HTX transition carry the usual merge damage: duplicate rows with different record IDs, typo domains from manual corrections. The check surfaces both. The migration-specific review workflow is covered in the use-cases article.
Related ZelNum pages
- How to Use HTX Email Checker for the step-by-step interface workflow behind this file format.
- HTX Email Checker Use Cases for the Huobi-era list migration and notification-channel review scenarios.
Ethan works on phone-number normalization, E.164 formatting, country-code rules, carrier metadata, and line-type detection. His editorial work turns verification signals into practical workflows for CRM cleaning, SMS preparation, lead review, and bulk data operations.
View full author profile →