To verify emails in an n8n workflow, add an HTTP Request or Code node between your lead source and your CRM. It calls a verification engine, reads the verdict (deliverable, risky, invalid, unknown), then routes the record with an IF node. Only deliverable addresses get written. Bad ones get logged or discarded.
Why verify emails before they reach your CRM?
Dirty data spreads. One bad address in your CRM triggers a bounce, and enough bounces hurt your sender reputation. Verifying at the point of capture keeps invalid and risky contacts out of sequences entirely. Your bounce rate stays under 2%, your deliverability holds, and your reps stop chasing dead inboxes.
The cost of a bad record is not just one bounce. Mailbox providers watch your bounce rate as a spam signal. Send to a list with 5% invalids and Gmail starts routing your good mail to spam. n8n sits at the perfect spot to stop this. It already touches your form fills, your scraped lists, and your enrichment steps. Add one verification step before the CRM write and every downstream tool inherits clean data.
There is also the reputation math. Cold outreach lives or dies on inbox placement. If a chunk of your list bounces, spam filters notice and future sends land in the junk folder even for valid contacts. Verifying inside n8n means the check happens automatically, every time, without a person remembering to clean the list first.
What the n8n verification workflow looks like
The flow is short. A trigger brings in a new lead. A verification node checks the address. An IF node splits the traffic. Deliverable leads get written to the CRM. Everything else goes to a review sheet or gets dropped. Here is the node order for a self-hosted instance.
- Trigger node: a webhook, form submission, or schedule that pulls new rows from a source like Google Sheets or a scraped list.
- Set node: normalize the email field, trim whitespace, and lowercase the domain so the check runs clean.
- HTTP Request node: send the address to your verification engine and receive a JSON verdict.
- IF node: branch on the verdict, deliverable down one path, everything else down another.
- CRM node: create or update the contact (HubSpot, Pipedrive, Salesforce) only on the deliverable branch.
- Log node: append risky, invalid, and unknown results to a sheet for later review.
Building the verification node
The HTTP Request node does the real work. Point it at your verification endpoint, pass the email as a query parameter or JSON body, and set the authentication header. n8n stores the key in its credential vault, so it never sits in plain text inside the workflow. Map the response fields with an expression like {{ $json.result }} so the next node can read the verdict.
For small batches you can call the engine one address at a time. For bulk imports, loop with the Split In Batches node and add a short wait between batches. SMTP-level checks take a second or two per address because the node opens a real conversation with the receiving mail server. Rushing hundreds of lookups at once gets you rate limited or temporarily blocked. If you just want to sanity check a list by hand before wiring the automation, the free Free Email Verifier tool runs the same MX and SMTP checks in the browser and exports CSV or JSON.
Reading the verdict and routing the lead
Every address comes back with one of four verdicts. Your IF node keys off that value. Keep the logic simple: deliverable is the only verdict that earns a CRM write on the first pass. The table below maps each verdict to a routing action.
| Verdict | What it means | Route in n8n |
|---|---|---|
| Deliverable | Mailbox exists and accepts mail | Write to CRM, add to sequence |
| Risky | Catch-all, role, or disposable domain | Tag and hold for manual review |
| Invalid | Syntax error or no mailbox | Drop, do not store |
| Unknown | Server timed out or would not answer | Queue for a retry later |
Want to test the routing before you build the whole flow? Paste a sample list into the Free Email Verifier and watch how each address lands across the four verdicts. It runs 10 checks a day with no signup, or 100 after you enter an email, and your CSV is parsed in the browser so nothing gets uploaded. If you would rather skip the build entirely and have verified meetings land on your calendar, Synthisia runs the pipeline for you.
Check your list right now, free
10 checks a day with no signup. 100 a day with just your email.
Can n8n verify emails in real time?
Yes. Wire the verification node to a webhook trigger and it checks each address the moment a form is submitted. The lead is scored before it ever reaches your CRM, usually within two or three seconds. For batch jobs, run the same node on a schedule against new rows instead of on submission.
Real-time checks work best for inbound forms where you want to gate signups or route hot leads instantly. For scraped or purchased lists, batch verification with a wait between calls is safer. Either way, the verdict logic stays identical, only the trigger changes.
Handling catch-all, role, and unknown addresses
Risky and unknown are where most people get the workflow wrong. A catch-all domain accepts every address, so the server cannot confirm the specific mailbox. Do not treat catch-all as invalid and do not blindly trust it. Tag those leads and let a human decide, or send them a low-stakes first touch and watch for a bounce. Role addresses like info@ or sales@ reach a group inbox, not a person, so they belong in a separate nurture path.
Unknown usually means a timeout, not a bad address. The receiving server was slow or greylisted your check. Build a retry branch that re-queues unknown results after a few hours. A second pass clears most of them. Never discard an unknown on the first look. You will throw away real leads.
Keeping the self-hosted flow reliable
A self-hosted n8n instance gives you full control over the data, which matters when you are pushing contact records through a third party. Keep the verification credential in the vault, not in a Set node. Add an Error Trigger workflow so a failed lookup pages you instead of silently dropping leads. And watch your daily volume against whatever limit your engine enforces so a big import does not stall halfway.
Version the workflow too. Export the JSON and commit it so a bad edit can be rolled back. When you change the verification endpoint or the CRM field mapping, test on a handful of known addresses first. One deliverable, one invalid, one catch-all. If all three route correctly, the flow is safe to turn back on for the full volume.
The payoff is steady. Clean addresses reach your CRM, your bounce rate stays low, and your reps work a list of real people. Build the verification step once and every future lead source plugs into the same guardrail.