Email verification pricing is built around a particular customer: a sales team that has bought a list of 50,000 strangers and needs to know which addresses are real before burning their domain on it. Per-credit pricing, bulk tiers, enterprise plans.
If you are one person with a signup form, you have a different problem, and most of what that product sells solves something you do not have.
Three different questions
"Verify this email" is really three questions with very different costs.
Is it syntactically an address? Free, instant, and you should already be doing it. Do not use an elaborate regex. Check for one @, a domain with a dot, and no whitespace. Over-strict validation rejects real addresses, and plus-addressing and newer TLDs are the usual casualties.
Can the domain receive mail at all? Free, fast, and this is the highest value check available to you. Look up the domain's MX records. No MX means no mail, ever, and that catches the entire class of typos that matters: gmial.com, hotmial.com, a domain that expired. One DNS query, no vendor.
Does this specific mailbox exist? This is the expensive one, and it is what you are actually paying vendors for.
Why the third question costs money
Proving a mailbox exists means opening an SMTP conversation with the receiving server and getting as far as RCPT TO without sending anything. It is a normal protocol interaction, and it is also exactly what someone harvesting addresses does, so mail servers defend against it.
They defend by refusing connections from IP addresses that are not established senders. Residential and most cloud IPs are refused outright. Some providers accept every address regardless, which tells you nothing.
What a verification vendor sells is a pool of IP addresses with enough reputation that mail servers will still talk to them. That is a real asset and genuinely hard to build. It is not clever code.
The dangerous failure
If you write this yourself and run it from your laptop, you will get 5xx rejections and it is tempting to record them as "invalid". They are not. A 5xx at RCPT TO from an unestablished IP is the server declining to talk to you. Marking those addresses invalid deletes real customers from your list.
Only treat a rejection as a bad address when the response names the recipient, typically a 5.1.x code with text about an unknown user. Everything else is unknown, and unknown is a legitimate answer that any honest verifier should return.
What to actually do
For a signup form:
- Syntax check on the client for immediate feedback.
- MX lookup on the server. Reject with a helpful message when the domain cannot receive mail, and offer the obvious correction for common typos.
- Send a confirmation email. This is the only check that proves both that the address exists and that the person asking controls it, and it costs one email.
You do not need a verification vendor for a signup form. Confirmation email is verification, and it is stronger than anything a vendor can sell you.
For a list you already have and want to mail, the calculus changes. If it is a few hundred addresses collected through your own signup flow, mail them and let the bounces suppress themselves. If it is tens of thousands of addresses of unknown provenance, verify first, because a 13.8% bounce rate will get your sending account reviewed and the vendor fee is cheaper than that.
The honest summary
Syntax and MX are free and catch most real-world mistakes. Mailbox-level verification needs clean sending IPs, which is a thing you rent rather than build. And if you control the signup, a confirmation email beats all of it.