Why is get_email returning not_found?

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

1
{
2
  "email": null,
3
  "status": "not_found",
4
  "reason": "catch_all",
5
  "domain": "acme.com"
6
}

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. That pattern usually points at something on our egress rather than at the domains.

Still stuck

• Verify the input first. get_email needs a first and last name; a single token 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 tokens each time.
• For the transient case, see Why did I get try_again_later?.