Compared
Real-time vs. bulk verification
The same checks and the same four verdicts, in two shapes. Real-time answers one address while somebody waits; bulk works through a list you already have.
| What you want to know | Real-time | Bulk |
|---|---|---|
| When the question is asked | At the moment of entry, before the record exists | After the list exists, usually before a send |
| Who is waiting | A person, looking at your form | Nobody |
| What a slow domain costs | A form that waits — so it answers unknown instead | Nothing. The job simply takes longer |
| The verdicts you get | The same four, with the same evidence | The same four, with the same evidence |
| How it is used | One API request per address | A file uploaded and worked through |
| What it is for | Keeping bad addresses out of the list | Getting bad addresses out of the list |
This is a choice about when you ask, not about what you get. Both run the same stages against the same infrastructure and return the same vocabulary, and an address checked either way gets the same verdict for the same reasons.
What differs is who is waiting. In a signup form somebody is looking at a spinner, so latency is the constraint that shapes everything: a domain that greylists cannot be resolved inside a request that a person is sitting through, and the honest answer within a reasonable time is unknown. Design for that. An address that comes back unknown at the point of entry is not a reason to block the signup — it is a reason to accept it and check again later.
In a bulk run nobody is waiting, so the same slow domain costs nothing. The job takes as long as it takes and every address gets the fullest answer available.
Most teams that use both use them for what they are: real-time at the point of collection, so bad addresses never enter the list, and bulk before a send, because an address verified eight months ago is not a fact about today.
Where this shows up in a result
Reason codes from the closed vocabulary in the API response. These are the exact strings an integration writes an if against.
SMTP_GREYLISTED | Greylisted, a retry is required |
SMTP_CONNECT_TIMEOUT | Mail server did not answer in time |
Run one and see the difference.
The free checker returns the whole result — every stage, every reason code, nothing held back.