Call the API on blur rather than on submit. The check runs while the visitor moves to the next field, so the answer is already there when they finish and nothing waits on the network.
Set a timeout around 500 milliseconds and accept the address when it expires. A verification failure that costs a real signup has destroyed more value than the bad address it was guarding against.
What you do with each verdict is a product decision rather than a technical one. Blocking an invalid address is uncontroversial. Blocking a catch-all address refuses ordinary corporate customers because their IT department configured a wildcard, which is usually the wrong trade.
A typo suggestion converts more than a rejection does. Someone who typed gmial.com responds well to an offer to correct it and badly to a red border with no explanation.
Pair it with a honeypot field for scripts. Verification catches human mistakes and throwaway domains; the honeypot catches automation, and the two cover different halves of the same problem.
A month of signups, in numbers
Say your product gets 6,000 signups a month. Suppose 3% of those addresses are wrong in some way, mostly typos with a few fakes. That's 180 people each month who'll never get your welcome email, your receipt or your password reset, however good those emails are. Some of them wanted to become customers.
A check at the form costs little by comparison. On our 10,000-credit pack, each check is a quarter of a cent, so 6,000 signups come to $15 a month. Checks that come back unknown aren't billed, so the real figure is a bit lower.
Most of the value comes from typo suggestions. If 100 of those 180 people accept a one-click fix for a misspelled domain, you've kept 100 signups for $15. Every one of them was already on your form and trying to join.
Soft blocks, and a side effect to guard against
Think hard before you block outright. Verifiers are sometimes wrong, and a false invalid at your form turns a real customer away with no appeal. A soft block handles this better. Show a message like: we couldn't reach that mailbox, want to check for a typo? Then let the person continue anyway if they insist. You stop most mistakes and you never lock out a real buyer.
When a result is unknown, accept the signup and run the check again that night in a background job. If the address still can't be judged, your confirmation email will settle it.
There's a side effect to plan for. A form that reports whether an address exists is, in effect, a free verification service for anyone with a script. Bots can run stolen lists through it and spend your credits. Limit the number of checks per visitor and per IP address, and keep the message vague so it doesn't confirm that a mailbox exists.
Related questions
Will verification slow down my signup form?
Not if you call it on blur and cap the timeout near 500 milliseconds. The check overlaps with the rest of the form.
What should happen if the API is unreachable?
Accept the signup and verify in the background. A failed check should never cost a customer.
Should I block disposable addresses at signup?
For paid trials, often yes. For a newsletter it matters less, and the detection list can never be complete.
Does this replace double opt-in?
No. Verification proves the mailbox works. Confirmation proves the person wants your mail.