A list across twenty countries behaves like twenty lists

Your list has grown past one market and the results don't look like they used to. A file that is a third German, a quarter Japanese and the rest spread across a dozen countries behaves nothing like a US consumer list.

The differences are structural rather than a quality problem with anybody's data. Provider behavior varies by market, and provider behavior is most of what sets coverage.

The order the work happens in

  1. Break the results down by domain before judging them

    An aggregate across twenty countries hides everything useful. Grouping by provider shows which markets resolved well and which did not, and they will differ sharply.

  2. Learn the large regional providers

    Web.de and GMX in Germany, Seznam in the Czech Republic, Mail.ru in Russia, QQ and 163 in China, Naver in Korea. Several of these reject unknown recipients cleanly and resolve better than the giants.

  3. Handle non-Latin addresses properly

    A domain in another script is encoded for DNS and travels fine. A local part in another script needs support at every hop, including your own sending tool. Check the tool before you blame the list.

  4. Set a target per market, not per list

    One coverage target across a file from twenty countries gets met by the easy markets and missed by the rest. The average tells you nothing about either group.

  5. Check the local rules before the send, not the check

    Consent requirements differ by country and apply to sending. Cleaning the file does not change what you are permitted to do with it.

What each result means here

The same four results and their flags, read against this job. A catch-all worth keeping in one situation is one to exclude in another.

ResultWhat to do with it
ValidSend, and record which provider it came from so the pattern is visible next time.
InvalidRemove. Clean rejections are more common outside the largest providers, which is good news for coverage.
Catch-allConcentrated in business domains and in some regional hosting setups. Segment by country rather than treating it as one pool.
UnknownHigher in markets with many small hosting providers. Re-check later rather than discarding a market's contacts.
Role flagRole conventions vary by language, so a list built for English local parts will miss some and flag others wrongly.
Disposable flagDomain lists skew towards English-language services, so detection is weaker outside those markets.

How you know it is finished

You can state coverage market by market rather than for the list as a whole. The weak markets have a named reason sitting next to them, and that reason is the provider mix.

What this does not fix

International files often carry a larger unknown share, and unknown results are not billed, so the bill tends to sit below the row count rather than at it. The per-address rate is the same wherever the domain is.

Questions people ask

Why does verification work better in some countries?

Because coverage follows provider policy. Markets dominated by providers that reject unknown recipients cleanly resolve well; markets full of small hosting companies that throttle or refuse probes resolve worse.

Can addresses with non-Latin characters be verified?

The domain half is encoded for DNS and handled normally. A non-Latin local part needs support at every hop including your sending platform, and that is where the failures usually are.

Does cleaning a list make international sending lawful?

No. Consent rules vary by country and govern the sending rather than the address. A verified address in a market where you have no consent is still an address you should not mail.

Try it on the file in front of you

100 free checks a month, no card. Addresses we could not get an answer on come back labeled as unknown, and those are not billed.