Email Validation API: What to Look For Before You Integrate

Choosing an email validation API looks simple until you read the response. Almost every service can tell you whether an address is well formed and whether its domain has mail servers. Far fewer tell you whether the mailbox actually accepts mail, whether the domain is a throwaway provider, whether the result is uncertain, and why an address looks risky. If the API sits behind a sign-up or lead form, those differences decide how much manual review your team inherits. This checklist is vendor neutral. Use it to evaluate any email validation API, then see how Email Insights scores and flags against each item, so your team can make the call.

Why "Valid" Is Not the Same as "Trustworthy"

A syntactically valid address can still bounce. A deliverable address can still belong to a disposable inbox created for one sign-up. An address on a domain that accepts all mail can look deliverable even when the mailbox does not exist. Validation answers "can this address receive mail?" Risk assessment adds "should we trust this sign-up, and why?"

For a newsletter list, deliverability may be enough. For an account sign-up form, an onboarding flow, or a lead form that feeds a sales team, you also need signals about intent and quality, explained clearly enough that someone can review an edge case.

The Email Validation API Checklist

1. Deliverability Beyond Syntax and MX

Format and MX checks are table stakes. Look for:

• Mailbox-level verification that talks to the receiving mail server, not only DNS.
• An explicit "unknown" state. Mail servers often answer with temporary failures. RFC 5321 defines 4yz replies as "Transient Negative Completion," and greylisting relies on them. An API that forces every result into yes or no hides real uncertainty.
• Catch-all detection. Domains that accept mail for any address make mailbox checks inconclusive, and the response should say so.
• Mailbox-full and reachability signals, which help separate temporary problems from dead addresses.

2. Disposable and Provider Classification

Disposable providers change constantly. Ask how the API identifies them (static lists alone age quickly) and whether it distinguishes private domains from consumer mailbox providers. Our post on how disposable domains keep evolving covers why this needs ongoing updates.

3. Domain Intelligence and Authentication Posture

The sending domain says a lot about an address. Useful signals include domain age and registration data, appearance on domain reputation lists, SSL status, and email authentication records:

• SPF, defined in RFC 7208
• DKIM, defined in RFC 6376
• DMARC, defined in RFC 9989
• MTA-STS, defined in RFC 8461

A domain registered last week with no authentication records is a different risk from a long-established domain with a full authentication setup. See our explainer on email spoofing for why these records matter.

4. Address Structure Signals

The local part of an address carries information too:

• Role addresses such as those listed in RFC 2142 (for example, a shared support or sales mailbox) are often fine for business leads but unusual for individual sign-ups.
• No-reply patterns suggest an address nobody reads.
• Subaddress tags, the "+tag" convention described in RFC 5233, are legitimate but can be used to create many accounts from one inbox. A normalized address helps you spot duplicates.

5. Typo Correction With an Audit Trail

Typos such as a misspelled provider domain are a common cause of lost sign-ups. Look for correction suggestions you can show to the user, an option to apply corrections automatically only when you choose, and a record of the original input so you can audit what changed.

6. A Risk Score With Reasons

A single pass or fail flag cannot express "deliverable but disposable" or "valid but brand-new domain." Look for:

• A numeric score with defined ranges and levels.
• Reason codes that explain the score in plain terms.
• Clear documentation of how levels map to score ranges.

Explainability matters most when a real customer gets flagged. Your support team needs to see why, and your policy needs to decide what happens next.

7. Real-Time and Batch Options

Most teams need both: a fast single-address call at the point of capture, and a batch path for imports, CRM hygiene, and periodic list review. For batch, check accepted file formats, payload limits, how you track job status, and how results are delivered.

8. Authentication and Integration Hygiene

• Credentials in a header, never in the URL. The OWASP API Security Top 10 flags APIs that send tokens "in the URL."
• Personal data in the request body, not in query strings that end up in logs.
• Support for multiple keys and rotation, plus network restrictions such as IP allowlists.
• Documented error codes and rate-limit behavior, including a Retry-After header for 429 responses.
• Maintained SDKs for the languages you use.

9. Data Handling and Security Posture

You are sending personal data to a third party. Ask for a security page, a Data Processing Addendum, a sub-processor list, and a vulnerability disclosure policy, and check whether outputs are advisory or automated decisions.

How Email Insights Scores and Flags Against the Checklist

Email Insights analyzes each address across eight dimensions: risk scoring, mailbox verification, domain intelligence, email authentication posture, MX relay detection, suspicious pattern detection, address signal intelligence, and auto-correction. Each analysis returns signals and a score. Email Insights scores and flags; your team decides what to do with each result.

Mapping Checklist Items to Response Fields

The field names below are copied from the Analyze Email API reference.

