> ## 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.
# 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
```mermaid theme={null}
graph LR
A[Email Input] --> B[Layer 1: Syntax]
B --> C[Layer 2: DNS]
C --> D[Layer 3: SMTP]
D --> E[Layer 4: Catch-All]
E --> F[B2B Quality Score]
F --> G[Final Result]
```
## 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**:
* ✅ `john@company.com`
* ✅ `john.doe+tag@company.co.uk`
* ❌ `invalid@`
* ❌ `@domain.com`
* ❌ `spaces are@notallowed.com`
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
```bash theme={null}
# 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:
```
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
```javascript theme={null}
{
"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](/concepts/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
Learn how we score emails for outbound value
Understand all possible validation results
Learn why catch-all detection is not mailbox proof.