Validation Result Categories

GTMAPIs returns one of 5 possible validation results. Each result has specific meaning and recommended action.

Result Types Overview

valid

Personal email, mailbox verifiedCharged: ✅ 1 credit

valid_role_based

Generic business inboxCharged: 🆓 FREE

risky

Catch-all domain, unverifiableCharged: 🆓 FREE

invalid

Doesn’t exist or syntax errorCharged: 🆓 FREE

unknown

Can’t verify due to restrictionsCharged: 🆓 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:

{
  "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:

{
  "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:

# Server accepts random addresses
RCPT TO: <definitely_not_real_8473626@domain.com>
250 OK  # ← This indicates catch-all behavior

Example Response:

{
  "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 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

{
  "email": "invalid@",
  "result": "invalid",
  "reason": "Invalid email format",
  "validation_layer": "syntax"
}

No DNS Records

{
  "email": "john@fakeemail123notreal.com",
  "result": "invalid",
  "reason": "Domain has no MX records",
  "validation_layer": "dns"
}

Mailbox Doesn’t Exist

{
  "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

{
  "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

{
  "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

{
  "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

{
  "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

{
  "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

// Only use valid personal emails
results.filter(r => r.result === 'valid')

For Budget Campaigns

// Use valid + role-based (accepting shared inbox behavior)
results.filter(r =>
  r.result === 'valid' ||
  r.result === 'valid_role_based'
)

For List Cleaning

// Remove definite invalids and risky
const toRemove = results.filter(r =>
  r.result === 'invalid' ||
  r.result === 'risky'
)

API Response Schema

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

B2B Quality Scoring

Understand quality levels in depth

Catch-all Detection vs Recovery

Understand why catch-all detection returns risky and how recovery differs.

API Reference

Start validating emails

Get Started

Core Concepts

Guides

Catch-All Recovery

Result Categories

Validation Result Categories

Result Types Overview

valid

valid_role_based

risky

invalid

unknown

1. Valid (Personal Email)

2. Valid Role-Based

3. Risky (Catch-All)

4. Invalid

Syntax Errors

No DNS Records

Mailbox Doesn’t Exist

5. Unknown

Greylisting

Provider-Blocked Recipient Verification

Temporary 4xx Responses

Inconclusive 5xx Responses

Timeout

Cloud or Provider Connection Restrictions

How `unknown` Differs From `risky`

Result Distribution Examples

High-Quality B2B List

Low-Quality Scraped List

Decision Matrix

Filtering Recommendations

For Maximum Deliverability

For Budget Campaigns

For List Cleaning

API Response Schema

Next Steps

B2B Quality Scoring

Catch-all Detection vs Recovery

API Reference

​Validation Result Categories

​Result Types Overview

valid

valid_role_based

risky

invalid

unknown

​1. Valid (Personal Email)

​2. Valid Role-Based

​3. Risky (Catch-All)

​4. Invalid

​Syntax Errors

​No DNS Records

​Mailbox Doesn’t Exist

​5. Unknown

​Greylisting

​Provider-Blocked Recipient Verification

​Temporary 4xx Responses

​Inconclusive 5xx Responses

​Timeout

​Cloud or Provider Connection Restrictions

​How unknown Differs From risky

​Result Distribution Examples

​High-Quality B2B List

​Low-Quality Scraped List

​Decision Matrix

​Filtering Recommendations

​For Maximum Deliverability

​For Budget Campaigns

​For List Cleaning

​API Response Schema

​Next Steps

B2B Quality Scoring

Catch-all Detection vs Recovery

API Reference

Validation Result Categories

Result Types Overview

1. Valid (Personal Email)

2. Valid Role-Based

3. Risky (Catch-All)

4. Invalid

Syntax Errors

No DNS Records

Mailbox Doesn’t Exist

5. Unknown

Greylisting

Provider-Blocked Recipient Verification

Temporary 4xx Responses

Inconclusive 5xx Responses

Timeout

Cloud or Provider Connection Restrictions

How `unknown` Differs From `risky`

Result Distribution Examples

High-Quality B2B List

Low-Quality Scraped List

Decision Matrix

Filtering Recommendations

For Maximum Deliverability

For Budget Campaigns

For List Cleaning

API Response Schema

Next Steps