When you call the Emailyze API to check an email address, the response contains multiple signals that together paint a complete picture of that address. No single field tells you everything—you need to interpret them in combination. This guide documents all 13 response fields, explains their meaning and values, and shows when and how to use each one effectively.
The API returns a JSON object with fields like is_disposable, provider_type, risk_score, and more. Each signal contributes different information: some are primary decision signals (block or allow), others provide context (why is this risky?), and some are metadata (how fresh is the data?). For signup blocking, is_disposable and risk_score are usually the main drivers. For deliverability, mx_valid, smtp, and catch_all matter more. For tuning thresholds, you'll want to understand all of them.
is_disposable — A boolean indicating whether the domain is a known disposable or temporary email provider. When true, the domain has been identified in our curated lists (e.g., tempmail.com, guerrillamail.com, mailinator.com). This is the most direct signal for blocking at signup: if is_disposable is true, you can confidently block or flag the address. When false, the domain is either a known non-disposable provider (Gmail, Outlook, etc.) or unknown. For unknown domains, rely on risk_score and other signals.
provider_type — A string categorizing the email provider. Values include: disposable (throwaway providers like tempmail, guerrillamail), personal (consumer services like Gmail, Outlook, Yahoo), freemail (same as personal in practice), masked (Apple Hide My Email, Firefox Relay—these forward to real addresses), and unknown (not in our lists). Use this to differentiate policy: you might block disposable, allow personal and freemail, and treat masked with special logic (e.g., allow but log). For unknown, combine with risk_score and sources.
risk_score — A number from 0 to 100. Higher values indicate a higher likelihood of disposable or risky usage. Domains with risk_score >= 80 are typically high risk; 31–79 is medium; 0–30 is low. Use thresholds based on your tolerance: strict signup flows might block at 50+, while list cleaning might only flag 80+. The score is derived from our domain lists, MX analysis, and behavioral patterns. It's useful when is_disposable is false but the domain is still suspicious.
mx_valid — A boolean indicating whether the domain has valid MX (Mail Exchange) records and can receive email. When true, the domain is configured to accept mail. When false, there are no MX records or they're invalid—the address may not be deliverable. Use this for list hygiene: invalid MX often means dead or misconfigured domains.
mx_provider — A string or null identifying where the domain's mail is hosted, inferred from MX records. Common values: google, microsoft, yahoo, amazon_ses, sendgrid, mailgun, zoho, protonmail, fastmail, icloud, postmark, mailchimp, rackspace, godaddy, ovh. When null, the provider couldn't be identified or the domain has custom MX. Use this to understand infrastructure: known providers (Google, Microsoft) are typically trustworthy; unknown or null may warrant extra scrutiny.
smtp — An object with live SMTP checks (when ?verify=true is used). Fields: can_connect_smtp (boolean), is_catch_all (true/false/null), is_deliverable (true/false/null), is_disabled (true/false/null), has_full_inbox (true/false/null). These require an extra SMTP probe and add latency. Use for high-stakes decisions: is_deliverable confirms the mailbox exists; is_catch_all indicates the domain accepts any address.
local_part_type — A string or null describing the local part (the part before @). Values: role (info@, support@, admin@—shared inboxes), plus_addressing (user+tag@domain.com—filtering/aliasing), numerical (mostly digits—often auto-generated or temporary), standard (normal personal address), or null (domain-only input). Role addresses and numerical patterns can indicate business or bot usage; plus addressing is common for power users. Use for context: numerical combined with high risk_score may justify blocking.
catch_all — true, false, or null. When true, the domain accepts mail for any address (catch-all). When false, unknown addresses are rejected. When null, the probe wasn't run or failed. Catch-all domains are higher fraud risk because anyone can receive mail at any address. Use with caution: some legitimate small businesses use catch-all. Combine with risk_score and is_disposable.
syntax — An object with parsed email components: domain, username, is_valid_syntax, and suggestion (typo correction if applicable). Use for validation: is_valid_syntax confirms RFC-compliant format. The suggestion field can help correct common typos (e.g., gmail.con → gmail.com).
first_seen — Date when we first saw this domain in our data feeds. Older domains may be more established; newer ones might be newly created disposable services.
last_seen — Date when we last saw this domain. Stale last_seen could indicate abandoned or defunct domains.
sources — Array of source names that contributed this domain (e.g., "disposable-email-domains", "github-lists"). Use to understand provenance: multiple sources increase confidence.
latency_ms — Response time in milliseconds. Typically under 50ms with caching. Useful for monitoring and SLA.
is_disposable === true or risk_score >= 80 (adjust threshold as needed).provider_type === "masked"—these forward to real addresses.mx_valid, smtp.is_deliverable, and risk_score to prioritize removals.provider_type === "unknown" with risk_score and optional smtp verification for critical flows.A typical API response might look like: {"email":"user@tempmail.com","domain":"tempmail.com","is_disposable":true,"provider_type":"disposable","risk_score":95,"mx_valid":true,"mx_provider":null,"local_part_type":"standard","catch_all":null,"syntax":{"domain":"tempmail.com","username":"user","is_valid_syntax":true,"suggestion":null},"smtp":{...},"first_seen":"2022-03-15","last_seen":"2024-11-20","sources":["disposable-email-domains","github-lists"],"latency_ms":12}. Here, is_disposable and risk_score clearly indicate a disposable domain; you would block. For user@gmail.com, you'd see is_disposable:false, provider_type":"freemail" or "personal", risk_score low, and mx_provider":"google" — allow. For an unknown domain with risk_score:45, you might warn or require additional verification. The key is combining signals rather than relying on one.
When tuning risk_score thresholds, start conservative (e.g., block at 90+) and gradually lower based on your false-positive tolerance. Monitor blocked users and support tickets. For B2B or high-value signups, consider allowing with manual review instead of hard blocking. Use A/B tests to compare conversion impact. The sources array helps with debugging: if a domain appears in multiple reputable lists, confidence is higher. Remember that latency_ms can spike during cold caches or under load; design your integration to handle timeouts gracefully. When smtp is present, is_catch_all there can override or confirm the top-level catch_all; prefer the SMTP value when available since it's from a live probe.