How to Integrate Real-Time Email Validation into Your Signup Form

Blocking bad addresses at the point of entry is far cheaper than cleaning them up later. Real-time email validation checks an address the moment a visitor submits your signup form, so typos, fake addresses and domains that cannot receive mail are caught while the person is still on the page. This tutorial shows how to add it using the MailInsightX API, with a safe server-side pattern, error handling and user-experience tips.
Why Validate Email Addresses at Signup?
Every invalid address you let into your database becomes a future problem: a bounce, a wasted contact fee, a skewed metric, or a missing customer who never got their confirmation email. Validation at the form helps you:
- Catch typos such as
gmial.comso real customers can correct them. - Block or flag disposable addresses that will never become lasting relationships.
- Keep bounce rates low, protecting your sender reputation. See what a bounce rate is and why it matters.
- Reduce fake sign-ups and free-trial abuse.
- Lower costs because your email platform and CRM store fewer dead contacts.
The trade-offs between this approach and checking whole lists are covered in single vs. bulk verification. In short, real-time validation prevents new bad data, while bulk verification cleans existing data. Still choosing a provider? See best email verification APIs for developers.
Before You Start
You need:
- A MailInsightX account on a paid plan. API access is not available on the Free plan. You can compare plans on the pricing page.
- An API key. Open the API Keys section in your dashboard and generate one. The full key is shown only once, so store it securely. The authentication guide explains this in detail.
- InsightX+ credits. The verify endpoint spends one InsightX+ credit per request. See credit pools for how they work.
- A server-side environment such as Node.js. This matters for the next section.
Rule One: Never Call the API from the Browser
Your API key is a secret. If you call the MailInsightX API directly from front-end JavaScript, anyone can open their browser's developer tools, copy the key and spend your credits. Always make the request from your server, and let your front end talk to your own endpoint.
The flow looks like this:
- The visitor submits the form.
- Your front end sends the email to your own backend route.
- Your backend calls MailInsightX with the API key.
- Your backend decides what to do with the result and replies to the form.
Step 1: Understand the Endpoint
The verify endpoint accepts a single email address:
POST https://mailinsightx.com/v1/verify
x-api-key: mi_your_api_key
Content-Type: application/json
{ "email": "[email protected]" }
A successful response contains a result object:
{
"email": "[email protected]",
"result": {
"status": "Valid",
"mx_valid": true,
"smtp_valid": true,
"is_catch_all": false,
"is_role_account": false,
"is_disposable": false,
"is_gibberish": false
}
}
The status field is the headline answer. The full list of statuses is in the Verification Status Glossary, and the verify endpoint reference documents every field and error.
Step 2: Create a Server-Side Route
Here is an example Node.js (Express) route that validates an email before accepting a signup. Keep the API key in an environment variable, never in your source code.
app.post('/api/signup', async (req, res) => {
const { email } = req.body;
try {
const response = await fetch('https://mailinsightx.com/v1/verify', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'x-api-key': process.env.MAILINSIGHTX_API_KEY,
},
body: JSON.stringify({ email }),
});
// If validation is unavailable, let the signup through rather than blocking real users.
if (!response.ok) {
return createAccount(email, res);
}
const data = await response.json();
const status = data.result.status;
const blocked = ['Hard Bounce (SMTP)', 'Invalid Domain (No MX)', 'Disposable'];
if (blocked.includes(status)) {
return res.status(400).json({ error: 'Please enter a valid, permanent email address.' });
}
return createAccount(email, res, { risky: status !== 'Valid' });
} catch (err) {
// Network problem: fail open so a validation outage never stops signups.
return createAccount(email, res);
}
});
Why this pattern works
- The key stays on the server.
- It fails open. If the validation service has a problem, signups continue. Losing a genuine customer is usually worse than accepting one questionable address, which a later bulk clean can catch.
- It separates "block" from "flag." Clear failures are rejected. Uncertain results are accepted but marked so you can handle them with care.
Step 3: Decide What to Do with Each Status
Not every status should be treated the same way. A sensible starting policy:
| Status | Suggested action |
|---|---|
| Valid | Accept |
| Hard Bounce (SMTP) | Reject and ask for another address |
| Invalid Domain (No MX) | Reject and ask for another address |
| Disposable | Reject, or accept and flag, depending on your product |
| Catch-All (Risky) | Accept, but flag and send a confirmation email |
| Role-Based (Risky) | Accept, flag, and consider asking for a personal address |
| Gibberish (Risky) | Flag or require double opt-in |
| Greylisted, Tarpitted or Unverified | Accept and rely on double opt-in |
Read catch-all emails explained to understand why catch-all and similar results should be accepted cautiously rather than rejected. To recognize bad addresses, see how to spot fake email addresses.
Step 4: Respect Rate Limits and Handle Errors
The API shares a limit across your account, currently 10 requests per 60-second window. That is comfortable for a typical signup form but not for bulk processing, so do not use the API to verify large files. Use bulk upload for that. Details are in the rate limits documentation.
Plan for these responses:
- 400: the email format was invalid. Show a friendly message.
- 402: you ran out of InsightX+ credits. Alert your team and fail open.
- 429: too many requests. Retry shortly or fail open.
- 500 and 502: temporary backend problem. Fail open. The errors reference shows which failures refund your credit.
You can check your balance with the balance endpoint and set an alert before it runs out.
Step 5: Design the Form Experience
Good validation feels helpful, not punishing.
- Be specific. "That email domain can't receive mail. Please check for typos." is better than "Invalid email."
- Offer corrections. If the domain looks like a typo of a major provider, suggest the fix.
- Do not reveal technical detail. Show a general message and keep raw statuses in your logs.
- Validate on submit, not on every keystroke, to conserve credits and avoid flicker.
- Show a loading state so users know something is happening.
- Keep double opt-in for important lists. Validation shows an address can receive mail; confirmation shows the owner wants it.
Step 6: Protect the Endpoint Itself
Because each check uses a credit, attackers or bots could drain your balance by hammering your signup route. Add:
- A rate limit per IP address on your own endpoint.
- A CAPTCHA or bot-detection check before calling the API.
- Basic format validation on your server before spending a credit.
- Logging and monitoring for unusual spikes.
Testing Your Integration
- Submit an obviously invalid address and confirm it is rejected.
- Submit a mistyped domain and confirm the user sees a helpful message.
- Submit a valid address and confirm the account is created.
- Temporarily use a wrong API key and confirm the flow fails open.
- Check your credit balance changes as expected.
Frequently Asked Questions
Can I call the MailInsightX API from front-end JavaScript?
No. That would expose your API key. Call it from your server and let the browser talk to your own endpoint.
Does real-time validation replace double opt-in?
No. Validation shows an address appears able to receive mail. Double opt-in confirms the owner wants it. Use both for high-value lists.
What happens if the API is down when someone signs up?
Design your route to fail open so signups continue, then verify those addresses later in bulk.
Does each validation cost a credit?
Yes, the verify endpoint spends one InsightX+ credit per request, and failed requests caused by backend errors are refunded as described in the errors reference.
Is there a bulk API endpoint?
No. The API verifies one address per request. For large lists use the dashboard bulk upload.
Start Protecting Your Signup Form
Real-time validation is one of the simplest ways to keep your database healthy from day one. Create a free MailInsightX account to explore the dashboard, then upgrade to a plan with API access when you are ready to integrate. Full reference material lives in the developer portal.
Enjoyed this post?
Get new posts like this one, and product updates, sent to your inbox.