Email Verification API Benchmarks

What Does 99.9% Accuracy Actually Measure

Email-check.app claims 99.9% accuracy for deliverable emails. This number is measured against emails that have confirmed mailboxes — addresses where an SMTP RCPT TO command returns 250 OK. The metric does not include catch-all domains, greylisted addresses, or addresses behind aggressive spam filters that time out.

Why this distinction matters: a provider that tests accuracy only against clearly deliverable addresses (Gmail, Outlook, corporate domains with standard SMTP) will show higher numbers than one that tests against a representative sample including catch-alls, role-based addresses, and recently registered domains. When comparing providers, ask what the test set included.

Response Time Benchmarks: What 25ms Means

The email-check.app API averages 25ms response time for a single verification call. This is the median (p50) measurement for a request that includes format validation, MX lookup, and SMTP verification. The p99 latency is higher — typically under 200ms — because SMTP connections to slow or rate-limiting mail servers take longer.

Response time varies by verification depth:

# Response time by verification depth (approximate)
# Format + MX only:        5-15ms
# Format + MX + SMTP:       15-50ms  (typical)
# Format + MX + SMTP + extras: 20-80ms
#   (extras = name detection, domain age, typo check)

# Real API call with all features enabled
curl -X GET "https://api.email-check.app/v1-get-email-details" \
  -H "accept: application/json" \
  -H "x-api-key: YOUR_API_KEY" \
  -G \
  -d "email=sales@acme-corp.com" \
  -d "verifyMx=true" \
  -d "verifySmtp=true" \
  -d "detectName=true" \
  -d "suggestDomain=true" \
  -d "checkDomainAge=true" \
  -d "timeout=10000"

# Response structure
{
  "email": "sales@acme-corp.com",
  "validFormat": true,
  "validMx": true,
  "validSmtp": true,
  "isDisposable": false,
  "isFree": false,
  "detectedName": {
    "firstName": null,
    "lastName": null,
    "confidence": 0
  },
  "domainSuggestion": null,
  "domainAge": {
    "ageInDays": 1247,
    "createdDate": "2022-09-15T00:00:00Z",
    "isValid": true
  },
  "score": 92
}

The score field (0-100) provides a composite quality rating. Scores above 80 indicate a high-confidence deliverable address. Scores between 40-80 suggest uncertainty — catch-all domains, greylisted addresses, or role-based accounts. Below 40 indicates likely undeliverable.

The Catch-All Problem: Where Accuracy Claims Break Down

Catch-all domains accept all emails regardless of whether the mailbox exists. Common examples include large enterprise domains configured to accept everything, Google Workspace domains with catch-all routing, and some hosting providers. When an SMTP RCPT TO returns 250 OK for every address, the provider cannot determine if the specific mailbox exists.

Different providers handle this differently:

• Return "accept_all" status. This is what email-check.app does. The API returns validSmtp: truebut the status is "accept_all" rather than "deliverable". Downstream systems can decide how to treat these — some teams send to accept_all addresses, others exclude them.
• Retry with delay. Some providers attempt SMTP verification multiple times with increasing delays, hoping the server eventually returns a definitive response. This improves accuracy but increases latency.
• Mark as "risky." Conservative providers classify all catch-all results as uncertain, regardless of the SMTP response.

For B2B lists, 15-30% of addresses may hit catch-all domains. How your provider handles them directly impacts how many contacts you can safely email. If you reject all catch-alls, you lose real contacts. If you accept them all, you add bounce risk. The right approach depends on your tolerance for false negatives versus false positives.

Greylisting and SMTP Timing

Greylisting is an anti-spam technique where the mail server temporarily rejects the first delivery attempt with a 450 response, then accepts retries from the same IP. Most email verification APIs, including email-check.app, handle this by retrying the SMTP connection after a short delay.

The practical impact: the first verification request to a greylisting server may return "unknown" or time out. A subsequent request to the same email may return "deliverable." This means verification results are not always deterministic on the first attempt. For bulk validation, this is handled with retry queues. For real-time signup validation, the result on the first attempt is what you get.

Disposable Email Detection: Beyond Domain Lists

Email-check.app detects 5,000+ disposable email domains. Detection is based on a maintained domain list rather than heuristic analysis. The API returns isDisposable: true for any address on a known temporary or throwaway domain (Mailinator, Yopmail, Guerrilla Mail, and thousands more).

A limitation: new disposable services appear regularly. If a disposable domain was registered after the last list update, it may not be caught. Teams with high fraud exposure should combine disposable detection with other signals: the domainAge field (domains under 30 days old are higher risk), isFree flag, and the composite score.

Typo Detection and Domain Suggestions

The suggestDomainfeature detects common domain typos and returns a correction suggestion. When a user types "john@gmial.com", the API returns:

curl -X GET "https://api.email-check.app/v1-get-email-details" \
  -H "accept: application/json" \
  -H "x-api-key: YOUR_API_KEY" \
  -G -d "email=john@gmial.com" -d "suggestDomain=true"

# Response (abbreviated)
{
  "email": "john@gmial.com",
  "validMx": false,
  "validSmtp": false,
  "validFormat": true,
  "domainSuggestion": {
    "original": "gmial.com",
    "suggested": "gmail.com",
    "confidence": 0.95
  },
  "score": 5
}

The confidence field (0-1) indicates how certain the suggestion is. Corrections with confidence above 0.8 are reliable enough to apply automatically in signup forms. Lower confidence suggestions should be presented to the user for confirmation.

Evaluation Framework: How to Compare Providers

When evaluating email verification APIs, test against a dataset that represents your actual traffic. Do not rely on the provider's self-reported benchmarks. Here is a testing framework:

Build a test set of 200-500 emails that represents your real traffic mix. Include known valid addresses from multiple providers (Gmail, Outlook, Yahoo, corporate domains), known invalid addresses, catch-all domain addresses, disposable addresses, role-based addresses, and addresses with common typos. Run this set through each provider you are evaluating and compare results.

Cost Per Verification: The Number That Actually Matters

Email-check.app pricing starts at $6.99/month for 6,000 credits — approximately $0.00117 per verification. The Business plan at $99.99/month includes 145,000 credits at $0.00069 per verification. Credits never expire on pay-as-you-go, and monthly plans reset each billing cycle.

The effective cost per verification depends on how you use the API. If you verify every email at signup (real-time) and also run bulk validation before campaigns (batch), your total volume determines the right plan. Compare providers by calculating: (monthly cost) / (total verifications needed per month). Include overage pricing in your calculation — some providers charge significantly more per verification once you exceed plan limits.

Frequently Asked Questions

How does email-check.app accuracy compare to competitors?

We recommend testing each provider against your own data set rather than relying on self-reported numbers. The email-check.app API returns structured results with validSmtp,validMx, validFormat, and a composite score that let you see the reasoning behind each result, making accuracy easier to audit.

Can I use the API for real-time signup validation?

The 25ms average response time is fast enough for synchronous signup flows. For best results, call the API on form submission (before creating the account) and use the isDisposable,score, and domainSuggestion fields to make immediate accept, reject, or correct decisions.

What happens with catch-all domains in bulk validation?

Catch-all addresses return validSmtp: truebut the overall status is "accept_all". In bulk workflows, you can segment these separately — send to confirmed deliverable addresses first, then decide on a case-by-case basis whether to include accept_all addresses in your campaign.

Does the API support bulk or batch verification?

The API processes individual requests. For bulk validation, you can upload CSV files through the dashboard or build batch processing in your application using concurrent API calls with rate limiting (100+ requests per second supported).