# Six verification verdicts

> What valid, catch-all, unknown, role, full mailbox and disabled mean on an EmailPal verification result — and whether you should send to each one.

Source: https://emailpal.io/help/six-verification-verdicts

## The six answers

EmailPal does not reduce a list to valid vs invalid. A catch-all is not valid. A greylist is not valid. A full mailbox is not "try again as valid." Each row gets its own verdict so you can make a policy instead of guessing.

| Verdict | What we learned | Send? |
| --- | --- | --- |
| Valid | The server rejected an impossible mailbox, then accepted this one. | Yes |
| Catch-all | The domain accepts anything, invented or not. | Risky — do not treat as confirmed |
| Unknown | Greylist, timeout, or a server that will not talk. Never rounded up. | Unverified — skip or retry |
| Role | A function (`info@`, `support@`, `sales@`), not a person. | Usually skip for cold email |
| Full mailbox | Exists, cannot receive now. | No — bounce waiting to happen |
| Disabled | Gone or switched off. | No |

The product that produces these rows: [List verification by EmailPal](/help/list-verification-by-emailpal). How to run a CSV: [How to verify an email list before sending](/help/how-to-verify-an-email-list-before-sending).

## Valid

The distinctive check ran. We asked about a mailbox that cannot exist; the server said no. We asked about your contact; the server said yes. That yes means something.

Valid is the only row where SMTP evidence says "this mailbox exists and the domain is not a catch-all." Send these from a [campaign-ready](/help/when-is-a-mailbox-ready-to-send) mailbox or a pre-warmed lease.

## Catch-all

The domain said yes to a mailbox that cannot exist. Your contact's `yes` carries no information. They might be real. A typo might also be "accepted."

[What is a catch-all email?](/help/what-is-a-catch-all-email) and [Catch-all detection](/help/catch-all-detection).

Many teams drop every catch-all. Some mail a subset that matched LinkedIn or a recent reply, at lower volume. Either is a policy. Calling them valid is how bounce rates show up a week later.

## Unknown

The server greylisted the probe, timed out, or refused to hold the conversation. Unknown stays unknown. We will not invent a clean rate by rounding it up.

Retry later, or skip. A whole domain of unknowns is often greylisting, not a broken CSV. [Open a ticket](/support/new) with the domain rather than blasting the list.

## Role

`info@`, `hello@`, `support@`, `sales@`, `admin@` — addresses that belong to a function. Shared inboxes, more readers, more likely to be filtered, more likely to complain.

Role is not "invalid." It is a different kind of risk. Skip for cold email unless that function is literally the buyer.

## Full mailbox

The mailbox exists and cannot take mail right now. Sending today creates a bounce tomorrow, on your reputation. Wait and re-verify, or drop the row.

## Disabled

The account is gone or switched off. There is no version of a campaign where this address should be sent to.

## FAQs

### Why is a real person at a catch-all company marked catch-all?

Because we cannot distinguish them from a typo. The domain said yes to a mailbox that cannot exist. The honest label is catch-all.

### Is role always bad?

It is a different kind of risk: one inbox, many readers, more likely to be filtered or to trigger a complaint. Not the same as disabled.

### Can a valid become disabled later?

Yes. Lists go stale. Re-verify after a few months or whenever you buy a new file.

### Do Instantly / Smartlead use the same six labels?

No. Their verifiers have their own taxonomies. EmailPal will not map their "valid" onto ours if they skipped the impossible-mailbox probe.

## Need More Help?

[List verification by EmailPal](/help/list-verification-by-emailpal).