Email Validation
Every lead is validated through a multi-stage pipeline before any send is allowed
What Superkabe Validation Does
Every lead that lands in Superkabe — from a Clay webhook, an API call, or a CSV upload — is run through the same validation pipeline before it can enter a campaign. Invalid, disposable, and high-risk addresses are blocked at the door so they never reach your sending mailboxes. This is the single biggest contributor to keeping bounce rates below the 3% threshold that triggers an auto-pause downstream.
Validation runs as a five-stage pipeline. Each stage is gated on the previous one — if a check rejects an address, the later stages are skipped. The first four stages are Superkabe-internal and free; the fifth stage (MillionVerifier API) is reserved for risky leads on Growth and Scale tiers.
Pipeline Stages
- 1. Syntax check — RFC-compliant address parsing. Rejects malformed addresses (missing @, invalid characters, bad TLD).
- 2. MX record lookup — confirms the recipient domain has at least one mail server registered in DNS.
- 3. Disposable domain detection — checks against the maintained list of throwaway providers (mailinator, guerrillamail, 10minutemail, etc.).
- 4. Catch-all detection — probes the destination MX to determine whether the domain accepts every address. Catch-all domains are flagged as risky.
- 5. MillionVerifier API — risky-only deep verification on Growth and Scale tiers. Returns a definitive deliverability status from a real-time external check.
Validation Status Meanings
Every validated email returns one of five statuses. The status determines how the Health Gate routes the lead.
| Status | Meaning | Health Gate Routing | What You Can Do |
|---|---|---|---|
valid | Address exists, accepts mail, low bounce risk. | GREEN — full send. | Nothing. Send normally. |
risky | Catch-all domain, role-based address, or low engagement signals. | YELLOW — risk-capped send. | Send with caps, or remove from list if you want pristine deliverability. |
invalid | Syntax failure, missing MX, or disposable provider. | RED — blocked. | Remove from your source list. This address will bounce 100%. |
unknown | Verifier could not reach a definitive answer (greylisting, timeout). | YELLOW — treated as risky. | Re-validate manually after 24 hours. Often resolves to valid or invalid. |
pending | Async validation in flight (MillionVerifier call queued). | HELD — waiting on result. | Poll /api/v1/validation/results — typical resolution in 2-5s. |
Credit Consumption Rules
Stages 1 through 4 of the pipeline (syntax, MX, disposable, catch-all) are Superkabe-internal and consume no credits. Only the MillionVerifier call in stage 5 consumes credit, and only on Growth and Scale tiers. Each MillionVerifier call costs 1 credit. Re-validating the same email within 30 days returns the cached result for free.
| Tier | Price | Credits / month | MillionVerifier? | API Access |
|---|---|---|---|---|
| Starter | $19/mo | 3,000 | No (stops at catch-all) | No |
| Pro | Volume-tiered | 10,000 – 50,000 | No (stops at catch-all) | No |
| Growth | $199/mo | 60,000 | Yes — risky leads only | Yes |
| Scale | $349/mo | 100,000 | Yes — risky leads only | Yes |
30-Day Cache
Validation results are cached per organization for 30 days. If the same email is submitted again inside that window, Superkabe returns the cached result instantly and consumes zero credit. Cache hits don't count against your monthly allotment, regardless of how many times you re-submit.
Tier Interaction with the Pipeline
Not every tier runs the full five stages. Starter and Pro tiers stop at stage 4 (catch-all detection). Growth and Scale extend the pipeline to stage 5, but only for leads that came out of stage 4 flagged as risky — clean valid leads never trigger an API call.
Why MillionVerifier is risky-only
Calling MillionVerifier for every single lead would burn credits on addresses that are already obviously valid or obviously invalid from the first four stages. Superkabe only spends a credit when stages 1-4 have produced a risky classification — typically catch-all domains or role-based addresses where the internal checks alone can't reach a confident verdict.
On a typical Clay export, this means roughly 15-25% of leads consume a credit; the rest are free.
Health Gate Routing
After validation completes, the lead is handed to the Health Gate, which classifies it as GREEN, YELLOW, or RED based on the validation status plus domain-level engagement signals.
GREEN — full send
valid status + clean domain (no recent bounces, not catch-all). Routed straight into the matching campaign.
YELLOW — risk-capped send
risky or unknown, or a domain with low engagement history. Routed with per-mailbox risk caps: at most 2 risky leads per 60 sends per mailbox. This keeps the bounce-rate impact bounded even if some YELLOWs do bounce.
RED — blocked from all campaigns
invalid, disposable provider, or known-bad domain. The lead is marked BLOCKED and never reaches a mailbox.
Batch Behavior
The validation API accepts batches of up to 5,000 emails per call. Batches are processed asynchronously — the POST returns immediately with a batch_id, and you poll the results endpoint to retrieve org-wide breakdowns by status.
Latency expectations
- – Stages 1-4 (syntax, MX, disposable, catch-all): ~50ms per lead.
- – Stage 5 (MillionVerifier): ~2-5s per lead. Only fires on risky leads on paid tiers.
- – A 5,000-email batch typically resolves in 30-90 seconds end-to-end on Growth/Scale.
Re-validation Rules
Superkabe automatically re-validates leads whose last validation was more than 30 days ago when they are added to a new campaign. This prevents stale data from leaking into a fresh send. You can also trigger manual re-validation at any time by re-submitting the email through the API.
- Within 30 days: cached result returns instantly. No credit consumed.
- Beyond 30 days: full pipeline re-runs. Stage 5 charges 1 credit if the lead is risky on Growth/Scale.
- Manual re-validation: hit
POST /api/v1/leads/validatewith the same email — the cache is bypassed only when you setforce: true.
What Blocks or Flags an Address
Hard blocks (status = invalid → RED):
- Syntax failure — malformed address, invalid characters, bad TLD.
- Missing MX records — recipient domain has no mail server in DNS.
- Disposable email provider — mailinator, guerrillamail, 10minutemail, and ~3,000 others.
Risky flags (status = risky → YELLOW):
- Catch-all domain — domain accepts every address; can't confirm specific mailbox exists.
- Role-based addresses —
info@,support@,no-reply@,admin@,sales@. - Low-engagement domains — historical bounce rate above org-level thresholds.
API Reference
Validation endpoints are available on Growth and Scale tiers. All requests require anAuthorization header carrying a live API key.
POST /api/v1/leads/validate
Submit up to 5,000 emails for validation. Returns a batch ID immediately.
curl -X POST https://api.superkabe.com/api/v1/leads/validate \
-H "Authorization: Bearer sk_live_abc123..." \
-H "Content-Type: application/json" \
-d '{
"emails": [
"alice@acme.com",
"bob@example.io",
"info@mailinator.com"
]
}'{
"batch_id": "batch_8f3c1a92",
"submitted": 3,
"cached": 1,
"queued": 2,
"status": "processing"
}GET /api/v1/validation/results
Poll for completed results. Returns org-wide breakdown by status plus per-email detail.
curl https://api.superkabe.com/api/v1/validation/results?batch_id=batch_8f3c1a92 \ -H "Authorization: Bearer sk_live_abc123..."
{
"batch_id": "batch_8f3c1a92",
"status": "complete",
"summary": {
"valid": 1,
"risky": 1,
"invalid": 1,
"unknown": 0,
"pending": 0
},
"results": [
{ "email": "alice@acme.com", "status": "valid", "health": "GREEN", "credits_used": 0 },
{ "email": "bob@example.io", "status": "risky", "health": "YELLOW", "credits_used": 1 },
{ "email": "info@mailinator.com", "status": "invalid", "health": "RED", "credits_used": 0 }
],
"credits_remaining": 59997
}Validation as Bounce Defense
Downstream of validation, every campaign is monitored for bounces. If a campaign exceeds a 3% bounce rate after 60+ sends, the bounce protection auto-pauses it and triggers the 5-phase recovery pipeline on the affected mailboxes. In a healthy Superkabe deployment, that pause should rarely fire on validation-related bounces — invalid emails shouldn't have shipped in the first place because the validator blocked them at ingestion.
If you see bounce-driven pauses
It usually means leads were imported through a path that bypassed validation (e.g., a legacy direct SMTP import). Re-run those leads through /api/v1/leads/validate before re-enrolling them, or move the import to a path that validates on ingestion.