WHAT: Validate email addresses for deliverability risk: RFC-style syntax, domain existence and MX records (DNS-over-HTTPS), null MX, disposable/temporary inbox domains, role accounts (info@, sales@), free webmail providers, common domain typos with a "did you mean" suggestion, and optional SPF/DMARC presence and policy. WHEN TO USE: cleaning signup or lead lists, checking an address before sending, flagging throwaway or typo signups. WHEN NOT TO USE: for a quick offline format check or parsing "Name " strings use check_email_syntax (free). Does NOT send email or do SMTP mailbox probing, so it cannot confirm that a specific mailbox exists. BEHAVIOR: runs the Fairquery Apify Actor fairquery/email-validator-mx-disposable via the Apify API (DNS lookups via Cloudflare DoH). Requires APIFY_TOKEN. Duplicates (case-insensitive) are skipped. Typical run 3-30 s. COST: paid (billed to your Apify account, pay-per-event): $0.00005 per run + $0.00079 per email row with a verdict; error rows are free. 100 emails ~ $0.08. RETURNS: one email row per unique address; verdict follows reasons[]: INVALID_SYNTAX, DOMAIN_NOT_FOUND, NULL_MX, NO_MAIL_SERVER -> invalid; DISPOSABLE_DOMAIN, ROLE_ACCOUNT, FREE_PROVIDER (per allow* flags), POSSIBLE_TYPO, IMPLICIT_MX_ONLY -> risky; DNS_NOT_CHECKED -> unknown. Error rows are free and never sit next to an email row for the same address: INPUT_EMPTY (nothing to check), MAX_EMAILS_EXCEEDED (once, for the overflow), DNS_LOOKUP_FAILED (one per address whose domain lookup failed, instead of its email row; retryable=true for transient DNS errors, so resend only those addresses). PARAMETERS: emails: entries are split on commas, semicolons and newlines, trimmed, reduced from "Name " to addr, and case-insensitive duplicates are skipped before checking, so a pasted list in one element works and you pay once per unique address; maxEmails caps that unique count (extras get one free MAX_EMAILS_EXCEEDED row), which makes it your spend cap. checkDns=false skips all DNS lookups: domain_exists / has_mx stay null and an address that is otherwise clean gets verdict "unknown" (DNS_NOT_CHECKED) instead of "valid" - it is still billed. checkSpfDmarc only adds has_spf / has_dmarc / dmarc_policy and never changes the verdict; it is ignored when checkDns=false. The three allow* flags only decide whether a condition downgrades an otherwise valid address to "risky": the reason code (ROLE_ACCOUNT, DISPOSABLE_DOMAIN, FREE_PROVIDER) is listed in reasons[] either way, and no flag can rescue an "invalid" address (bad syntax, DOMAIN_NOT_FOUND, NULL_MX, NO_MAIL_SERVER). POSSIBLE_TYPO and IMPLICIT_MX_ONLY are always "risky". Presets: B2B lead list = allowFreeProviders false + allowRoleAccounts false; consumer signups = defaults. EXAMPLE: {"emails":["someone@gamil.com"]} -> verdict "risky", reasons ["POSSIBLE_TYPO"], did_you_mean "someone@gmail.com".

WHAT: Check whether strings are syntactically valid email addresses and normalize them (extracts "Name ", lowercases the domain), entirely locally. WHEN TO USE: fast pre-filtering or parsing before calling validate_emails, or when only the format matters. WHEN NOT TO USE: it does not check that the domain exists, has MX records, is disposable, a role account or a typo - use validate_emails (paid) for deliverability. COST: free; pure local function, no network, no APIFY_TOKEN. BEHAVIOR: synchronous and CPU-bound, no rate limit; 10,000 addresses return in well under a second. RETURNS: one "email_syntax" row per input element; reason is null or INVALID_SYNTAX. PARAMETERS: emails: each element is checked on its own and returns exactly one row, in input order (no splitting of comma/semicolon lists, no deduplication - unlike validate_emails). Normalization before checking: surrounding whitespace is trimmed, a trailing "Name " is reduced to addr, and the domain is lowercased (the local part keeps its case). Syntax rules: total <= 254 chars, local part <= 64 chars with no leading/trailing or double dot, domain labels of letters/digits/hyphens and a 2-63 letter TLD; quoted local parts, IP-literal domains and non-ASCII (IDN) addresses are reported as INVALID_SYNTAX here. input always echoes the original string so you can map rows back. EXAMPLE: {"emails":["Jane jane@Example.com"]} -> email "jane@example.com", syntax_valid true, domain "example.com".