DEV Community: Damiana Teliti

Give your AI assistant a real email verifier (MCP setup in 2 minutes)

Damiana Teliti — Fri, 23 Oct 2026 12:48:09 +0000

Ask an AI assistant whether an email address is real and it will answer confidently. But without a tool it can't look up the domain's mail servers or ask the mailbox whether it exists. It can only judge whether the address looks plausible, which is exactly how typos and dead mailboxes slip through.

The fix is to give the assistant a real tool. With the Model Context Protocol (MCP), Claude, Cursor and other clients can call an email verifier directly, and you get answers backed by DNS and SMTP instead of pattern matching.

Here's how to set that up in a couple of minutes, and the one design rule I think every paid MCP tool should follow. The examples use ListCheckup's MCP server (disclosure: I work on it), but the pattern applies to any verifier.

What the assistant gets

Six tools:

tool	what it does	costs credits?
`check_email`	verify one address	yes, unless catch-all or unknown
`get_balance`	remaining credits	no
`create_list`	submit a list, get a price back	no
`start_list`	start checking the list	yes, the only one
`get_list`	status and progress	no
`get_list_summary`	counts when finished	no

Setup in Claude Code

One command:

claude mcp add --transport http listcheckup https://listcheckup.com/mcp \
  --header "Authorization: Bearer lck_live_..."

Setup in Claude Desktop, Cursor and most other clients

Add this to the client's MCP config file:

{
  "mcpServers": {
    "listcheckup": {
      "url": "https://listcheckup.com/mcp",
      "headers": { "Authorization": "Bearer lck_live_..." }
    }
  }
}

To test it, ask the assistant to list its tools. Six tools means you're connected. An unauthorized error almost always means the word Bearer (and the space after it) is missing, or the key was pasted incompletely.

What you can ask

"Is jane@acme.com a real address?"
"How many credits do I have left?"
"Here's a CSV of 4,000 leads. How much would it cost to verify them?"
"Go ahead and start it, then tell me how many came back invalid."

The design rule: price first, spend second

Notice that create_list and start_list are separate tools. That's deliberate. An agent that can spend money in one step will eventually spend it when you only asked a question. Splitting "what would this cost?" from "do it" means the assistant has to show you the price, and you have a natural point to say yes or no.

If you're building an MCP server for anything that costs money, I'd copy this. Read-only and quoting tools should be free and safe to call; exactly one tool should spend.

Keep the key safe

The key sits in clear text in the config file, and anyone holding it can spend your credits. Keep that file out of shared repos, use one key per machine so you can revoke a single one, and revoke from the dashboard if a key leaks. Revocation applies to the API and the MCP server immediately.

Why catch-all and unknown are free

Some domains accept every address (catch-all), and some servers refuse to answer verification probes (unknown). No verifier can confirm those, so ListCheckup doesn't charge for them. There are also 100 free checks every month, which is plenty to try this out. Docs: listcheckup.com/api.

Are you giving your assistants tools that spend money yet? How are you handling confirmation?

How to verify emails at signup without blocking real users (Node.js)

Damiana Teliti — Fri, 23 Oct 2026 11:22:48 +0000

Most signup forms validate an email with a regex and call it done. That catches bob@@gmail but happily accepts jane@compnay.com, test@mailinator.com and ceo@a-domain-that-accepts-everything.com. A month later your welcome emails are bouncing and your sender reputation is paying for it.

Here's a small, practical pattern for checking addresses at signup without blocking real users. The code uses Node.js and the ListCheckup API (disclosure: I work on it), but the decision logic at the end applies to any verifier.

What a real check tells you

A proper verifier goes beyond syntax: it looks up the domain's MX records and asks the recipient's mail server whether the mailbox exists, without sending anything. You get back one of five answers:

status	meaning	what to do at signup
`valid`	mailbox exists	accept
`invalid`	can't receive mail	reject, ask them to fix it
`risky`	disposable or shared inbox	accept or warn, your call
`catch_all`	domain accepts every address	accept, flag for later
`unknown`	server wouldn't answer	accept, flag for later

The important part is the last two. Never block a signup on catch_all or unknown. Plenty of real companies run catch-all domains, and plenty of real mail servers refuse to answer verification probes. Rejecting those turns away paying customers.

The handler

One request per signup, answered inline:

// verify-email.js (Node 18+, no dependencies)
const API = "https://listcheckup.com/v1/verify";

