Troubleshooting verification result issues

Verification results that do not match your expectations usually fall into one of a few categories. This page goes symptom-by-symptom, with the actual reason for each behavior.

"This address should be valid but came back invalid"

Possible causes, in rough order of frequency:

The mailbox really does not exist

Hard as it is to believe sometimes, the most common cause of an invalid result is that the address genuinely does not exist on the server. The 11-step engine confirms mailbox existence via SMTP RCPT TO — if the server returns 550 mailbox not found, the result is invalid and it is right.

Things that look like valid addresses but are not:

• Internal-only aliases that exist in the company directory but do not accept external mail.
• Catch-rule placeholders that look like real addresses.
• Test/dev addresses that were never wired up to a real mailbox.
• Recently-deleted accounts where the mailbox was removed but the directory entry remains.

The recipient server is misconfigured

A small number of mail servers return 550 for every address until the sender warms up — a misguided anti-spam pattern. The engine usually catches this and downgrades to unknown instead of invalid, but a server that returns 550 cleanly without flagging anti-spam markers can fool the engine into reporting invalid. If you have ground-truth that the address is real, contact support — we can re-run with different routing.

Typos that look right at a glance

Always worth a sanity check before assuming the engine is wrong:

• gmial.com instead of gmail.com
• yahooo.com instead of yahoo.com
• hotmial.com instead of hotmail.com
• outlook.co instead of outlook.com

"Why is this address `catch_all` — it should be Safe"

The engine downgrades any otherwise-Safe result to catch_all when it detects the domain accepts mail to any local-part. The detection works by probing with a random nonsense address and seeing if the server still says yes. If yes → catch-all flag applies.

On a catch-all domain, the engine cannot tell whether the specific recipient is real, because the server says yes to everything. The result is honest signalling — your address probably exists, but we cannot confirm from the outside. Test small batches before bulk-sending to catch-all results. See catch-all complete guide.

"My results are missing some addresses I uploaded"

If your output file is smaller than your input, the most likely cause is duplicate removal. The bulk pipeline auto-strips duplicates before charging credits or running verification (the Remove Duplicates toggle is on by default). The notification right after upload tells you exactly how many duplicates were stripped.

Other causes:

• Addresses with whitespace/formatting issues that did not parse as valid emails (those are silently skipped).
• Addresses that landed in the unprocessed file because the engine could not reach the server (downloadable separately on the Verification Details page; credits refunded automatically).
• Multi-line cells in the original file that got concatenated incorrectly during CSV parsing.

"I see Unknown results but no refund in my credit history"

Refunds for unknown results are applied at the end of the job, not per-address. For a single bulk task with 50 unknowns, you see one refund row in the credit history for the total (50 credits) rather than 50 separate rows. Check around the timestamp of the task completion — the refund is right there.

If you genuinely see unknown results with no corresponding refund, that is a bug. Email support@validemailchecker.com with the task ID.

"This result is different from what another verifier said"

Different verifiers can return different statuses for the same address. The most common reasons:

• Time of check matters. A mailbox can be active when verifier A checked and disabled when verifier B checked an hour later.
• Different definitions. Some verifiers report all role accounts as valid; we flag them separately as role_account.
• Different catch-all detection. Verifiers vary in how aggressive their catch-all probing is. We use a random nonsense probe; some others only flag based on heuristics.
• Different default behavior on uncertainty. Some verifiers default to valid when in doubt; we default to unknown and refund the credit.

Cross-verifier disagreement is normal. The right test is: which verifier's results correlate with your actual bounce rate on safe-marked sends?

"I can't see my results after 15 days"

15-day retention is automatic and unrecoverable. After the deadline, the gdpr-cleanup function wipes the raw verification data; only aggregate stats remain (total count, success rate). Download results within the window. If you missed the window, the only way to recover the per-row data is to re-verify the original list — credits will be charged again because the engine has no cached results to reuse.

"My API call returns different fields than my dashboard results"

The API returns boolean flags (is_disposable, is_catch_all, etc.) and a risk_score (0–100, higher = riskier). The dashboard CSV exports include the same data but with Yes/No values for the flags and the inverse score (confidence, 0–100, higher = safer). It's the same engine output; just different formatting per surface. See single verification endpoint for the API response shape.

"My signup form passes obviously fake addresses"

If you wired the single-verify API into a signup form and are still seeing fake addresses register, common configuration mistakes:

• Form validation only on the client side — bypass with curl/postman.
• Form validates email format but does not call our API.
• Form calls the API but does not reject on disposable / invalid — only on syntactic errors.
• Form rate-limit on signup is too generous, so bots can still get through after some bounced attempts.

See the API single-verification guide for the recommended integration pattern.

Next steps