Checklist item	Email Insights response fields
Deliverability	isDeliverable (yes, no, or unknown), isReachable, isCatchAll, isMailboxFull, isFormatValid
Provider classification	emailType (private, free, or disposable), emailProvider
DNS and authentication	emailDNS: mx, spfValid, dkimConfigured, dmarcValid, mxRelay, mxRelayCategory
Domain intelligence	domain: creationDate, expirationDate, ageYears, registrar, isBlockListed, sslValid, mtaStsStatus, bimiStatus, hasVMC, aRecordValid
Address structure	addressSignals: isRoleAddress, roleType, isNoReply, noReplyPattern, tagDetected, tagValue, normalizedAddress
Typo correction	emailCorrection, emailAutoCorrectedFrom
Risk score with reasons	riskReport: score, level, baseAnalysis

Deliverability and Uncertainty

Email Insights runs a real-time SMTP probe and returns a tri-state isDeliverable value. Our FAQ lists common reasons for unknown: greylisting, temporary network issues, and anti-spam protections on the receiving server. Per our Email Insights product page, an async retry pipeline handles greylisting, rate limiting, and transient failures for inconclusive results. When isCatchAll is true, the FAQ notes that a deliverable result does not always confirm that the specific address is valid, so you can weigh it accordingly.

Typo Correction You Control

The request body accepts enableAutoCorrection, which defaults to false. Correction covers common domain typos for 100+ major providers. When a correction is applied, emailAutoCorrectedFrom keeps the original input for your audit trail. Our FAQ recommends showing suggestions to the user for confirmation and auto-correcting only with a controlled allowlist.

The Explainable Risk Report

When enableAI is true (the default), the response includes a riskReport object with a score from 200 (lowest risk) to 1000 (highest risk), a level, and baseAnalysis reason codes. The product page describes up to 3 ranked reason codes per analysis, drawn from 30+ weighted signal factors. Examples from our assessed signals reference include disposable-domain, catch-all-domain, role-address, noreply-detected, and spoofing-risk.

Level	Score range
lowest	300 or below
low	301 to 400
medium	401 to 600
high	601 to 800
highest	Above 800

Some conditions set a minimum level. Per our FAQ, disposable domains, undeliverable states, missing MX records, and no-reply detections cannot be scored below high. For security reasons, the full signal list and internal weights are not published. For a deeper look, read how the email risk score works.

What you do with each level is your decision. For example, you might send highest results to a review queue, ask the user to confirm the address on medium results, and keep lower levels in your normal flow, then tune from there.

Real-Time and Batch

For single addresses, call POST /email/analyze. For lists, POST /email/batch accepts a JSON emails array, a CSV, TSV, or XLSX file upload, or plain text, and returns 202 with a jobId. You then poll GET /email/batch/{jobId} for status and progress, and download results from downloadUrls (csv, json, csvCompressed, jsonCompressed). The FAQ sets a 3 MB payload limit per request and notes that download URLs are time-limited. To pull a filtered subset, POST /email/batch/{jobId}/exports accepts exportType, filters, and columns. Read more on bulk email validation.

Authentication and Integration

Requests authenticate with the x-opportify-token header. The API reference states that the API avoids query parameters for all operations, including authentication and personal data, and sends sensitive information only in headers or the request body. ACL Rules let you restrict API access to listed IP addresses. The FAQ covers key rotation with a brief overlap, honoring Retry-After on 429 responses with exponential backoff, and not retrying other 4xx errors. SDK guides are available for Node.js, Python, and other languages.

Data Handling and Security

Our Trust Center lists our access, data protection, and API security controls, along with our certification status. Our Data Processing Addendum and sub-processor list are public, and our Terms and Conditions state that output scores are advisory.

Quick Start

This request, from our documentation, analyzes a single address:

curl -X POST https://api.opportify.ai/insights/v1/email/analyze \
  -H "x-opportify-token: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email": "test@example.com"}'

Optional body fields include enableAI (default true), enableAutoCorrection (default false), and enableDomainEnrichment (default true).

Getting Started

1. List your capture points. Sign-up, onboarding, lead, and checkout forms each carry different risk.
2. Score the checklist. Run your candidate APIs against the nine items above with a sample of real and known-bad addresses.
3. Start in observation mode. Log scores and reason codes for a week or two before acting on them.
4. Write your policy. Decide what each risk level means for each form, and who reviews flagged cases.
5. Add batch hygiene. Schedule periodic batch runs for imported and older contacts.

See the Email Insights product page for details and pricing for current plans.

Key Takeaways

• Syntax and MX checks are table stakes. Mailbox verification, an honest unknown state, and catch-all detection matter more.
• Disposable, domain, authentication, and address-structure signals separate deliverable addresses from trustworthy ones.
• A risk score is only useful with reason codes your team can read and act on.
• Look for both real-time and batch paths, header-based authentication, and clear rate-limit behavior.
• The API should score and flag. Your team decides.