Validation Pipeline

Understand our 4-layer email validation process

4-Layer Validation Pipeline

GTMAPIs uses a 4-layer validation pipeline to produce canonical validation statuses, B2B quality signals, and credit charge metadata.

Pipeline Overview

Layer 1: Syntax Validation

Goal: Verify the email follows RFC 5322 format

Checks:

• Valid email structure (local@domain)
• Allowed characters and special cases
• Proper quoting and escaping
• Length constraints (64 chars for local, 255 for domain)

Examples:

• ✅ [e-mail]
• ✅ [e-mail]
• ❌ invalid@
• ❌ @domain.com
• ❌ spaces [e-mail]

If syntax validation fails, we immediately return invalid without proceeding to DNS/SMTP checks.

Layer 2: DNS Validation

Goal: Verify the domain can receive email

Checks:

• MX record lookup via DNS
• Fallback to A/AAAA records if no MX
• Domain existence verification
• DNS timeout handling (2s default)

Caching:

• MX lookups may be cached to reduce repeated DNS work
• Cache-first checks keep repeated validations consistent and efficient
• Provider-call budgets guard external validation work

Examples:

• ✅ gmail.com → MX records found
• ✅ company.com → MX records found
• ❌ fakeemail123notreal.com → No DNS records

# Example DNS lookup
dig +short MX gmail.com
# Returns: 5 gmail-smtp-in.l.google.com.

Domains without MX records but with A/AAAA records can still receive email via direct delivery. We handle this edge case.

Layer 3: SMTP Validation

Goal: Verify mailbox existence when the receiving server provides a reliable SMTP signal

Process:

1. Connect to mail server via SMTP (port 25)
2. Initiate SMTP conversation (HELO/EHLO)
3. Specify sender (MAIL FROM)
4. Attempt recipient verification (RCPT TO)
5. Parse server response

Provider-Specific Handling:

We’ve implemented smart detection for major providers:

Provider	Behavior	Our Approach
Gmail	Always returns 250 OK	Skip false positives, rely on syntax
Microsoft	Accepts all RCPT TO	Pattern-based detection
Yahoo	Rate limits aggressively	Backoff strategy
Custom	Varies widely	Standard SMTP validation

SMTP Response Codes:

• 250 - Mailbox exists ✅
• 550 - Mailbox doesn’t exist ❌
• 451/452 - Temporary failure (greylisting) ⏳
• 421 - Service unavailable 🔒

We don’t mark greylisted emails as invalid - they may become valid after retry.

SMTP is useful but not absolute. Some servers block recipient verification, temporarily reject checks, time out, accept first and bounce later, or return policy 5xx responses that do not prove whether the mailbox exists. GTMAPIs returns unknown for temporary, blocked, timed-out, or inconclusive SMTP outcomes and does not charge credits for them.

GTMAPIs does not recommend bypassing provider restrictions with aggressive probing. When a provider or network prevents reliable recipient verification, the conservative result is unknown.

Layer 4: Catch-All Detection

Goal: Identify domains that accept all emails (low value for outbound)

Detection Methods:

1. Random Address Testing

Send RCPT TO commands with random, obviously fake addresses:

RCPT TO: <[e-mail]>

If the server accepts it, that indicates catch-all behavior. It does not prove the specific mailbox exists.

2. Pattern Scoring

We analyze multiple signals:

• Response time consistency
• Multiple random addresses accepted
• Server banner analysis
• Known catch-all provider patterns

3. Confidence Scoring

{
  "is_catchall": true,
  "catchall_confidence": "high",  // or "medium", "low"
  "result": "risky"
}

Why Catch-Alls Are Risky:

• Can’t verify individual mailbox existence through standard SMTP checks
• Low B2B outbound certainty for the specific address
• Possible delivery uncertainty

Catch-all acceptance can look like a successful SMTP response, but it is not a confirmed personal mailbox. GTMAPIs marks catch-all results as risky rather than chargeable valid because the specific recipient remains unverifiable. See Catch-all detection vs recovery for how this differs from opt-in recovery scoring.

Catch-all emails are marked as risky and don’t consume credits since their outbound value is low.

Pipeline Performance

Validation latency depends on cache state, DNS behavior, SMTP server behavior, and provider-call budget availability. Transport failures are retried or surfaced as execution failures rather than persisted as synthetic unknown validation results.

Error Handling

Each layer has graceful degradation:

1. Syntax Fail → Return invalid immediately
2. DNS Fail → Return invalid (domain doesn’t exist)
3. SMTP Temporary, Blocked, Timeout, or Inconclusive → Return unknown (domain may receive email, but mailbox status is not proven)
4. Definitive SMTP Mailbox Reject → Return invalid (mailbox does not exist)
5. Catch-All Detected → Return risky (domain accepts broadly, so the specific mailbox is unverifiable)

Next Steps

B2B Quality Scoring

Learn how we score emails for outbound value

Result Categories

Understand all possible validation results

Catch-all Detection vs Recovery

Learn why catch-all detection is not mailbox proof.