Reference
Every verdict, explained.
Four statuses, fifteen reason codes and a 0 to 100 score. This page says what each one means, why it happened and what to do with the address before your next send.
Statuses
The four statuses
Deliverable
Safe to send. The mailbox exists and accepts mail.
What to do: Send. Keep the address in your list and your automations.
Typical share: Around 70 to 85% of a healthy list.
Undeliverable
Do not send. Mail to this address will bounce.
What to do: Remove or suppress before sending. Every one of these is a guaranteed hard bounce.
Typical share: 5 to 20% of a list that has not been cleaned in a year.
Risky
Might deliver, might bounce. Send with care or suppress.
What to do: Decide by segment: send to catch-all business domains you have a relationship with, suppress disposable inboxes, and keep role addresses out of nurture flows.
Typical share: 5 to 15%, mostly catch-all domains.
Unknown
The mail server would not confirm either way. Re-check later.
What to do: Do not treat as bad. Re-check in a few hours (greylisting clears) or send a low-volume warm-up to these first.
Typical share: Under 5%; higher on lists heavy with Yahoo or self-hosted domains.
Reason codes
Why an address got its *status*
The reason field is stable and safe to branch on; reason_text is the sentence below, safe to show to people.
Deliverablereasons that produce this status
The mail server confirmed this mailbox exists and accepts mail.
Nothing to do. The mailbox answered 250 OK to RCPT TO.
Undeliverablereasons that produce this status
This is not a correctly formed email address.
Fix the capture point: the address broke RFC 5321 rules (a space, a missing @, two dots). Never charged.
The domain does not exist or has no mail configuration.
Remove. The domain does not exist in DNS; check did_you_mean for the intended one.
The domain has no mail servers (no MX records).
Remove. The domain exists but publishes no mail servers, so nothing can deliver to it.
The mail server says there is no mailbox with this name.
Remove. The server replied 550 5.1.1 (no such user). The classic hard bounce.
The mailbox has been disabled or suspended by its provider.
Remove. The provider has disabled or suspended the account.
The domain looks like a misspelling of a well-known provider.
Offer the correction in did_you_mean (gmai.com becomes gmail.com). The widget does this automatically.
Riskyreasons that produce this status
The mailbox exists but is over quota; mail will bounce until it is cleared.
Keep but do not send now. Over-quota mailboxes bounce until cleared; re-check in a week.
This domain hands out temporary, throw-away inboxes.
Suppress from marketing. The domain hands out throw-away inboxes (10-minute mail and friends); block at sign-up with the widget.
A role address (info@, support@) belongs to a function, not a person; engagement is low and complaints are common.
Keep out of personal nurture flows. info@, support@ and sales@ reach a function, not a person, and complain more often.
The domain accepts mail for any name, so the mailbox cannot be confirmed individually.
Send with care. The domain accepts every name, so the mailbox cannot be confirmed; the score reflects SPF/DMARC hygiene. Prefer addresses with recent engagement.
Unknownreasons that produce this status
The server asked us to try again later (greylisting). Re-check in a few hours.
Re-check in 1 to 4 hours. The server asked us to try later; a second attempt usually gets a definitive answer.
The mail server did not allow a verification handshake from here.
Re-check later or use engagement data. The mail server refused a verification handshake from any outside host.
The mail server gave an unexpected reply.
Re-check. The server gave an unexpected reply mid-conversation.
This provider does not reveal whether individual mailboxes exist.
Rely on the other signals. Some providers never reveal whether a mailbox exists; the syntax, MX, SPF and DMARC checks still ran.
Score
The 0 to 100 *score*
The score is our confidence that mail will land. It is not a probability model trained on bounces; it is a deterministic reading of what the mail server said, adjusted for catch-all behaviour, role accounts and the domain's SPF and DMARC hygiene. Two checks of the same address give the same score.
A sensible default for marketing sends is to mail everything at 60 and above, suppress everything under 30, and treat the middle as a segment to warm carefully. Transactional mail (receipts, password resets) should go to anything that is not undeliverable.
Send. The mailbox was confirmed by its own mail server.
Send with care: catch-all domains, role accounts and providers that hide mailbox status land here.
Re-check later or suppress: greylisting, blocked handshakes and full mailboxes.
Do not send. Disposable inboxes, dead domains and mailboxes the server rejected.