Validate Emails in Any App with Zapier

Zapier email validation takes exactly one extra step in any Zap: a Webhooks by Zapier POST to the check endpoint, followed by a Filter that only continues when the returned action is allow. The recipe works with any trigger that produces an email address, Typeform entries, Mailchimp subscribers, new Google Sheets rows, and it means every tool downstream of the Zap only ever sees addresses worth keeping. This is a recipe piece: the core Zap first, then the two variants that handle warns and relays properly.

The reason to bother is supply. As of the September 2026 State of Disposable Email report, the dataset behind this check tracked 217,847 disposable domains, with 10,223 new ones arriving in a single 36 day window, and 9,971 of those new domains live and deliverable on report day. Throwaways pass format checks because they are real mailboxes on signup day; the damage comes later, when the dead ones hard bounce in a batch and your email platform opens a list quality review. Filtering them before they reach your tools is the whole game, and Zapier sits in exactly the right place to do it.

How do you verify an email address in a Zap?

Build the core recipe once and copy it everywhere. Five steps, with the exact configuration:

1. Trigger: your signup source. Typeform (New Entry), Mailchimp (New Subscriber), and Google Sheets (New Spreadsheet Row) all work identically; anything that outputs an email field qualifies.
2. Action: Webhooks by Zapier, event POST. URL: https://api.isitdisposable.com/v1/check. Payload Type: json. Data: one row with the key email and the value mapped to the trigger's email field. Wrap Request In Array: No. Headers: one row with the key Authorization and the value Bearer sk_live_your_secret_key, using your secret key, which is safe here because the request runs from Zapier's servers, never a browser.
3. Test the step. Zapier sends a real request and pulls the response fields into the editor so later steps can map them.
4. Filter by Zapier: Only continue if Action (Text) Exactly matches allow.
5. Destination: your original action, adding the contact to your CRM, list, or sheet, exactly as it was before the check existed.

One practitioner note on step 4 before you ship it. Under the default policy, relay addresses like Apple Hide My Email come back as warn, not allow, so the strict filter above holds them back along with everything else that is not a clean pass. If you run only this one Zap, change the filter to Action Does not exactly match block, which lets allow and warn through and drops only confirmed throwaways. If you want the stricter gate, keep Exactly matches allow and add the two variant recipes below, so warns get reviewed and relays get kept.

Which response fields can you map in later steps?

The webhook step returns the full verdict as mappable fields. The four you will actually use:

Field	Type	What it tells you
action	text: allow, warn, or block	The combined verdict, with your dashboard policy already applied
disposable	true or false	Whether the domain is a confirmed throwaway
relay	true or false	Whether this is a relay or alias service forwarding to a real inbox
reason	short text code	Why the verdict landed where it did, useful in review sheets

Filter on action and let the rest ride along as annotations: a review row that carries reason and disposable next to the address answers most questions before anyone asks them.

How do you route warn results to a review sheet?

Duplicate the core Zap and change two things: the Filter becomes Action Exactly matches warn, and the destination becomes Google Sheets, Create Spreadsheet Row, mapping the email plus the action, reason, and relay fields alongside it. Now soft signals get human eyes instead of a silent drop, which matters because warn is deliberately the category of "off, but plausibly legitimate." A weekly skim of that sheet takes five minutes and teaches you more about your signup traffic than any dashboard.

How do you tag relay contacts instead of filtering them?

Never filter relays out. A relay address, Apple Hide My Email, Firefox Relay, SimpleLogin, addy.io, DuckDuckGo Email Protection, a Proton alias, forwards to a real person's permanent inbox, and the person behind it is a privacy-conscious, frequently paying customer. The recipe: duplicate the core Zap, set the Filter to Relay (Boolean) Is true, and make the destination your list tool's add-or-update action with a relay tag, Mailchimp's Add/Update Subscriber with a tag does this in one step. Tagged, kept, and never blocked, which is the stance the whole product takes; the reasoning is in the relay section of The Complete Guide to Disposable Email Detection, and it is the link to send anyone who suggests treating relays as throwaways.

Does the same recipe work in Make and n8n?

Identically, because it is just a zapier webhook api pattern with nothing Zapier-specific in it. In Make, use the HTTP module's Make a Request with the same URL, the same Authorization header, and a JSON body of {"email": ...}, then a router filtered on the action field. In n8n, the HTTP Request node plus an IF node on action does the same job. Same endpoint, same verdict, same three branches, whatever the orchestrator.

What does each recipe prevent?

Recipe	Trigger app example	What it prevents
Gate new signups on allow	Typeform	Throwaways ever reaching your CRM, list, or downstream tools
Route warns to a review sheet	Any signup trigger, into Google Sheets	Soft signals being silently dropped instead of reviewed
Tag relay contacts	Mailchimp	Privacy-conscious real customers being mistaken for throwaways

Run the first everywhere, and add the second and third wherever the list behind the Zap actually matters.

What does the check cost in Zapier tasks?

One task per checked signup, and it is worth being straight about the platform economics. The webhook step consumes a task each time it runs; the Filter step is free, and your destination action was already costing a task before the check existed. Note also that Webhooks by Zapier is a premium app and this is a multi-step Zap, both of which sit on Zapier's paid plans under current pricing, so budget for that rather than discovering it at publish time. On the check side, the free plan's 250 lookups a month lines up comfortably with the signup volumes most Zap-driven lists actually see, and the 14-day full-access trial, no credit card, covers the testing period while you tune your filters.

That is the entire integration: one webhook, one filter, and your tools stop collecting addresses that were never people. The check behind it is isitdisposable.com, a live dataset of 217,847 disposable domains per the September report, drawn from multiple upstream sources, MX-validated and refreshed daily, and built to fail open, an unreachable or over-quota check answers allow, so your Zaps keep flowing and a signup is never lost to validation. And when a Zap graduates into real code, the same endpoint drops into a server in an afternoon; the Node.js and Express guide shows exactly how.