Email Validation API: Verify Emails with Format, MX, and Risk Scoring

A bad email address costs more than a bounced message. It inflates your subscriber counts with phantom users, drags down your sender reputation, triggers spam filters that affect your legitimate emails, and opens the door to fraud. For fintech platforms handling account creation, transaction notifications, and compliance communications, email quality is not optional — it is infrastructure.

Edge's Email Validation API checks email addresses at multiple layers: syntax validation, MX record verification, disposable domain detection, and risk scoring. Each check adds confidence that the address you are storing is real, active, and safe to send to.

This guide covers what the API checks, why each layer matters, and how to integrate validation into your application with practical code examples.

Why Regex Is Not Enough

Most developers start with regex validation. It is the first line of defense, and it catches obvious typos like missing @ signs or spaces in the address. But regex only checks format — it tells you nothing about whether the address actually exists.

Consider these addresses that pass standard regex validation:

• user@gmial.com — typo in the domain, mail will bounce
• test@mailinator.com — disposable address, user has no intention of engaging
• admin@expired-startup.com — domain exists but MX records are gone
• a@b.c — syntactically valid but almost certainly not a real mailbox

A comprehensive validation pipeline goes beyond pattern matching. It checks whether the domain can receive email (MX records), whether the domain is a known disposable provider, and assigns a risk score based on multiple signals.

What the Email Validation API Checks

When you submit an email address to the API, it runs through a multi-stage validation pipeline:

Stage 1: Format and Syntax Validation

The API checks the address against RFC 5321 and RFC 5322 standards. This catches structural issues that regex patterns often miss, including:

• Invalid characters in the local part
• Missing or malformed domain components
• Addresses exceeding length limits (64 characters for local part, 255 for full address)
• Quoted string and special character handling

Stage 2: DNS and MX Record Verification

The API performs a live DNS lookup on the domain to check for MX (Mail Exchanger) records. If a domain has no MX records and no A record fallback, it cannot receive email. This catches:

• Typos in popular domains (gmial.com, yaho.com, hotmal.com)
• Expired or parked domains that no longer operate mail servers
• Non-existent domains entirely

Stage 3: Disposable Domain Detection

The API checks the domain against a continuously updated database of disposable and temporary email providers. Services like Mailinator, Guerrilla Mail, TempMail, and hundreds of lesser-known providers are flagged. This matters because:

• Users with disposable emails rarely convert to paying customers
• Disposable addresses are frequently used in fraud and abuse patterns
• They inflate your user counts without adding business value

Stage 4: Risk Scoring

The API combines signals from all previous stages into a risk score that ranges from low to critical. The scoring considers:

• Domain age and reputation
• Whether the domain is a free email provider (Gmail, Yahoo, Outlook)
• Disposable domain flags
• MX record configuration quality
• Known patterns associated with fraudulent registrations

The risk score is not a binary pass/fail. It gives you granularity to make decisions appropriate to your context. A free email address might be acceptable for a newsletter signup but warrant additional verification for a financial account.

API Usage

Basic Email Validation

curl -X POST "https://api.edge.bh/v1/email/validate" \
  -H "X-Api-Key: your_api_key" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{"email": "user@example.com"}'

Response:

{
  "success": true,
  "data": {
    "email": "user@example.com",
    "is_valid": true,
    "checks": {
      "format": {
        "valid": true,
        "local_part": "user",
        "domain": "example.com"
      },
      "mx_records": {
        "found": true,
        "records": ["mx1.example.com", "mx2.example.com"]
      },
      "disposable": {
        "is_disposable": false
      }
    },
    "risk": {
      "score": "low",
      "factors": []
    },
    "suggestion": null
  }
}

Catching Typos with Domain Suggestions

When the API detects a likely typo in a popular domain, it returns a suggestion:

curl -X POST "https://api.edge.bh/v1/email/validate" \
  -H "X-Api-Key: your_api_key" \
  -H "Content-Type: application/json" \
  -d '{"email": "john.doe@gmial.com"}'

