Real-time email validation on sign-up forms: how it works and what it catches
Real-time email validation checks an address as it is typed: syntax, typos, disposable domains, role accounts, MX and an optional mailbox check. Here is how it works.
Verify emails with Zapier or Make: step-by-step setup for both
Verify every lead with one HTTP step: Webhooks by Zapier GET plus a Filter, or Make's HTTP module plus a Router. Exact settings, typo fixing, error handling, costs and a Zapier vs Make comparison.
To verify emails with Zapier or Make, add one HTTP step after your trigger that calls the Verifyre API with the email mapped into the query string, then filter or branch on the status or score it returns. In Zapier that is a Webhooks by Zapier GET step followed by a Filter; in Make it is an HTTP module followed by a Router. Either way the setup takes about ten minutes, and every lead is verified before it reaches your CRM or email tool.
Why verify inside the automation?
Most lead pipelines look the same: a form, a Zap or scenario, a CRM or ESP. Anything typed into the form, including typos and disposable addresses, flows straight through. Typically 5% to 15% of raw form submissions are undeliverable at the moment they are captured, and each one becomes a bounce in the welcome email, a dead record in the CRM and a wasted sales follow-up.
Putting the check in the automation means it runs once, in one place, for every source that feeds the pipeline. You never send to an address that cannot receive, and you can fix typos on the way through.
How do you set it up in Zapier?
- Add your trigger as usual, for example Typeform > New Entry or Facebook Lead Ads > New Lead.
- Add a Webhooks by Zapier step, event GET, and fill it in like this:
URL: https://verifyre.co/api/v1/verify
Query String: email = {{Email from the trigger step}}
Send As JSON: No
Unflatten: Yes
Headers: Authorization = Bearer vfy_live_YOUR_API_KEYTest the step with a real address. The response fields appear as Status, Score, Reason, Reason Text, Did You Mean, Deliverable and Provider, ready to map into later steps.
- Add Filter by Zapier. Condition: Status (Text) Exactly matches deliverable. Or, if you want to allow catch-all and other risky addresses through, use Score (Number) Greater than 59 instead. Rows that fail the filter stop here and are not billed as further tasks.
- Branch with Paths if you need different handling. Path A: Status is deliverable, create the CRM contact and send the welcome email. Path B: Status is risky, create the contact but tag it "needs confirmation" and send a re-confirmation email instead. Path C: Status is undeliverable, log it to a sheet.
- Fix typos with Formatter. Add Formatter by Zapier > Text > Default Value: input
Did You Mean, defaultEmail from trigger. The output is the corrected address when a suggestion exists (gmial.com becomes gmail.com) and the original otherwise. Map that output, not the raw trigger email, into the CRM step. - Handle errors. Leave the webhook step's "allow this step to error" setting off so a 429 rate limit or a 402 out-of-credits halts the Zap rather than passing an unverified lead through.
The same pattern works with any other Zapier trigger, and the native Zapier integration replaces step 2 with a "Verify Email" action that needs no headers.
How do you set it up in Make?
- Add your trigger module, for example Webhooks > Custom webhook or Google Sheets > Watch new rows.
- Add an HTTP > Make a request module with these settings:
URL: https://verifyre.co/api/v1/verify
Method: GET
Query String: Name: email Value: {{1.email}}
Headers: Name: Authorization Value: Bearer vfy_live_YOUR_API_KEY
Body type: empty
Parse response: YesParse response: Yes is the setting people miss. Without it the response is a single text blob and nothing is mappable; with it, status, score, did_you_mean and the rest appear as fields in the next module.
- Add a Router after the HTTP module and create one route per outcome. On each route set a filter: route 1,
statusequal todeliverable; route 2,statusequal torisky(orscoregreater than or equal to 60 if you prefer the score); route 3, fallback for everything else. - Build each route. Deliverable: add the contact to your CRM and ESP. Risky: add the contact with a tag and send a re-confirmation message. Fallback: write the address and
reason_textto a Google Sheet for review. - Apply the correction. In the CRM module, map the email field to
{{if(2.did_you_mean; 2.did_you_mean; 1.email)}}so a suggested fix replaces a typo. - Set error handling. Right-click the HTTP module > Add error handler. A Break with retries handles 429 rate limits; a Resume directive with a fallback value lets you choose whether to pass the lead through unverified on a 402. Make gives you finer control here than Zapier does.
The ready-made Make integration wraps the HTTP module with the key stored as a connection, which keeps it out of the scenario itself.
Zapier or Make: which is better for this?
| Aspect | Zapier | Make |
|---|---|---|
| Pricing model | Per task; every step that runs after the trigger is a task | Per operation; each module run is an operation, usually cheaper per row |
| Ease of setup | Simpler, more guided; Filter and Paths are easy | Steeper at first; the Router and filters are more flexible once learned |
| Branching | Paths, limited to a few branches on lower plans | Router with unlimited routes and per-route filters |
| Error handling | Automatic retries, step-level errors halt the Zap | Explicit error handlers per module: retry, ignore, resume, rollback |
| Fixing typos | Formatter step with a default value | Inline if() function in the mapping |
For a simple form-to-CRM flow with one filter, either is fine. With several outcomes, or if you need control over what happens on an API error, Make is the stronger tool.
What are the typical use cases?
- Lead form to CRM. Form > verify > HubSpot, Pipedrive or Salesforce. Undeliverable leads never reach sales, and the HubSpot integration covers cleaning the existing database too.
- Facebook or LinkedIn Lead Ads. These forms autofill from the user's profile, and the profile address is often an old one. Verify before paying for a CRM seat.
- Spreadsheet intake. New row in Google Sheets > verify > write the status to the next column, which is the automation alternative to the function in how to verify emails in Google Sheets.
What does it cost per row?
Each verification uses one Verifyre credit per unique address; a second check of the same address within 24 hours is free and returns cached: true. On the automation side, Zapier counts the webhook step and every later step as tasks, so a lead that passes the filter and lands in a CRM costs around three tasks. Make counts one operation per module, so the same flow is roughly four operations. A lead that fails the filter in Zapier stops before any further task is charged, and a Make route that no row matches costs nothing.
For developers who would rather skip the no-code layer, the same endpoint is documented on the email verification API page, and the JSON fields mapped above are identical.
Key takeaways
- One GET request to the verify endpoint with the email in the query and the key in the Authorization header, in either tool.
- Zapier: Webhooks GET, then Filter on Status exactly matches deliverable or Score greater than 59, then Paths and Formatter.
- Make: HTTP module with Parse response set to Yes, then a Router with a filter per route.
- Map did_you_mean over the raw email to fix typos on the way into the CRM.
- One credit per unique address, free repeats within 24 hours; filtering early keeps task costs down.
Frequently asked questions
Should I filter on status or on score?
Status is the simpler rule: deliverable only. Score lets you choose your own line; 60 and above admits catch-all and other risky addresses, which is often right for B2B leads where catch-all domains are common.
What happens to leads when I run out of credits?
The API returns 402 out_of_credits. In Zapier the step errors and the Zap halts until you top up; in Make you can add an error handler that passes the lead through unverified instead.
Does verification slow the automation down?
By about half a second to three seconds per lead, which is the time of the SMTP conversation. The ms field in the response reports the exact figure.
