Reading Email Registration Check Result States

Most of the value in an email registration check is lost in the last step, when the response is folded back into a spreadsheet or a CRM field. A check returns several distinct outcomes, and collapsing them into a single registered/not-registered column throws away exactly the information that would have told you which addresses still need work.

This article walks through the outcome states you can get back, what each one licenses you to conclude, and where teams most often lose fidelity.

A completed result is a point-in-time signal

When a check completes, registered: true means the account existed at its provider at the moment the check ran. That is a narrow and useful statement, and it is worth being precise about what it does not cover.

It does not promise that a message will reach the inbox. Deliverability depends on your sending reputation, the content of the message, and provider-side filtering — none of which a registration check observes. It is also not proof of identity or ownership: an address existing says nothing about who controls it. And it carries no statement about consent or your right to contact the person behind it; that remains a question for your own records and your legal basis for outreach.

Finally, it is time-specific. An account can be closed after the check runs. If a list matters to your workflow, the practical question is not "is this result correct" but "how old is this result, and does my process tolerate that age".

Undetermined is not a soft "no"

The single most common mistake is turning an undetermined outcome into registered: false.

Catch-all domains are the clearest case. A catch-all domain accepts mail addressed to any local part, so the provider's answer cannot distinguish a real account from one that was never created. The honest result is undetermined, and that is what the check returns — rather than guessing a registration state that the provider never confirmed.

If you write undetermined into a false column, two things happen. You suppress addresses that may be perfectly good, and you lose the ability to ever revisit them, because nothing in your data now records that the question was left open. Keep undetermined as its own value.

Failed and invalid describe your input and the run, not the account

Two more outcomes are worth separating from each other and from everything above.

An invalid outcome means the input could not be accepted as an email address at all. This is a data-quality problem in your list, and the fix is upstream of any checking: repair the source, then resubmit.

A failed outcome means the check itself did not complete. The address may be entirely fine; the run did not produce an answer. These are the rows to retry, and retrying them is a different operation from re-checking a stale completed result.

Keeping these four buckets — completed, undetermined, failed, invalid — as four distinct values is the whole discipline. It costs one extra column and it is the difference between a list you can act on and a list you have to re-check from scratch.

Choosing an endpoint for the shape of your list

The same outcome model applies across every entry point, so the choice is only about batch size and how you want to wait.

A single address goes to POST /api/v1/check and returns directly. Up to 100 addresses can go to POST /api/v1/batch-check in one synchronous request, which suits interactive use inside a form or a record view. Larger lists belong in an asynchronous file task at POST /api/v1/bulk-tasks, which accepts from 1,000 up to 100,000 addresses per task and returns a downloadable result rather than blocking the request.

Avatar signals are a separate product and cover a documented set of families — Gmail, Yandex and Mail.ru. Availability of a public avatar is an additional contact-record signal only; like registration status, it is not identity verification, not proof of ownership, and not permission to reuse the image.