{
  "success": true,
  "data": {
    "email": "john.doe@gmial.com",
    "is_valid": false,
    "checks": {
      "format": {
        "valid": true,
        "local_part": "john.doe",
        "domain": "gmial.com"
      },
      "mx_records": {
        "found": false,
        "records": []
      },
      "disposable": {
        "is_disposable": false
      }
    },
    "risk": {
      "score": "high",
      "factors": ["no_mx_records", "possible_typo"]
    },
    "suggestion": "john.doe@gmail.com"
  }
}

This alone recovers a meaningful percentage of lost signups. Rather than silently accepting a bad address or showing a generic error, you can prompt the user: "Did you mean john.doe@gmail.com?"

JavaScript Integration for Signup Forms

Here is a practical integration for validating emails during user registration:

async function validateEmail(email) {
  const response = await fetch("https://api.edge.bh/v1/email/validate", {
    method: "POST",
    headers: {
      "X-Api-Key": process.env.EDGE_API_KEY,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({ email })
  });

  const { data } = await response.json();

  if (!data.is_valid) {
    if (data.suggestion) {
      return {
        valid: false,
        error: `This email appears invalid. Did you mean ${data.suggestion}?`
      };
    }
    return {
      valid: false,
      error: "Please enter a valid email address."
    };
  }

  if (data.checks.disposable.is_disposable) {
    return {
      valid: false,
      error: "Disposable email addresses are not allowed. Please use a permanent email."
    };
  }

  if (data.risk.score === "critical" || data.risk.score === "high") {
    return {
      valid: true,
      requireVerification: true,
      message: "We'll send a verification email to confirm this address."
    };
  }

  return { valid: true, requireVerification: false };
}

// Usage in a form handler
const result = await validateEmail("user@example.com");
if (!result.valid) {
  showError(result.error);
} else if (result.requireVerification) {
  triggerEmailVerification();
} else {
  proceedWithRegistration();
}

This pattern gives you three tiers of response: reject clearly bad addresses, flag risky ones for verification, and pass clean ones through immediately. The user experience stays smooth while your data quality stays high.

Real-World Use Cases

Signup and Registration Forms

The highest-impact integration point. Validating emails at the moment of registration prevents bad data from entering your system in the first place. For fintech applications where email is a primary communication channel for transaction alerts and compliance notices, this is critical.

A typical implementation validates on form blur (when the user tabs away from the email field) so feedback is immediate without blocking the submission flow.

Marketing List Hygiene

If you have an existing email list, batch validation before a campaign prevents bounces that damage your sender reputation. Email service providers like SendGrid, Mailchimp, and Amazon SES track your bounce rate. Exceed their threshold, and your account gets throttled or suspended.

The economics are straightforward: validating 10,000 emails costs a fraction of what a damaged sender reputation costs in lost deliverability across your entire list.

Fraud Prevention at Account Creation

Disposable emails are a signal. Not every user with a disposable email is a fraudster, but patterns of disposable email usage correlate strongly with:

• Account farming and credential stuffing
• Promo abuse (creating multiple accounts for referral bonuses)
• Chargeback fraud in payment platforms

Combining email risk scoring with phone validation and sanctions screening gives you a layered defense that catches bad actors without adding friction for legitimate users.

CRM and Database Cleaning

Customer databases accumulate invalid emails over time. People change jobs, domains expire, and typos slip through older systems that lacked validation. Periodic batch validation keeps your CRM data accurate, your segmentation reliable, and your outreach effective.

The ROI of Clean Email Data

The business case for email validation is concrete and measurable:

Reduced bounce rates. Industry benchmarks consider a bounce rate above 2% problematic. Above 5%, and your sender reputation is actively degrading. Each invalid email removed directly improves this metric.

Higher deliverability. Email providers use engagement signals and bounce rates to decide whether your messages reach the inbox or the spam folder. Clean lists get better placement.

Accurate metrics. If 8% of your email list is invalid, your open rates and click rates are artificially deflated by 8%. Cleaning the list gives you accurate numbers to make decisions on.

Lower costs. Most email service providers charge by list size or send volume. Removing invalid addresses directly reduces your bill.

Reduced fraud exposure. For platforms that extend credit, process payments, or handle sensitive data, catching suspicious emails at registration is a fraction of the cost of dealing with fraud downstream.

Email Validation vs. Email Verification

These terms are often used interchangeably, but they serve different purposes:

Validation (what this API does) checks whether an email address is structurally correct, has working mail infrastructure, and exhibits risk signals. It happens instantly, in real time, without sending any email to the address.

Verification (sending a confirmation email) proves that a specific person controls the inbox. It requires the user to click a link, which adds friction and delays.

The best practice is to use both: validate first to catch obviously bad addresses without bothering the user, then verify high-risk addresses or when your use case demands proof of ownership (financial accounts, password resets).

Server-Side Validation: Always Required

Client-side validation improves the user experience, but it is never sufficient on its own. Any validation running in the browser can be bypassed by a determined user or bot.

For the Email Validation API, the recommended architecture is:

1. Client-side: Quick regex check for instant feedback on obvious format errors
2. Server-side: Full API validation before storing the email or creating the account
3. Post-registration: Verification email for high-value accounts

// Server-side (Node.js/Express example)
app.post("/api/register", async (req, res) => {
  const { email, password, name } = req.body;

  // Server-side validation via Edge API
  const validation = await fetch("https://api.edge.bh/v1/email/validate", {
    method: "POST",
    headers: {
      "X-Api-Key": process.env.EDGE_API_KEY,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({ email })
  });

  const { data } = await validation.json();

  if (!data.is_valid) {
    return res.status(422).json({
      error: "invalid_email",
      message: "The provided email address is not valid.",
      suggestion: data.suggestion || null
    });
  }

  if (data.checks.disposable.is_disposable) {
    return res.status(422).json({
      error: "disposable_email",
      message: "Please use a permanent email address."
    });
  }

  // Proceed with account creation
  const user = await createUser({ email, password, name });

  // If risk is elevated, require email verification
  if (data.risk.score === "high" || data.risk.score === "critical") {
    await sendVerificationEmail(user);
    return res.status(201).json({
      user,
      requiresVerification: true
    });
  }

  return res.status(201).json({ user, requiresVerification: false });
});

Getting Started

Integrating the Email Validation API takes minutes:

1. Sign up at app.edge.bh and create your organization.
2. Generate an API key from the dashboard.
3. Start validating using the code examples above.

Edge's credit-based pricing means you pay only for the validations you run. The free tier gives you enough credits to build and test your integration before committing to a paid plan.

For a complete validation stack, combine email validation with phone validation and IBAN validation to verify all user-submitted contact and financial data from a single platform.

Frequently Asked Questions

Does the API actually send an email to check deliverability?

No. The API validates the email address using DNS lookups, MX record checks, and domain analysis. It does not send any message to the address. This means validation is instant (typically under 500ms) and does not alert the address owner that a check was performed.

How accurate is disposable email detection?

The disposable domain database is continuously updated and covers thousands of known temporary email providers, including their auto-generated subdomains. No detection system is 100% comprehensive since new disposable services appear regularly, but the database catches the vast majority of commonly used providers.

Can I validate emails in bulk?

The API processes one email per request, which works well for real-time form validation. For batch processing (cleaning an existing list), you can make concurrent requests within your rate limit. If you have large-scale batch needs, contact the Edge team through the dashboard to discuss optimized batch pricing.

What does the risk score factor in?

The risk score combines multiple signals: whether the domain has valid MX records, domain age and reputation data, free vs. business email provider classification, disposable domain flags, and pattern analysis. The score levels (low, medium, high, critical) help you make graduated decisions rather than binary accept/reject.

Should I reject all high-risk emails?

Not necessarily. A high-risk score is a signal, not a verdict. For low-stakes interactions like newsletter signups, you might accept high-risk emails but skip sending expensive onboarding sequences. For financial account creation, you might require additional verification. The API gives you the data to make context-appropriate decisions.

How does this compare to using a regex pattern?

Regex validation catches roughly 20-30% of invalid emails (the ones with obvious format errors). It misses typos in valid-looking domains, disposable addresses, and domains that no longer accept mail. The Email Validation API catches these additional cases because it performs live infrastructure checks rather than just pattern matching. Use regex for instant client-side feedback, and the API for authoritative server-side validation.