How do I avoid wasting credits on duplicate addresses?

Duplicate addresses are the easiest source of wasted credits in Valid Email Checker. The platform has built-in protection, but a few extra layers in your own data pipeline catch the duplicates that slip past the default dedupe pass.

Layer 1: trust the built-in dedupe

The Bulk Upload page has a "Remove duplicates" toggle that is enabled by default. With it on, the upload removes exact-match duplicates before any credit is charged. A 50,000-row CSV with 8,000 duplicates becomes a 42,000-row job, and you pay for 42,000 verifications. See how bulk upload deduplicates addresses for the matching rules. Leave the toggle on unless you have a specific reason to count duplicates (rare).

Layer 2: normalize before upload

Default dedupe is case-insensitive but otherwise literal. These look different to it:

• john@gmail.com and john+newsletter@gmail.com (Gmail plus-aliases all route to the same inbox).
• john@gmail.com and j.o.h.n@gmail.com (Gmail ignores dots in the local part).
• john@example.com and john @example.com (trailing/leading whitespace).
• john@example.com and john@example.com. (trailing dot in some exports).

If your source has a lot of Gmail plus-alias variations, pre-process the CSV with a small script that normalizes Gmail addresses (strip everything after + in the local part, remove dots in the local part) before upload. That alone can cut a typical B2C list size by 5 to 15%.

Layer 3: cache verification results in your own database

Once an address comes back safe, the result is good for roughly 30 to 60 days. If the same address shows up in a future job (a re-signup, an export from a different system, a duplicate import) you do not need to re-verify it. Store a vec_verified_at timestamp and vec_status on each subscriber row, and skip any address with a recent timestamp on the next bulk job.

Practical caching rules:

• Cache safe, invalid, disabled, disposable, spamtrap for 60 days.
• Cache catch_all and role for 30 days (the underlying state changes more often).
• Do not cache unknown (it was inconclusive and auto-refunded; re-run on next batch).
• Invalidate the cache on any explicit unsubscribe or bounce event from your ESP.

Layer 4: collapse cross-system duplicates

If you have several systems each pushing addresses into a verification queue (HubSpot, your app database, a third-party form), centralize the queue before calling Valid Email Checker. One dedupe pass against a unified queue is cheaper than running each system through bulk separately.