> ## Documentation Index
> Fetch the complete documentation index at: https://help.pipelime.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Email Verification: verdicts and what they mean

> Deliverable, undeliverable, catch-all and inconclusive: how each verdict is reached and what the product does with it.

export const Screenshot = ({id, alt, caption, frame = 'browser', url, marks = [], lang = 'en', workspace = 'northwind-outbound'}) => {
  const src = `/images/screenshots/${lang}/${id}.png`;
  const chrome = url ? `app.pipelime.ai/${workspace}${url}` : 'app.pipelime.ai';
  return <figure className={`pl-shot pl-shot--${frame} not-prose`}>
      <div className="pl-shot__frame">
        {frame !== 'bare' && <div className="pl-shot__bar">
            <span className="pl-shot__dots">
              <span className="pl-shot__dot" />
              <span className="pl-shot__dot" />
              <span className="pl-shot__dot" />
            </span>
            <span className="pl-shot__url">{chrome}</span>
          </div>}
        <div className="pl-shot__media">
          <img src={src} alt={alt} loading="lazy" />
          {marks.map(mark => <span key={mark.n} className="pl-shot__mark" style={{
    left: `${mark.x}%`,
    top: `${mark.y}%`
  }} aria-hidden="true">
              {mark.n}
            </span>)}
        </div>
      </div>
      {caption && <figcaption className="pl-shot__caption">{caption}</figcaption>}
    </figure>;
};

Email verification checks whether an address can actually receive mail before we send to it. A lead only ever shows you one of three outcomes (verified, failed, or inconclusive), but the check behind that word reasons through five, and the five are what decide what happens to the lead.

<div className="pl-availability">
  <div className="pl-availability__row">
    <div className="pl-availability__label">Where</div>
    <div className="pl-availability__value"><span className="pl-path">Leads<span className="pl-path__sep">→</span>Prospects</span></div>
  </div>

  <div className="pl-availability__row">
    <div className="pl-availability__label">Your role needs</div>
    <div className="pl-availability__value">Read access to Prospects <code>read-leads</code>. Admin, Member and Viewer have it by default.</div>
  </div>

  <div className="pl-availability__row">
    <div className="pl-availability__label">To create or change</div>
    <div className="pl-availability__value"><code>create-leads</code> to add one, <code>update-leads</code> to change one, on top of the permission above.</div>
  </div>

  <div className="pl-availability__note">If you cannot find this in your sidebar, your workspace may have a custom menu configuration. Contact support and we will check it for you.</div>
</div>

<Screenshot id="email-accounts/email-verification--lead-badges" url="/leads/prospects" alt="Three rows on the Prospects list: one with a small green verified badge next to its email, one with a red failed icon, and one still showing the outlined Verify button because nothing has been checked yet" caption="Whatever the check decided underneath, this is the entire vocabulary a lead row ever shows you." />

## How it behaves

### Two engines, and when the second one runs

When an address is checked, the in-house verifier answers first: a live handshake with the receiving mail server. It comes back with one of four readings (deliverable, undeliverable, risky, or unknown), which become one of five verdicts: `ok`, `invalid`, `disposable`, `catch_all`, or `unknown`.

Not every address is checked. During lead generation, an address that arrives already reported as verified by the source it came from is stored as verified without a probe. Everything else gets one.

Only an `unknown` goes further. When the first check can't get a clean answer (the receiving server greylisted the probe, blocked the connection outright, or the check timed out), we ask our data provider to break the tie, so the second engine is spent on the genuinely hard cases only.

That tiebreak runs only from the product's own queued work. A check you start yourself settles for inconclusive instead: press **Verify** on a row and an unknown stays unknown. The same address, checked again later by a background job, can still come back verified or failed.

### Five verdicts, three words you actually see

| You see      | Called       | Why                                                                                                         | What's saved                   |
| ------------ | ------------ | ----------------------------------------------------------------------------------------------------------- | ------------------------------ |
| verified     | `ok`         | The receiving server accepted the address                                                                   | The address is marked verified |
| failed       | `invalid`    | The receiving server rejected it                                                                            | The address is marked failed   |
| failed       | `disposable` | Undeliverable, and from a disposable-address provider                                                       | The address is marked failed   |
| inconclusive | `catch_all`  | The domain accepts mail for any address, or the mailbox reported itself full. Either way, nothing is proven | Nothing                        |
| inconclusive | `unknown`    | Greylisted, blocked, or timed out, with no tiebreak available                                               | Nothing                        |

