Normalize and validate
Practical syntax normalization and domain handling before network work begins.
FOR REVOPS / GTM ENGINEERING / OUTBOUND OPERATIONS
Your email list can pass verification and still damage your sender reputation.
You import or enrich a list, the verifier approves it, you send, hard bounces appear anyway, and the cost lands on your reputation. Then you go back to the verifier and all you have is a status or score.
MailCheck keeps the evidence behind every verdict — and publishes where it's wrong, not just where it's right. Join the waitlist for API access and the first open false-valid benchmark.
OPERATIONAL CONSEQUENCE
Bad verification uncertainty becomes a sending problem.
- Your source data looks clean.
- A verifier approves it.
- You send.
- Some addresses hard bounce.
- Good mail starts facing more throttling or worse placement.
- You troubleshoot with almost no evidence behind the original decision.
WHY ORDINARY OUTPUTS FAIL
A green check does not tell you whether the mailbox was actually accepted, whether the domain was catch-all, whether the provider was blocking verification, whether the verifier’s probe was degraded, or whether the result was already stale.
THE RESOLUTION
MailCheck treats email verification as an evidence problem, not just a scoring problem.
Instead of returning only a verdict, MailCheck preserves what was observed, which probe observed it, which classifier interpreted it, what limits certainty, and how fresh the result is.
ClassificationPROBABLE_VALID
FreshnessCURRENT
Probesmtp01
ProviderMicrosoft 365
Domain has MX
SMTP recipient accepted
Random mailbox rejected
DOMAIN_HAS_MX
SMTP_RCPT_ACCEPTED
RANDOM_RECIPIENT_REJECTED
SMTP acceptance does not guarantee future delivery.
HOW IT WORKS
Inspect DNS and MX
MailCheck records DNS and provider context instead of treating domain lookups as throwaway checks.
Perform bounded SMTP verification
Remote probe infrastructure collects SMTP evidence without sending DATA.
Preserve raw observations
Evidence stays replayable and probe-aware rather than being flattened into one opaque score.
Apply versioned classification
Reason codes, limitations, freshness and classifier lineage stay attached to the result.
Return an explainable decision
Mailbox status remains separate from contact admissibility and downstream delivery outcomes.
CURRENT CAPABILITIES
Evidence inspection
Review DNS, MX, SMTP, freshness, reason codes and limitations behind each verification.
Replayable classification
Historical classifications remain immutable while newer classifier versions can re-interpret the same evidence.
Catch-all handling
Catch-all behavior is preserved explicitly instead of being hidden behind a generic “risky” bucket.
Remote probe path
Production SMTP observations are collected through dedicated probe infrastructure, not from the primary app host.
WHY EVIDENCE, NOT JUST VALID/INVALID
Most lists carry hidden risk a binary check misses.
In a closed-beta validation of 93 real outbound contacts, only 41 were cleared by both a major verifier and internal policy. The rest carried catch-all, connection, or confirmed-invalid signal that a single "valid / invalid" score flattens away.
| Classification | Contacts |
|---|---|
| HIGH_CONFIDENCE_VALID | 43 |
| ACCEPT_ALL (catch-all) | 26 |
| CONNECTION_FAILED | 17 |
| Unverifiable / temporary | 4 |
| CONFIRMED_INVALID | 2 |
| Unavailable | 1 |
One episode. A major verifier scored an address valid, 100/100. MailCheck returned CONFIRMED_INVALID (SMTP recipient rejected). The partner's own send history showed a hard bounce. MailCheck preserved the rejected-SMTP evidence the other tool buried.
Design-partner validation (Nebula, closed beta, 93 contacts). A signal, not a claim of accuracy superiority — the public beta will measure false-valid rates at cohort scale.
EXPLICIT LIMITATIONS
- SMTP acceptance is not proof of future delivery.
- Catch-all domains may prevent conclusive mailbox validation.
- Remote providers can intentionally obscure mailbox validity.
- Verification results are time-sensitive.
- Mailbox validity does not establish permission to contact.
- Inbox placement and sender reputation depend on factors beyond mailbox validity.
DEVELOPERS / API
Evidence is available over the API, not just in the UI.
curl \
-H "Authorization: Bearer $MAILCHECK_API_KEY" \
-H "Content-Type: application/json" \
-d '{"email":"[email protected]"}' \
https://mailcheck.mikeholownych.com/api/v1/verifyWAITLIST — CLOSED BETA
Join the waitlist for provisioned API access — and the first published false-valid benchmark.
Registration is closed. Waitlist requests do not create a user, account, membership, session or API key. Members get first access to the API as seats open, plus the risk-layer benchmark report — the measured hard-bounce and false-valid rates across the cohort, published openly so you can see exactly where verification is wrong, not just where it's right. The benchmark is measured from real post-send outcomes reported by integrators (bounce, complaint, abuse); it publishes only once enough observed outcomes exist to be a real rate, not before.