# List verification by EmailPal

> EmailPal verifies addresses before you send so catch-alls and disabled mailboxes do not become bounces on a warmed IP. Six verdicts, SMTP probes that never deliver a message, daily allowances on every plan, and the same engine on the dashboard, REST and MCP.

Source: https://emailpal.io/help/list-verification-by-emailpal

## What is list verification?

List verification is the check you run **before** a campaign so you are not paying for bounces with reputation. A bounce is not only a wasted send. Inbox providers treat a rising bounce rate as a sign the sender does not know who they are mailing. A 4% bounce rate will undo warmup.

Most verifiers ask the receiving server "does this mailbox exist?" and call a `yes` **valid**. That works on well-behaved domains. It fails on **catch-alls**: domains that accept mail to any local-part, invented or not. Those later bounce, sit in a bit bucket, or generate complaints — after your mailbox has already spent the send.

EmailPal's distinctive check: we ask the receiving server about a mailbox that **cannot exist**, then interpret what it says about your real contact. If the fake address is accepted, the domain is a catch-all and a "valid" on the real address does not mean what you think.

Nothing is delivered. The probe is `RCPT TO` only. No DATA, no message, no inbox notification from us.

This is included on every paid plan. You do not need a second vendor for the first pass.

## What EmailPal verification is

The engine returns **six verdicts**, not two:

| Verdict | Meaning | Send? |
| --- | --- | --- |
| Valid | The server rejected an impossible mailbox, then accepted yours. Deliverable. | Yes |
| Catch-all | The domain accepts anything. Your contact is not confirmed. | Risky — your call |
| Unknown | Greylist, timeout, or a server that will not hold a conversation. Never rounded up to valid. | Treat as unverified |
| Role | `info@`, `support@`, `sales@` — a function, not a person. | Often skip |
| Full mailbox | Exists, cannot take mail right now. Sending creates a bounce later. | No |
| Disabled | The mailbox is gone or switched off. | No |

A longer walkthrough of each row: [Six verification verdicts](/help/six-verification-verdicts). The catch-all probe itself: [Catch-all detection](/help/catch-all-detection) and [What is a catch-all email?](/help/what-is-a-catch-all-email).

Other properties of the product:

- **One probe per domain, cached a day.** We do not hammer the same MX with a unique impossible mailbox for every row in your CSV.
- **Dashboard, REST and MCP use the same engine.** Paste a file, `POST /api/public/v1/verify` a single address, or `verify_list` from an agent.
- **Unknown stays unknown.** A greylist deferral is not a valid. Rounding it up is how other tools invent a clean rate.

## Pricing and allowances

Verification is included on every plan, with a daily instant-check allowance:

| Plan | Instant checks / day | Typical use |
| --- | --- | --- |
| Starter ($69) | 500 | One company getting outbound off the ground |
| Growth ($189) | 1,500 | Agencies and teams running several books |
| Scale ($499) | 4,500 | High-volume senders |

Extra capacity is sold in blocks of **500 checks/day per month**. Upload verification and API/MCP use the same pool.

There is no separate "list cleaning" SKU. The product page is [List verification](/products/list-verification).

## Why use it

- Catch-alls look valid until they are not. The impossible-mailbox probe is the only cheap way to tell them apart before you send.
- Disabled and full mailboxes become hard bounces on your warmed IP if you skip this step.
- Role addresses collect spam complaints because they are shared and often filtered.
- Pre-warmed leases and freshly warmed mailboxes both die the same way: a dirty list. The 15/day or 40/day cap does not protect you from a 4% bounce rate.

If you only remember one line: **do not put an unverified CSV on a mailbox that just became campaign-ready.**

## How to run a list

### From the dashboard

1. Sign in. Open **Lists**.
2. Upload a CSV or paste addresses.
3. Wait for verdicts. Catch-alls are the ones to drop or handle differently.
4. Send only what you are willing to put on a warmed mailbox. Most teams send `valid` only. Some also accept `unknown` at lower volume.

The same check can run on upload at send time where the dashboard offers it, so a list that skipped Lists still gets probed.

### Over the API

Authenticate with an API key as documented in the [API reference](/docs).

- `POST /api/public/v1/verify` — a single address, answered synchronously. Use this in a signup form or CRM import.
- List endpoints for bulk jobs — same six verdicts, same catch-all probe.

### Over MCP

The `verify_list` tool on `@emailpal/mcp` is the same verifier. An agent can clean a list as one step in a longer job without you writing the glue. See [Connect the MCP server](/help/connect-the-mcp-server).

A step-by-step of the operator flow: [How to verify an email list before sending](/help/how-to-verify-an-email-list-before-sending).

## What to do with each verdict

- **Valid** — send. This is the only row where SMTP evidence says the mailbox exists and the domain is not a catch-all.
- **Catch-all** — drop, or mail at much lower volume if you have another reason to believe the person is real (LinkedIn match, recent reply). Do not treat the verifier's `yes` as confirmation.
- **Unknown** — the server would not say. Do not round up. Re-try later, or skip.
- **Role** — skip for cold email unless that function is literally the buyer. Shared inboxes complain more.
- **Full mailbox / Disabled** — never send. You already know the bounce.

## FAQs

### Does verification send an email to the prospect?

No. No DATA, no message, no inbox notification from us. The probe is `RCPT TO` only.

### Why not trust a "valid" from another vendor?

If they skipped the impossible-mailbox probe, catch-alls look valid. Those bounce later, on your reputation, not theirs.

### Is this available in the free trial / before a plan?

Daily allowances ride on the paid plans (Starter, Growth, Scale). There is no separate verification SKU to trial.

### Should I re-verify every week?

Re-verify after a few months, or any time you bought a new list. Fresh-looking CSVs still go stale — people leave, mailboxes fill, domains become catch-alls.

### A whole domain came back unknown.

That is often a server that greylists probes, not a bug in your CSV. [Open a ticket](/support/new) with the domain. Do not send the list "because unknown might be fine."

### Does this replace warmup?

No. Verification protects the list. Warmup (or a [pre-warmed lease](/help/pre-warmed-inboxes-by-emailpal)) protects the mailbox. You need both. See the [cold email deliverability guide](/help/cold-email-deliverability-guide).

### Can I verify addresses I will send from Instantly or Smartlead?

Yes. EmailPal is the infrastructure. Verify here, send there. The sequencer does not have to be ours.

## Need More Help?

[How to verify an email list before sending](/help/how-to-verify-an-email-list-before-sending) for the click-path, or [open a ticket](/support/new) if a whole domain comes back unknown.