Dead mailboxes found before your ESP finds them
The probe opens a conversation with the receiving server and asks about the exact address. A mailbox that stopped existing is caught here rather than in a bounce report your provider keeps a copy of.
Validrow checks the spelling, the domain, the reputation of the provider and the mailbox itself, then hands your file back with every column where you left it and a verdict on every row.
Where the mailbox cannot be proven, the report says Unknown and names the layer that stopped. Nothing is rounded up.
| company | signed_up | status | sub_status | settled_at | |
|---|---|---|---|---|---|
| jane.doe@acme.io | Acme | 2026-01-14 | Deliverable | mailbox_confirmed | 6 |
| sales@acme.io | Acme | 2026-02-02 | Risky | role_account | 5 |
| john@gmial.com | Northwind | 2026-02-19 | Undeliverable | no_mx | 4 |
| hello@bigco.com | Bigco | 2026-03-05 | Unknown | greylisted | 6 |
Syntax through to an SMTP mailbox probe, run in that order.
Vendored into the engine, and readable line by line.
Free for the first 100 accounts. No card.
01Why the depth
It flatters the report and you pay for it in sender reputation. Validrow takes the slower path on every address and tells you exactly where it got to.
The probe opens a conversation with the receiving server and asks about the exact address. A mailbox that stopped existing is caught here rather than in a bounce report your provider keeps a copy of.
The large providers accept almost any recipient at the door and bounce it later. Validrow knows which ones do this and refuses to report a confident Deliverable on an acceptance that means nothing.
One probe per domain settles whether the server accepts everything. If it does, its addresses come back Risky with the reason attached, so you can decide instead of guessing.
A typo on a live domain returns a correction your team can act on. The row stays in the file with the suggestion beside it rather than disappearing into a removed pile.
Dots and plus tags are the same mailbox wearing different spellings. They collapse to one key, so a list is reported per person rather than per variation.
Every verdict carries the layer that produced it and the sub-reason under that. A row you took out can be explained to whoever asks why the list shrank.
02The layers
Each layer can settle an address on its own, and an address that is settled early never reaches the expensive ones. That is why a million rows finish without a million SMTP connections.
RFC 5322 parsing, plus the length and character limits the RFC leaves to the implementation. A malformed address never costs a network call.
Gmail dots and plus tags collapse to one key, so a person is counted once however their address was typed.
A misspelled domain returns a suggestion rather than a deletion, and the row keeps its place in your file.
Resolved once per domain and cached for the run, so a million rows are not a million lookups.
Role accounts, free providers and 8,720 disposable domains, from lists that ship inside the engine and can be read line by line.
EHLO, MAIL FROM, RCPT, QUIT, and never DATA. The receiving server answers for the exact address, and nothing is delivered to your list.
One probe per domain. A domain that accepts every recipient has proven nothing, so its addresses come back Risky rather than Deliverable.
03The trace
Open any address and you see how far down the pipeline it travelled and what stopped it there. A verdict you can question is a verdict you can trust.
Settled at layer 6, SMTP mailbox probe. The receiving server answered for this mailbox.
Settled at layer 5, Classification. A role account. Real, but nobody in particular.
Settled at layer 4, DNS and MX. The domain has no MX. Suggested john@gmail.com.
Settled at layer 6, SMTP mailbox probe. The server deferred the probe. Queued for a retry.
04Verdicts
The mailbox was probed and the receiving server answered for it.
Real, but not a clean send. A role account, or a catch-all domain whose acceptance settles nothing.
Greylisting, a timeout, or a provider that will not answer honestly. Retried on a schedule, and never rounded up to Deliverable.
Invalid syntax, no MX, a disposable domain, or a mailbox the server rejected outright.
| Deliverable | 2,946 | 61% |
| Risky | 613 | 13% |
| Unknown | 722 | 15% |
| Undeliverable | 531 | 11% |
Unknown is its own column, not a rounding error hidden inside the valid count.
05What comes back
Every row you uploaded, every column kept, with the verdict, sub-reason, score and normalised address appended.
The rows worth sending to, and nothing else.
What came out, with the layer and the reason each row came out.
Validrow only needs to know which column holds the email. Everything else in the file is carried through untouched, down to the delimiter and the line endings you uploaded with.
06API
Verify a single address while a form is still open, or push a file through the bulk pipeline and poll it. Create a key in Settings; it is shown once.
Read the API docs$ curl -s https://validrow.inboxrow.com/v1/verify \ -H "X-API-Key: eve_..." \ -d '{"email":"john@gmial.com"}' { "status": "undeliverable", "sub_status": "no_mx", "suggested_correction": "john@gmail.com", "settled_at_layer": 4 }
07Pricing
10,000 addresses a month, every month, through all seven layers. The same engine, the same probe, the same file back.
No card, and no clock counting down a trial.