> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://gtm-tools.sh/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://gtm-tools.sh/_mcp/server.

# Why is get_email returning not_found?

> get_email returns a reason on every non-ok result. What catch_all, no_mx, unverifiable_provider, no_pattern_verified, smtp_blocked and prober_rejected each mean, and what to do about them.

`get_email` has exactly three outcomes: `ok` with a verified address, `not_found`, or `try_again_later`. A `not_found` doesn't mean the tool gave up early. It means the tool did the work and can't hand you an address it believes in.

The useful part is the `reason` field, present on every non-`ok` result. It tells you whether the person has no mailbox, whether they probably do but the server won't confirm it, or whether the domain itself is the obstacle.

## What the reason field tells you

```json
{
  "email": null,
  "status": "not_found",
  "reason": "catch_all",
  "domain": "acme.com"
}
```

| Reason                                                | Does an address likely exist? | Retry?                                    |
| ----------------------------------------------------- | ----------------------------- | ----------------------------------------- |
| `catch_all`                                           | Probably, but unprovable      | No                                        |
| `no_mx`                                               | No                            | No                                        |
| `unverifiable_provider`                               | Probably                      | No                                        |
| `no_pattern_verified`                                 | Probably not                  | No                                        |
| `smtp_blocked`                                        | Unknown                       | Not automatically                         |
| `prober_rejected`                                     | Probably                      | Not automatically                         |
| `smtp_unavailable`, `google_cooldown`, `ms_throttled` | Unknown                       | Yes, these come back as `try_again_later` |

None of the `not_found` reasons get better by calling again with the same input. Each retry is charged and returns the same answer.

## catch_all

The domain accepts mail for every recipient, so `first@`, `flast@`, and `nonsense123@` all pass verification. There's no way to confirm one specific mailbox, and returning a guess as "verified" would be lying.

**What to do:** treat the most-likely pattern as a hypothesis, not a fact. If you have another signal for the same person (a LinkedIn profile confirming they still work there), the pattern is usually right: send to it, and let the bounce be your verification. Don't feed catch-all guesses into a large send without warming.

## no_mx

The domain publishes no mail server, so no mailbox at that domain can exist. Common causes: a parked or acquired domain, a marketing-only domain that never handled mail, or a typo in the domain you passed.

**What to do:** check the domain. If the company was acquired, the person's mail probably lives on the parent's domain, so retry with that instead.

## unverifiable_provider

The mail provider blocks verification: an enterprise gateway (Proofpoint, Mimecast), an on-prem server configured to refuse enumeration, or a provider that accepts-then-drops. An address very likely exists; we just can't prove it.

**What to do:** this is the case where a second enrichment source earns its money. If you only have us, fall back to the dominant pattern for that company and accept the risk.

## no_pattern_verified

The server does distinguish between real and fake recipients, so verification works there, and none of the common patterns were deliverable. That's a meaningful negative: this person most likely has no mailbox on this domain.

**What to do:** believe it. Check whether they've changed employer with `get_linkedin_profile`, or whether the company uses a different mail domain than its website domain.

## smtp_blocked

We couldn't open an SMTP conversation at all: the port was blocked, or the receiving side dropped our connection before any recipient check happened. Distinct from `smtp_unavailable`, which is transient and surfaces as `try_again_later`.

**What to do:** it's not your call pattern and it's not the person. If a whole batch of domains returns this at once, [tell us](/support). That pattern usually points at something on our egress rather than at the domains.

## prober_rejected

The mail server answered, then refused our verifier rather than the address: it judged the IP we probe from (a blocklist listing such as Spamhaus, or missing reverse DNS). Nothing about the person or the pattern was tested, and calling again from the same egress gets the same refusal, so it comes back as `not_found` instead of `try_again_later`.

**What to do:** treat it like `unverifiable_provider`: an address very likely exists. If a large share of a batch returns it, [tell us](/support), because it is about our egress, not your domains.

## Still stuck

* Verify the input first. `get_email` needs a first **and** last name; a single credit returns an error rather than a lookup.
* Pass `linkedin_url` when you have it. It lets the lookup use the profile as a second signal and populates the cache under a stable key.
* Cache your own results. Verified addresses are stable for weeks, and re-asking costs 5 credits each time.
* For the transient case, see [Why did I get try_again_later?](/knowledge-base/troubleshooting/try-again-later).