export async function checkSignupEmail(email) {
  const controller = new AbortController();
  const timer = setTimeout(() => controller.abort(), 4000); // never hold up signup

  try {
    const res = await fetch(API, {
      method: "POST",
      headers: {
        Authorization: `Bearer ${process.env.LISTCHECKUP_KEY}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({ email }),
      signal: controller.signal,
    });
    if (!res.ok) return { action: "accept", reason: "verifier_unavailable" };

    const r = await res.json(); // { status, reason, confidence, ... }

    switch (r.status) {
      case "invalid":
        return { action: "reject", reason: r.reason };
      case "risky":
        return { action: "warn", reason: r.reason };
      case "catch_all":
      case "unknown":
        return { action: "accept", flag: true, reason: r.reason };
      default:
        return { action: "accept", reason: r.reason };
    }
  } catch {
    // timeout or network error: fail open, don't punish the user
    return { action: "accept", reason: "verifier_timeout" };
  } finally {
    clearTimeout(timer);
  }
}

Three design choices worth copying whatever tool you use:

Fail open. If the verifier is slow or down, accept the signup. A verification service should never be a single point of failure for your funnel.
Hard timeout. Most checks answer in well under a second, but some mail servers are slow. Four seconds is a reasonable ceiling for a form.
Store the flag. Save catch_all / unknown on the user record. You'll want it later when deciding who gets your first newsletter.

Using it in a route

app.post("/signup", async (req, res) => {
  const { email } = req.body;
  const check = await checkSignupEmail(email);

  if (check.action === "reject") {
    return res.status(422).json({
      error: "That address can't receive email. Could there be a typo?",
    });
  }

  await db.users.insert({
    email,
    email_unconfirmed: Boolean(check.flag),
    email_risky: check.action === "warn",
  });

  res.status(201).json({ ok: true });
});

Note the error message: "can't receive email, could there be a typo?" is friendlier than "invalid email", because many invalid addresses at signup are typos, not bad actors.

What about lists you already have?

Checking one address at a time is for forms. For an existing list, send the whole thing in one request, get a price back before anything is charged, then start it:

curl -X POST "https://listcheckup.com/v1/lists" \
  -H "Authorization: Bearer $LISTCHECKUP_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "old-subscribers", "emails": ["a@example.com", "b@example.com"]}'

A webhook fires when it finishes, so you don't need to poll.

The pricing detail I'd check in any verifier

Since no verifier can confirm catch_all or unknown addresses, I think you shouldn't pay for them. ListCheckup doesn't charge for those two results, and there are 100 free checks a month, which is plenty for testing a signup flow. The full API reference is at listcheckup.com/api.

How do you handle email checks at signup today: regex only, double opt-in, or a verifier?

Why catch-all email addresses can't be verified (and what to do instead)

Damiana Teliti — Thu, 22 Oct 2026 17:30:35 +0000

If you've ever run a list through an email verifier, you've probably seen a result labelled catch-all, accept-all or unknown. It's tempting to treat that as a bug in the tool. It isn't. It's a hard limit of how email works, and once you understand it you'll make better decisions about what to send to.

How verification works under the hood

A verifier never sends an email. It runs a short conversation with the recipient's mail server and stops just before the message would be delivered:

Syntax check. Is anna@example.com even a well-formed address?
DNS lookup. Does example.com publish MX records, i.e. does anything accept mail for this domain?
SMTP handshake. Connect to the mail server and say who the mail is for:

EHLO verifier.example
MAIL FROM:<probe@verifier.example>
RCPT TO:<anna@example.com>

The interesting part is the reply to RCPT TO:

250 2.1.5 OK                       -> mailbox accepted
550 5.1.1 User unknown             -> mailbox does not exist

Then the verifier sends QUIT. No message is ever transmitted. For most domains, that 250 versus 550 is a clean answer.

Where it breaks: catch-all domains

Some mail servers are configured to accept every address at the domain. Ask about a real mailbox and you get 250 OK. Ask about xk2j9q-not-a-person@example.com and you also get 250 OK.

Companies do this for legitimate reasons: so a typo in an address still reaches someone, so mail to ex-employees lands in a shared inbox, or because their security gateway accepts everything first and filters later.

From the outside, a real mailbox and an invented one now look identical. The usual detection trick is to probe a random address that almost certainly doesn't exist. If that gets 250, the domain is catch-all. But that only tells you the domain accepts everything. It tells you nothing about whether the one address you actually care about belongs to a person.

No SMTP-based check can resolve this. Any tool that confidently labels these addresses "valid" is guessing.

Other reasons you'll see "unknown"

Greylisting. The server temporarily rejects the first attempt (451 4.7.1) and expects a retry minutes later.
Rate limiting and blocks. Large providers throttle or refuse verification-style connections.
Timeouts. The server simply doesn't answer in time.

A good verifier retries some of these, but some addresses will stay undetermined, and that's the honest result.

What to do with catch-all addresses

Keep them as a separate segment. Don't mix them into your "verified" list.
Send to the most engaged ones first (people who opened or clicked recently) and watch your bounce rate.
Cap the volume. Hard bounces above roughly 2% of a send are where mailbox providers start to push back.
Use other signals. A recent reply, a signed-up account or an address you got directly from the person is worth more than any verifier result.

The pricing question

Here's the part I'd encourage you to check in whatever tool you use: do you get charged for results the tool can't actually determine? Many verifiers bill a catch-all or unknown result exactly like a confirmed one, and some count catch-alls as valid in their accuracy claims.

Disclosure: I work on ListCheckup, an EU-based email verifier. We label catch-all and unknown addresses separately and refund the credit for them, precisely because we can't honestly confirm them. There's a longer write-up on why catch-all domains can't be verified, and a 54-second video overview on YouTube.

If you've found other ways to handle catch-all segments, I'd love to hear them in the comments.