`catch_all` and `unknown` look identical to you: nothing is written against the address, so it stays usable (we don't stop sending to it), and the row keeps offering to check it again.

A lead whose address comes back verified is also marked chargeable: the flag that decides whether it counts against your credits. The check itself never spends one; [what consumes credits](/en/billing/what-consumes-credits) has the whole rule.

### A recent verdict for the same address is reused

Before probing, we look for the same address on another record that was verified or failed in the last 30 days, and reuse that verdict instead of checking again. This applies everywhere a check happens, including the **Verify** button, which is why a check sometimes comes back instantly.

Only verified and failed are reusable. An inconclusive result is never stored, so it is never reused, and the next check starts from scratch.

### Running a check by hand needs permission to change leads

The **Verify** button only appears for a role that can update leads. Without that permission you still see the green badge and the red icon, but nothing to press: the failed icon's tooltip drops its "Click to verify again" half, and clicking it does nothing.

Both markers are tooltips: "Email verified" on the badge, "Email verification failed. Click to verify again." on the icon. The result of a check you run arrives as a notification: "Email verification result: verified", "Email verification result: failed", or "Email verification was inconclusive — the address stays unverified".

### In a workflow, the same five verdicts become three branches

Add a Verify Email block to a canvas and it hands you three branches instead of a word: Valid, Risky and Invalid. `ok` becomes Valid, `invalid` and `disposable` both become Invalid, and `catch_all` and `unknown` both become Risky rather than stalling it, because a flow has to send a lead down some path. A check that fails outright also resumes down Risky, and a lead with no email address at all goes straight down Invalid without a check.

<Screenshot id="email-accounts/email-verification--workflow-branches" url="/workflows/2" alt="The Verify Email block on a workflow canvas, with three labelled branch handles: Valid in green, Risky in amber, and Invalid in red" caption="This is the only screen that shows the full vocabulary at once. Everywhere else, an inconclusive check just looks unverified." />

### Repeated failures stop the digging at one company

Lead generation works through a company's people one at a time. If the addresses found at one company keep failing, trying every remaining name there spends lookups on a domain that is probably dead. After 3 consecutive failed verifications at a company, the remaining candidates there are not looked up: each one ends in error instead. One address that comes back verified clears the streak, and inconclusive results neither count towards it nor clear it.

The count is scoped to that one company (not the domain in general, not your whole workspace), and it expires 7 days after the first failure in the streak. Only failures from lead generation feed it; a bounce during sending does not.

### A stale "verified" gets checked again before a send

Before a campaign email goes out (first outreach, follow-up or reply), we check the recipient again if it wasn't confirmed verified in the last two weeks, unless the lead has already sent a genuine reply on some channel, which proves the address is live. This only applies when the recipient is the lead's most recent address.

If that check comes back failed, the lead is closed and the message doesn't go out: the same path a bounce takes, which for progressive lead generation moves on to the next person at the company. An inconclusive result doesn't stop anything: the send goes ahead as planned.

## Limits

|                                                     |                                                                                                          |
| --------------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| Checked first                                       | The in-house verifier, on every address that gets checked at all                                         |
| Second engine                                       | Our data provider, only on an unknown result, and only from queued work, never from a check you start    |
| Verdicts that get saved                             | verified and failed only; inconclusive writes nothing                                                    |
| A verified or failed result is reused for           | 30 days, for the same address on another record                                                          |
| Consecutive failures that stop lookups at a company | 3                                                                                                        |
| That count expires                                  | 7 days after the first failure in the streak, or as soon as one address there verifies                   |
| Checked again before a send                         | Any recipient not confirmed verified in the last two weeks, unless the lead has already replied for real |
| Workflow branches                                   | Valid, Risky, Invalid: catch-all and unknown both land on Risky                                          |

## Related

<CardGroup cols={2}>
  <Card title="Verify a lead's email address" icon="circle-check" href="/en/leads/verify-an-email-address">
    The Verify button itself, step by step.
  </Card>

  <Card title="Find & Enrich blocks" icon="shield" href="/en/workflows/find-and-enrich-blocks">
    The Verify Email block alongside Find Phone, Find Email and Company.
  </Card>

  <Card title="Email verification was inconclusive" icon="circle-question-mark" href="/en/troubleshooting/email-verification-inconclusive">
    Why the same address can keep asking to be checked.
  </Card>

  <Card title="Leads troubleshooting" icon="wrench" href="/en/leads/troubleshooting">
    Including leads that end in error and leads that close on their own.
  </Card>
</CardGroup>