Email Verification Before the CRM, Not After

Most businesses that have ever had a deliverability problem solved it by cleaning the list. You export, run it through a verification service, remove the dead addresses, re-import.

That works, and it is repair. It happens after the bounces have already been recorded against your sending domain.

The same service, called half a second earlier — at the moment the address is typed into your form — prevents the damage instead. It is the same money and a completely different outcome, and the only difference is where in the sequence it sits.

The bounce you avoid was never counted

This is the whole argument and it is worth being precise about it.

Mailbox providers score your sending domain on what you actually send. A hard bounce — mail to an address that does not exist — is a signal that you are mailing a list you have not maintained. Accumulate enough and your placement degrades, which affects everything from that domain, including your quotes and invoices.

Now compare two sequences.

Clean afterwards. Address is captured. It goes into the CRM. A campaign sends. The bounce is recorded. You later export, verify, and remove it. Net effect: one bounce on your record, permanently, plus the work.

Verify first. Address is captured. Before anything is stored, it is checked. It fails. The person is told immediately, on the form, while they are still looking at it. Net effect: nothing on your record, and frequently a corrected address, because the most common failure is a typo and the person is still sitting there.

That last part is the underrated half. gmial.com typed at 9pm is fixable at 9pm. It is not fixable three weeks later when it turns up in a bounce report.

What a check at the form actually catches

Three categories, and they are not equally important.

Typos in known domains. gmial.com, hotmial.com, yahoo.co. The highest-volume failure and the only one where the correction is trivial. Good services suggest the fix.

Disposable and throwaway domains. Addresses created to collect something and abandoned. If you gate a download behind an email, you have more of these than you think. They do not bounce immediately — they bounce later, once the service recycles them, which makes them the most insidious category.

Mailboxes that do not exist. The service performs a check against the receiving server without actually sending. This is what catches a real-looking address at a real domain that was never issued, or was deactivated when someone left.

The third is the one that matters for business-to-business, because staff turnover means a perfectly valid address today is a hard bounce in eighteen months and nothing tells you.

The fail-open decision, and why we made it

Here is the part that never appears in the sales material for these services.

The verification service is a third-party API. It can be slow. It can be down. So the system has to decide what happens when the check cannot be completed, and there are only two answers.

Fail closed. No verification, no submission. Your contact form now depends on a third party being up.

Fail open. The submission proceeds unverified.

We chose fail open, and it is the right default for a contact form. Losing a genuine enquiry because a verification API had a bad minute is a worse business outcome than admitting one junk address. The enquiry is revenue; the junk address is a small reputational cost you can absorb.

But it is a real trade and it should be a decision rather than an accident. If the form gates something expensive — a physical sample, a free trial with a cost attached, an account with resources behind it — fail closed is defensible, because the cost of admitting a bad actor now exceeds the cost of losing a legitimate one.

★ Insight ───────────────────────────────────── Whichever way you choose, the outcome has to be recorded. A submission that proceeded without verification should be marked as such. Otherwise your database contains two kinds of contact that look identical — checked and not checked — and every later decision treats them the same. That is the same defect as a total that does not know what it cannot see: the data is fine, the label on it is a claim nobody established. ─────────────────────────────────────────────────

Where it sits in the sequence

The order that works, and the reason for each position:

1. Spam protection, in the browser. A challenge and a honeypot. Before anything leaves the page, because a challenge has to be solved client-side and there is no point spending an API call on a bot.
2. Address verification. Before any write. This is the position that converts repair into prevention.
3. Create or update the contact record. Keyed on the email address, so a repeat enquirer updates rather than duplicating.
4. Confirmation email and double opt-in. The person proves they can receive mail at the address they gave.
5. Only then, any automated sending.

Steps 2 and 4 are often presented as alternatives. They are not — they catch different things. Verification catches addresses that cannot receive mail. Double opt-in catches addresses that can receive mail but do not belong to the person filling in your form. You want both, and verification first, because there is no sense sending a confirmation to an address that does not exist.

What it costs

These services price per check, in fractions of a cent at small volume, usually with a free tier that covers a typical small-business contact form entirely.

The honest comparison is not cost versus nothing. It is cost versus the alternative you are already paying: periodic list cleaning, which costs the same per address, plus the bounces you have already taken, plus the time.

What verification does not do

Worth being clear, because these services are sold as though they solve deliverability.

It does not tell you the address belongs to the person using your form. Somebody can type a real address that is not theirs. That is what the confirmation click is for.

It does not tell you they want your email. A valid, reachable, correctly-typed address that never asked for marketing will still produce a spam complaint, and a complaint is a stronger negative signal than a bounce.

It does not keep working. An address verified today is a hard bounce in two years, because people leave jobs and mailboxes get closed. Verification at capture reduces the bounce rate of new contacts; it does nothing for the list you already hold.

So the honest position is that it removes one failure mode of three, at the cheapest possible moment. The other two need double opt-in and periodic re-checking of your existing list, and a business that verifies at the form and never looks at its list again will still find its reputation degrading in a few years.

The check worth running this week

Export your contact list and look at the last hundred addresses captured.

Count the obvious typos. Count the free-mail addresses on a business form. Count anything at a domain you do not recognise.

Whatever that count is, it is the number you have been paying for in reputation, and it is the number a check at the form would have caught while the person was still there to fix it.

---

Cloud Geeks runs email infrastructure, forms and CRM integration for Australian small businesses. Websites come from Cosmos Web Tech, apps from Awesome Apps, and the group is Ganda Tech Services.