> ## Documentation Index > Fetch the complete documentation index at: https://gtmapis.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Result Categories > Complete reference of all validation result types # Validation Result Categories GTMAPIs returns one of 5 possible validation results. Each result has specific meaning and recommended action. ## Result Types Overview Personal email, mailbox verified **Charged**: ✅ 1 credit Generic business inbox **Charged**: 🆓 FREE Catch-all domain, unverifiable **Charged**: 🆓 FREE Doesn't exist or syntax error **Charged**: 🆓 FREE Can't verify due to restrictions **Charged**: 🆓 FREE ## 1. Valid (Personal Email) **Result**: `valid` **Meaning**: Real personal email that passed all 4 validation layers **Validation Status**: * ✅ Syntax: Valid RFC 5322 format * ✅ DNS: MX records found * ✅ SMTP: Mailbox verified * ✅ Catch-All: Not a catch-all domain * ✅ Role-Based: Not a generic inbox **Example Response**: ```json theme={null} { "email": "john@company.com", "result": "valid", "reason": "", "is_role_based": false, "is_free_provider": false, "is_catchall": false, "b2b_outbound_quality": "high", "credits_charged": 1, "charge_reason": "Valid personal email with high B2B outbound quality" } ``` **Recommended Action**: ✅ **USE IN CAMPAIGNS** **B2B Outbound Value**: 🟢 **High** * Highest deliverability * Clear individual ownership * Direct access to individual * Worth the credit charge *** ## 2. Valid Role-Based **Result**: `valid_role_based` **Meaning**: Valid email but it's a generic business inbox **Validation Status**: * ✅ Syntax: Valid format * ✅ DNS: MX records found * ✅ SMTP: Mailbox exists * ⚠️ Role-Based: Generic inbox (info@, support@, etc.) **Common Patterns**: ``` info@, contact@, hello@, support@, help@, sales@, marketing@, admin@, office@, team@, hr@, careers@ ``` **Example Response**: ```json theme={null} { "email": "info@company.com", "result": "valid_role_based", "reason": "Role-based email address", "is_role_based": true, "role_type": "information", "b2b_outbound_quality": "low", "credits_charged": 0, "charge_reason": "Role-based email - free for low B2B value" } ``` **Recommended Action**: ⚠️ **USE WITH CAUTION** **B2B Outbound Value**: 🟡 **Low** * Deliverable but shared inbox * Lower individual attribution than personal emails * Multiple people may see it (or none) * Higher spam report risk * Good for: Company inquiries, not cold outreach *** ## 3. Risky (Catch-All) **Result**: `risky` **Meaning**: Domain accepts all emails, so the specific mailbox cannot be verified with confidence **Validation Status**: * ✅ Syntax: Valid format * ✅ DNS: MX records found * ⚠️ SMTP: Server accepts everything * ❌ Catch-All: Detected catch-all configuration **Detection**: ```bash theme={null} # Server accepts random addresses RCPT TO: 250 OK # ← This indicates catch-all behavior ``` **Example Response**: ```json theme={null} { "email": "anyone@catchall.com", "result": "risky", "reason": "Catch-all domain detected", "is_catchall": true, "catchall_confidence": "high", "b2b_outbound_quality": "none", "credits_charged": 0, "charge_reason": "Catch-all domain - cannot verify individual mailbox" } ``` **Recommended Action**: ❌ **AVOID IN CAMPAIGNS** **B2B Outbound Value**: 🔴 **None** * Unknown if mailbox actually exists * High bounce risk in practice * Damages sender reputation * Could be spam trap * May accept but not deliver Catch-all acceptance is different from a verified personal mailbox. The server may return a technically successful SMTP response for both real and fake recipients, so GTMAPIs returns `risky` instead of treating the address as chargeable `valid`. See [Catch-all detection vs recovery](/concepts/catch-all-detection-vs-recovery) for the distinction between detecting catch-all behavior and opt-in recovery scoring. **Confidence Levels**: * `high` - Very likely catch-all (avoid completely) * `medium` - Possibly catch-all (use with caution) * `low` - Uncertain (test with small batch first) *** ## 4. Invalid **Result**: `invalid` **Meaning**: Email doesn't exist or has syntax errors **Common Reasons**: ### Syntax Errors ```json theme={null} { "email": "invalid@", "result": "invalid", "reason": "Invalid email format", "validation_layer": "syntax" } ``` ### No DNS Records ```json theme={null} { "email": "john@fakeemail123notreal.com", "result": "invalid", "reason": "Domain has no MX records", "validation_layer": "dns" } ``` ### Mailbox Doesn't Exist ```json theme={null} { "email": "notreal@gmail.com", "result": "invalid", "reason": "Mailbox does not exist (SMTP 550)", "validation_layer": "smtp", "smtp_response": "550 5.1.1 User unknown" } ``` **Recommended Action**: ❌ **REMOVE FROM LIST** **B2B Outbound Value**: 🔴 **None** * Will hard bounce * Damages sender reputation * Wastes sending credits * No chance of delivery *** ## 5. Unknown **Result**: `unknown` **Meaning**: Unable to verify mailbox existence because the SMTP outcome is temporary, blocked, timed out, or otherwise ambiguous **Common SMTP Uncertainty Modes**: ### Greylisting ```json theme={null} { "email": "john@greylisted.com", "result": "unknown", "reason": "Temporary rejection - greylisting (SMTP 451)", "smtp_response": "451 4.7.1 Greylisting in action, please try again", "b2b_outbound_quality": "unknown", "credits_charged": 0 } ``` Greylisting returns a temporary rejection, usually a `4xx` SMTP response, to slow automated senders. The mailbox may exist after a retry window, so GTMAPIs does not mark the address `invalid` and does not charge a credit. ### Provider-Blocked Recipient Verification ```json theme={null} { "email": "john@restrictive.com", "result": "unknown", "reason": "SMTP verification not permitted", "smtp_response": "550 5.7.1 Recipient verification not allowed", "b2b_outbound_quality": "unknown", "credits_charged": 0 } ``` Some providers and corporate mail systems reject recipient verification even when they accept normal mail delivery. A response such as `550 5.7.1 Recipient verification not allowed` is not the same as `550 5.1.1 User unknown`, so GTMAPIs treats it as `unknown`. ### Temporary 4xx Responses ```json theme={null} { "email": "john@temporary-failure.com", "result": "unknown", "reason": "Temporary SMTP failure", "smtp_response": "452 4.2.2 Mailbox temporarily unavailable", "b2b_outbound_quality": "unknown", "credits_charged": 0 } ``` Temporary SMTP responses can come from greylisting, rate limits, mailbox throttling, overloaded servers, or policy checks. They are not definitive mailbox-existence signals. ### Inconclusive 5xx Responses ```json theme={null} { "email": "john@policy-protected.com", "result": "unknown", "reason": "SMTP policy rejection did not prove mailbox status", "smtp_response": "550 5.7.1 Recipient verification blocked by policy", "b2b_outbound_quality": "unknown", "credits_charged": 0 } ``` Definitive mailbox rejections such as `550 5.1.1 User unknown`, `551`, or `553` can support `invalid`. Policy rejections, anti-abuse blocks, and verification-disabled responses do not prove whether the mailbox exists, so they remain `unknown`. ### Timeout ```json theme={null} { "email": "john@slowserver.com", "result": "unknown", "reason": "SMTP connection timeout", "b2b_outbound_quality": "unknown", "credits_charged": 0 } ``` ### Cloud or Provider Connection Restrictions Some mail providers, hosting networks, and cloud environments restrict SMTP handshakes or recipient checks. GTMAPIs does not recommend bypassing these restrictions with aggressive probing. When provider restrictions prevent a reliable answer, the result is `unknown` and free. ### How `unknown` Differs From `risky` | Result | When it appears | What GTMAPIs knows | Credits | | --------- | ------------------------------------------------------ | ----------------------------------------------------------------------------- | ------- | | `unknown` | SMTP is blocked, temporary, timed out, or inconclusive | Domain may receive email, but mailbox status is not proven | 0 | | `risky` | Catch-all behavior is detected | Domain accepts addresses too broadly, so the specific mailbox is unverifiable | 0 | Both outcomes protect you from paying for ambiguous validation work. Only High-Value Validations consume credits: `valid` personal emails that are not role-based, catch-all, invalid, risky, or unknown. **Recommended Action**: ⚠️ **PROCEED WITH CAUTION** **B2B Outbound Value**: 🟡 **Unknown** * Domain exists (passed DNS) * Mailbox status uncertain * May deliver successfully * Test with small batch first * Monitor bounce rates For cost reporting, use `credits_reserved`, `credits_consumed`, `credits_refunded`, and `credits_per_high_value_validation` in bulk and async summaries. These fields show how many credits were held up front, how many were actually consumed by High-Value Validations, how many were returned for non-chargeable outcomes, and the effective credit cost per usable lead. *** ## Result Distribution Examples ### High-Quality B2B List ``` valid (personal): 60% ✅ Charged valid_role_based: 20% 🆓 Free risky (catch-all): 10% 🆓 Free invalid: 8% 🆓 Free unknown: 2% 🆓 Free ``` ### Low-Quality Scraped List ``` valid (personal): 15% ✅ Charged valid_role_based: 30% 🆓 Free risky (catch-all): 25% 🆓 Free invalid: 25% 🆓 Free unknown: 5% 🆓 Free ``` ## Decision Matrix | Result | Deliverable? | Credits | Use in Campaigns? | | ------------------ | ------------ | ------- | --------------------------- | | `valid` | ✅ Yes | 1 | ✅ Primary target | | `valid_role_based` | ✅ Yes | 0 | ⚠️ Secondary (low priority) | | `risky` | ❓ Unknown | 0 | ❌ Avoid | | `invalid` | ❌ No | 0 | ❌ Remove | | `unknown` | ❓ Maybe | 0 | ⚠️ Test carefully | ## Filtering Recommendations ### For Maximum Deliverability ```javascript theme={null} // Only use valid personal emails results.filter(r => r.result === 'valid') ``` ### For Budget Campaigns ```javascript theme={null} // Use valid + role-based (accepting shared inbox behavior) results.filter(r => r.result === 'valid' || r.result === 'valid_role_based' ) ``` ### For List Cleaning ```javascript theme={null} // Remove definite invalids and risky const toRemove = results.filter(r => r.result === 'invalid' || r.result === 'risky' ) ``` ## API Response Schema ```typescript theme={null} interface ValidationResult { // Core fields email: string; result: 'valid' | 'valid_role_based' | 'risky' | 'invalid' | 'unknown'; reason: string; // Detection flags is_role_based: boolean; is_free_provider: boolean; is_catchall: boolean; // B2B quality b2b_outbound_quality: 'high' | 'low' | 'none' | 'unknown'; // Credits credits_charged: 0 | 1; charge_reason: string; // Optional details role_type?: string; catchall_confidence?: 'high' | 'medium' | 'low'; validation_layer?: 'syntax' | 'dns' | 'smtp' | 'catchall'; smtp_response?: string; } ``` ## Next Steps Understand quality levels in depth Understand why catch-all detection returns `risky` and how recovery differs. Start validating emails