What should a product team evaluate when choosing an email validation service?

Define validation as several separate checks

“Email validation” can mean client-side form checks, Internet Message Format parsing, domain existence, DNS mail-routing checks, an SMTP dialogue, historical bounce intelligence, disposable-domain classification, typo suggestions, or proof that a person controls an address. These jobs observe different facts. Begin with a written decision: blocking malformed signup input, warning about a probable typo, reducing repeated sends to permanently failed addresses, or reviewing an imported list with a lawful and expected purpose. Ask each vendor to name the exact evidence behind valid, invalid, risky, unknown, accept-all, disposable, role-based, and temporary results. A single green score should not silently combine syntax, third-party reputation data, and a remote server’s transient response. Keep the raw reason, check time, normalized input, and policy decision separate so the product can change its threshold without pretending the underlying observation changed.

Parse syntax without rejecting legitimate addresses

Internet email address syntax is broader than common web-form regular expressions. RFC 5322 defines message address syntax, while SMTP places transport requirements on mailbox and domain forms. Use a maintained parser and a modest early input check rather than a handcrafted expression that only accepts familiar consumer patterns. Preserve the user’s original address for display and audit, but normalize only rules the team can justify. Domain names are case-insensitive; local-part handling can be provider-specific, so lowercasing or removing punctuation can merge distinct mailboxes. Decide whether the product supports internationalized addresses and document that boundary explicitly. Syntax success means only that an address can be represented under the supported grammar. It cannot establish that the domain accepts mail, the mailbox exists, the person owns it, or the recipient requested messages. A validation vendor should return a syntax reason rather than replace an unusual but supported address without confirmation.

Check the domain and mail-routing evidence

Resolve the address domain through DNS and distinguish a usable mail route from a lookup failure. SMTP delivery normally uses MX records and defined fallback behavior, while RFC 7505 lets a domain publish a Null MX to state that it accepts no email. A service should report NXDOMAIN, Null MX, valid MX, implicit fallback, DNS timeout, SERVFAIL, and DNSSEC-related or resolver errors as different observations. Temporary resolver failure must not become a permanent invalid verdict. Capture the resolver time and final answer because DNS changes and caches make the result perishable. Domain-level success does not prove a particular mailbox exists. A valid MX can serve millions of addresses, route through a security gateway, accept all recipients, or defer checks until later. Require the vendor to expose the domain evidence instead of describing every domain with an MX record as a verified recipient.

Treat SMTP probing as uncertain and policy-sensitive

Some services connect to a destination SMTP server and issue enough of a transaction to observe recipient handling without transmitting message content. RFC 5321 defines commands and responses, but remote systems can disable verification commands, accept every recipient initially, reject probes, tarpit, greylist, rate-limit, vary by connecting IP, or delay recipient validation until after message acceptance. A `250` response to `RCPT TO` is evidence from one server at one time, not proof that the mailbox is monitored or will accept a later production message. A `4xx` response is temporary and should normally yield unknown or retry-later, not invalid. A `5xx` response needs the exact command stage and diagnostic before it supports a permanent-address decision. Ask whether the vendor identifies itself responsibly, limits traffic, respects server policy, uses real envelope identities, and prevents its probing infrastructure from causing reputation or abuse problems for customers.

Require explainable results and conservative automation

Define an internal result model before integrating a vendor. Useful dimensions include syntax state, domain state, MX state, Null MX, SMTP observation, enhanced status, accept-all evidence, disposable or role classification, typo suggestion, confidence, checked time, and data source. Keep `unknown` and `temporary` as first-class outcomes. Do not coerce them into valid merely to increase signups or invalid merely to simplify code. Reserve hard blocking for evidence the product has deliberately approved, such as impossible syntax, a Null MX domain, or a repeated and current permanent failure under the product’s policy. Use warnings or confirmation for probable typos. For ambiguous cases, verify ownership through the product’s normal confirmation flow or permit a controlled first send and process its outcome. Log which rule made the decision without storing more address history than support, fraud, privacy, and recipient-safety operations genuinely need.

Measure accuracy with a controlled and time-bound set

