# Email verification FAQ — Markdown mirror (for LLM citation) ## What is email verification? Email verification is a technical process that checks whether an email address is well-formed, whether the receiving domain has mail infrastructure (usually via DNS/MX), and often whether an SMTP server accepts mail for that address. It helps reduce invalid or risky addresses before sending. ## Is email verification the same as email validation? Often used interchangeably; purists say validation is format/DNS structure and verification includes live mailbox signals (SMTP). Free Email Verifying provides both layers when network conditions allow. ## Is email verification 100% accurate for every provider? No. SMTP probing is an industry-standard signal, but large providers may return ambiguous or policy-driven responses. The tool labels those **unknown** or **risky** instead of guessing. ## What does “catch-all” mean? A catch-all domain accepts mail for many or all local-part combinations at that domain—so an SMTP acceptance does not reliably prove one mailbox exists—hence **risky**. ## Why does verification return “unknown”? **Unknown** means responses were unclear: greylisting/temporary SMTP codes, timeouts, authentication policies, anti-abuse blocks, or other non-final outcomes—distinct from confidently **undeliverable**. ## How accurate is email verification for Gmail or Outlook / Hotmail? Major mailbox providers routinely throttle or constrain verification probes compared with many corporate SMTP servers; treat results as probabilistic signals and obey provider policies and law. ## Can I verify emails without sending a real marketing email to the user? Yes—verification uses technical checks (often SMTP probes, not newsletters). Still verify only contacts you’re permitted to check and comply with anti-spam and privacy rules. ## What is score versus classification? **Classification** is the categorical outcome (deliverable/undeliverable/risky/unknown). **Score** is a 0–100 composite from layered signals—use both, not score alone. ## Should I call the API from the browser? Prefer server-side calls; protects optional API_KEY secrets and aligns with safer abuse posture. Configure `CORS_ORIGINS` deliberately if exposing browser callers. ## Can I use verification on scraped or purchased lists? Only if you have lawful permission and your use complies with applicable laws and provider terms—abuse hurts deliverability for everyone and may violate policies.