Published on June 15, 2026 • By Kaiju Team
An email validation workflow is the set of places and moments where you check that an address is real and deliverable — at the signup form, inside your CRM, before a campaign send, or on a nightly schedule — and the rules you apply to each result. This guide is the no-code, integration-patterns playbook: it shows you where to plug verification into the tools you already run, how to automate email validation through Zapier or Make without writing API code, and what to do with each verdict so good leads get through and junk never reaches your database.
Email addresses enter your business through a handful of doors, and every door is a chance to validate before bad data spreads. The cheapest fix is always the earliest one — an address you reject at the form never becomes a bounce, a wasted CRM record, or a deliverability problem three campaigns from now. Map your stack first, then decide which doors get a verification step.
These are the common insertion points, roughly in the order data flows through a typical go-to-market stack:
Across all those insertion points, you are really running one of four repeatable patterns. Naming them helps you decide what to build where, and whether each one should use real-time single verify or a bulk job. The table below is the cheat sheet.
| Pattern | Where it runs | Mode | Goal |
|---|---|---|---|
| Validate-on-capture | Signup / lead / checkout form | Real-time single verify | Block typos and junk before they hit the database |
| Scheduled list-clean | CRM / ESP, nightly or weekly | Bulk job | Re-verify stored contacts that decay over time |
| Pre-send verification | Just before a campaign send | Bulk job | Strip dead addresses to protect deliverability |
| Lead-routing by result | Automation / CRM on new lead | Real-time single verify | Route valid leads fast, hold risky ones for review |
Validate-on-capture and lead-routing are inline and one-address-at-a-time, so they want real-time verification. Scheduled cleans and pre-send runs touch thousands of stored rows at once, so they want a bulk job. If you are unsure which side a given workflow falls on, our deep dive on bulk vs real-time verification walks through the trade-offs in detail.
Whether you build it in Zapier, Make, or a CRM workflow tool, every no-code verification automation has the same three-part skeleton. You do not need to understand request signing or async polling to wire it up — the platform handles the HTTP call, and you just configure where the data comes from and what happens to each outcome.
The branching is the part that matters, because a verdict is only useful if your automation acts on it. The standard three-way split looks like this:
TRIGGER new lead / signup / order / row
|
v
VERIFY call KaijuVerifier verify step -> { result, did_you_mean }
|
+-- result = valid -> proceed: create/route the record normally
|
+-- result = risky -> hold for review: tag & assign, don't auto-send
|
+-- result = invalid -> if did_you_mean: apply correction & re-route
else: suppress (add to suppression list)In Zapier you implement the branch with Paths; in Make you use a Router with filter conditions on each route. The verify step itself is just an authenticated HTTP call — the actual request and response shapes, authentication, and rate-limit guidance live in the API documentation. If your automation needs to verify large lists asynchronously and be notified when the job finishes, the signed-callback mechanics are covered in our guide to webhooks and real-time validation rather than repeated here.
The form is where validate-on-capture lives, and it is the pattern with the highest return because it stops bad data at its source. When a visitor types their address, fire a single real-time verify as they leave the field or on submit. The verdict drives the form's behavior, and the goal is to be helpful, not hostile — you want to catch genuine mistakes without blocking real customers behind a false positive.
A sensible default policy for a signup or lead form:
info@-style addresses rarely convert.You can test these verdicts by hand with the interactive single email validator before you wire anything up, so you know exactly what each result looks like for the addresses your audience tends to mistype.
CRMs accumulate bad email data faster than any other system because contacts arrive from a dozen sources that never touched your validated form — imports, conference scans, integrations, and manual entry. A repeatable hygiene workflow keeps the database trustworthy. The order of operations matters: dedupe first so you do not waste verifications on duplicate rows, verify second, then tag and segment on the result.
email_status = valid | risky | invalid — then build segments on it. Mailable segments exclude invalid; a "needs review" segment captures risky and catch-all.Run this on a schedule, not just once. Mailboxes that were valid last quarter go dark as people change jobs and domains lapse, so a monthly or quarterly re-clean keeps decay from accumulating. The bulk email cleaner handles the export-verify-reimport loop through a UI if you would rather not script it, and our walkthrough on how to clean an email list covers the end-to-end process.
A verdict you collect but never act on is wasted work. Two follow-through habits turn verification from a report into a system that protects revenue and reputation.
Did-you-mean typo recovery. When a verdict comes back invalid because of a domain typo — gmial.com, hotmial.com, yaho.com — the response includes a corrected candidate. At a live form, surface it as a one-click prompt. In a back-office automation, you can auto-apply the correction and re-verify, recovering a contact that would otherwise have been suppressed outright. This single behavior rescues a meaningful slice of leads that look invalid but are really just fat-fingered.
Suppression lists. Confirmed-bad addresses should never be silently dropped and forgotten — they should be written to a suppression list so they are never mailed again, even if the same address re-enters through another source. A suppression list is the institutional memory that stops a known hard-bouncer from being re-imported next quarter and re-poisoning your metrics. The cost of skipping this step compounds; see our breakdown of the hidden cost of hard bounces for why a clean suppression list pays for itself.
| Verdict | Action | Where it lands |
|---|---|---|
| Valid | Proceed | Mailable segment |
| Invalid + did-you-mean | Apply correction, re-verify | Mailable segment if it now passes |
| Invalid (no suggestion) | Suppress | Suppression list |
| Risky / catch-all | Hold for review | Needs-review segment |
| Disposable / role | Flag per policy | Tagged, often excluded |
The same engine powers both modes, so the choice is purely about where the work sits. If the verification happens inline — a user is waiting, or a single new record just arrived — use real-time single verify so you get an immediate verdict to branch on. If the verification touches a stored list of many addresses at once — a CRM segment, an ESP audience, a spreadsheet export — use a bulk job so throughput matters more than per-address latency.
A mature stack runs both at once: validate-on-capture keeps new data clean at every form, while a scheduled bulk clean keeps the existing database fresh. Skip either one and the other source of decay eventually wins. For volume tiers and where the free tier ends, see pricing, and for the full decision framework on mode selection, read bulk vs real-time verification.
How do I add email verification to a Zapier or Make automation?
Use the same trigger-verify-branch shape in either tool. Add a "Webhooks" (Zapier) or "HTTP request" (Make) action that calls KaijuVerifier's verify endpoint with the email from your trigger, then use Zapier Paths or a Make Router to branch on the returned verdict: valid proceeds, risky goes to review, invalid is suppressed or typo-corrected. The platform makes the HTTP call for you; the request and authentication details are in the API documentation.
Can I verify emails inside HubSpot, Salesforce, or Pipedrive?
Yes, through each platform's API or by connecting them to a Zapier/Make automation that runs the verify step on contact-created and writes the result back as a property. From there you build segments and routing rules on that property. There is no native KaijuVerifier app inside those CRMs — the integration is via their API or an automation platform.
Where should I put verification in my stack first?
Start at the form with validate-on-capture, because it is the cheapest and highest-leverage point — a bad address rejected there never becomes a bounce, a wasted CRM record, or a deliverability problem. Once that is live, add a scheduled bulk clean for the data you already stored, since even a clean intake cannot fix records that decay over time.
What should I do with risky or catch-all results in an automation?
Do not hard-block them. Route them to a "needs review" tag or segment instead of either accepting them blindly or discarding them. Catch-all domains accept mail for any address, so the verdict is genuinely inconclusive rather than bad, and treating it as invalid would cost you real contacts. Reserve suppression for confirmed-invalid addresses.