Build a test set whose ground truth the team can lawfully know: addresses in owned domains, controlled mailboxes, explicit non-existent recipients, Null MX domains, catch-all domains, Unicode cases within the supported boundary, syntax edge cases, and a server configured to return temporary responses. Run each vendor at the same time and retain the reason codes, not only the labels. Measure false blocks, false accepts, unknown rate, latency, result drift, and time to recover from temporary DNS or SMTP failure. Never test with purchased or scraped addresses. Avoid claiming a universal accuracy percentage from a narrow sample because domain mix, receiver policy, probing reputation, time, and address age affect observations. Recheck results after the vendor’s documented freshness window and after controlled domain changes. The proof period should validate decision usefulness and operational behavior, not create unsolicited traffic.

Keep validation separate from consent and sender reputation

An address can be syntactically valid, route to an active mailbox, and still be unsafe to contact. Google and Yahoo sender guidance emphasizes recipient choice, subscription expectations, complaint control, authentication, and list hygiene. No validation API can manufacture permission, prove that an imported address requested a message, repair misleading content, or protect reputation when recipients complain. Store consent source, message class, preference, suppression, and prior delivery history independently from validation. At send time, recipient-safety and authorization checks should take precedence over an old green validation result. Do not reactivate an unsubscribed, complained, or permanently bounced address merely because a vendor now labels it deliverable. Conversely, a temporary validation result should not erase verified ownership or a legitimate business workflow. Validation is one input to a documented decision, not an exemption from receiver policy or responsible sending practice.

Review privacy, security, and retention before uploading addresses

An address list is personal and commercially sensitive data, even when the service returns only a score. Ask where addresses are processed, whether they are stored, how long raw inputs and results persist, which subprocessors receive them, and whether they are reused for network intelligence, benchmarking, or model training. Prefer single-address or batch interfaces that minimize fields and support deletion, export, regional controls, and tenant isolation. Keep API keys in a secret manager, restrict them by environment and workload where possible, authenticate callbacks, and prevent addresses or credentials from entering analytics, URLs, terminal history, prompts, or broad logs. Batch uploads need authorization, size limits, malware-safe parsing, audit history, and expiry. Contractual deletion is not enough if exports, backups, debug traces, and derived reputation datasets remain unexplained. Test that one workspace cannot query another workspace’s validation history or infer whether an address appears in another customer’s data.

Evaluate the API and exit path as operational systems

Require stable request IDs, versioned reason codes, clear HTTP errors, idempotent batch creation, pagination, per-item state, rate-limit headers, retry guidance, webhook authentication, and documented maximum sizes. A timeout can leave a batch in an ambiguous state, so the client needs reconciliation rather than blind resubmission. Define how long results remain queryable and how the team exports original input hashes, normalized values, evidence, timestamps, and decisions when changing vendors. Check usage units carefully: per submitted address, unique address, completed result, retry, or enriched check can produce different costs. Test key rotation, revoked credentials, rate limits, partial batch failure, callback replay, delayed completion, deletion, and account closure. Preserve the product’s own result model so a vendor-specific label does not spread through business logic. Portability matters because historical validation decisions may be needed during support, fraud review, consent disputes, and provider migrations.

Use SendHQ for documented email capabilities

SendHQ's public documentation describes sending and receiving email, verifying domains, delivery events, and suppressions. It does not describe a pre-send recipient-address validation endpoint, mailbox-ownership proof, disposable-address classifier, or SMTP probing service. Use a dedicated validation service when you need those checks. SendHQ delivery events and suppressions can inform post-attempt recipient safety, but do not prove mailbox ownership or replace consent, suppression, or expected-recipient controls.

Frequently asked questions

Sources

• RFC 5321: Simple Mail Transfer Protocol — RFC Editor
• RFC 5322: Internet Message Format — RFC Editor
• RFC 7505: A Null MX No Service Resource Record for Domains That Accept No Mail — RFC Editor
• RFC 3463: Enhanced Mail System Status Codes — RFC Editor
• Gmail Email Sender Guidelines — Google
• Yahoo Sender Best Practices — Yahoo Sender Hub
• OWASP Input Validation Cheat Sheet — OWASP Foundation
• SendHQ OpenAPI Contract — SendHQ