Email Validation and Email Intelligence in SuperSend

Who this is for

Campaign operators and deliverability owners who want to understand exactly how SuperSend validates email addresses, what the risk scores mean, and why the intelligence layer produces more accurate results than standalone validation services.

The Two-Layer System

SuperSend email validation is not a single check. It is two systems working together:

1. SMTP Validation — probes the actual mail server to confirm whether a mailbox accepts mail, without sending an email. This is the industry-standard check that tools like ZeroBounce and NeverBounce use.

2. Email Intelligence — a cross-customer, privacy-preserving database of real delivery outcomes. Every send, bounce, and reply across the SuperSend platform feeds a global registry that scores each email address based on what actually happened — not what an SMTP probe guessed.

When both layers have data on an email address, the intelligence layer takes precedence. Real delivery outcomes beat theoretical probing.

Layer 1: SMTP Validation

What it checks

Every email address is evaluated against four criteria in order:

1. Syntax (Regex)

Is the address formatted like a valid email? This catches obvious malformation: missing @, invalid characters, malformed domains.

2. Disposable domain check

SuperSend maintains a list of ~4,778 known disposable and temporary email providers — mailinator.com, guerrillamail.com, and hundreds of similar services. Addresses at these domains are flagged immediately without any network call.

3. MX record lookup

SuperSend performs a DNS query to confirm the domain has valid MX records — the routing rules that tell other mail servers where to deliver email for that domain. A domain with no MX records cannot receive email.

4. SMTP verification

SuperSend's validator service connects to the destination mail server and probes whether the specific mailbox exists — without actually sending an email. The mail server's response determines whether the address appears deliverable.

The validator infrastructure

SuperSend runs a dedicated validation microservice (email-validator.supersend.io) on its own infrastructure. The service is load-balanced across multiple endpoints, with:

• A least-connections algorithm that routes each validation to the least-busy endpoint
• Health checks every 60 seconds to remove failed endpoints from rotation
• Retry logic with exponential backoff (up to 2 retries)
• An 11-second timeout per validation attempt

Validation runs as a background queue job, processing up to 10,000 contacts at a time at 200 concurrent requests. Progress is broadcast in real time to your team's session via websocket.

SMTP validation limitations

SMTP probing has a fundamental weakness: many mail servers lie, or refuse to answer. Enterprise mail servers protected by security gateways (Proofpoint, Mimecast, Barracuda) often return "accept all" responses to prevent harvesting. Catch-all domains — domains configured to accept any email address — also return positive SMTP responses for nonexistent mailboxes. The SMTP check cannot distinguish a real mailbox from a catch-all acceptance.

This is where the intelligence layer fills the gap.

Layer 2: Email Intelligence

What it is

Email Intelligence is a global database of real delivery outcomes, aggregated across all campaigns sent through SuperSend. Every time an email is sent, bounces, or receives a reply anywhere on the platform, that outcome updates the intelligence record for that address.

Privacy model

The database stores a SHA256 hash of each lowercase email address — never the plaintext address. The hash allows lookup when you upload a contact list, but cannot be reversed to recover email addresses. Only aggregate counts are stored: total sends, bounce counts, reply counts. No information about which organizations sent to which contacts is stored or exposed.

The three core signals

Replies (gold standard)

A reply is definitive proof that the address exists, is deliverable, and belongs to a person who reads their email. When a reply is recorded against an address, the system immediately assigns it the highest possible score (SAFE, score 100). No other signal can override this.

Hard bounces (definitive fail)

A hard bounce is a permanent delivery failure — the address does not exist, the domain is dead, or the server explicitly rejected the address as nonexistent. One hard bounce sets the score to 0 and marks the address INVALID. Hard bounces are considered permanent unless a subsequent successful delivery is recorded.

Successful sends (positive signal)

Every email delivered without a hard bounce increments the address's send count. An address that has been successfully delivered to 10 times with no bounces has a high-confidence SAFE record, regardless of what an SMTP probe says. This is the override mechanism: when SMTP says "mailbox not found" but the intelligence database shows 5 successful deliveries, the delivery proof wins.

Detection flags (instant, no history required)

Three classifications apply to every contact immediately at import, without any database lookup or network call. They are based entirely on the email address itself:

Role-based email (is_role_based)

The local part of the address matches one of ~45 known role prefixes: info, support, sales, contact, hello, help, team, admin, office, hr, jobs, careers, billing, marketing, press, webmaster, and others. Role addresses route to shared inboxes or distribution lists. They are typically deliverable but have significantly lower response rates in cold outreach because no single person owns the mailbox.

Abuse or system email (is_abuse_email)

The local part matches one of ~35 prefixes associated with postmaster addresses, bounce handlers, or abuse reporting: abuse, noreply, no-reply, postmaster, mailer-daemon, bounce, spam, dmarc, bot, daemon, and others. These addresses are operated by mail systems, not people. Sending cold outreach to them has no value and can harm your sending reputation.

Free provider (is_free_provider)

The domain is a personal email service: Gmail, Yahoo, Hotmail, iCloud, Outlook, ProtonMail, AOL, Yandex, and ~75 others. Free provider detection is used as a mild risk signal (not a hard block) because business outreach to personal addresses has lower response rates and higher unsubscribe rates than to business domains.

Catch-all detection (passive inference)

Catch-all domains accept every email sent to them — even to nonexistent mailboxes — making SMTP probing useless. SuperSend detects catch-all domains passively from real delivery patterns rather than active probing (which gets blocked by security gateways):

• If 50+ unique addresses at a domain have been sent to across the platform, and the hard bounce rate is effectively 0%, the domain is classified as catch-all with up to 85% confidence.
• If the same domain shows a normal bounce rate (5%+), it is classified as non-catch-all with up to 90% confidence.
• Domains with insufficient volume remain unclassified.

This method has a key advantage over active probing: it cannot be blocked or rate-limited by the destination mail server, and its confidence grows with every send.

Provider and security gateway detection

SuperSend performs MX record lookups to identify which email platform and security gateway each domain uses. This data populates each contact's email_provider and email_security_service fields:

• Email providers: Google Workspace, Microsoft 365, and others
• Security gateways (SEGs): Proofpoint, Mimecast, Barracuda, and others

Provider detection runs once per domain per validation batch, with a 30-day refresh window. Knowing a domain uses Proofpoint, for example, explains why some validation probes return inconsistent results — Proofpoint blocks SMTP harvesting attempts, so raw probe responses from those domains are less reliable.

Cross-organization blacklist signals

When multiple unrelated organizations independently blacklist the same email address or domain, that convergence is a strong negative signal. A single blacklist entry from one organization could mean anything — a competitor, an unsubscribe, a data quality issue. Three independent organizations blacklisting the same address is a meaningful pattern.

The system applies a scoring penalty when unique_orgs_blacklisting >= 3. Importantly, this penalty is suppressed if the address also has a reply on record: an unsubscribe-based blacklist proves the email is deliverable, not invalid.

Domain-level blacklist signals carry more weight than individual email blacklists. If 5+ organizations have blacklisted the same domain, that domain is considered risky regardless of individual address history.

The Scoring Algorithm

The score

Every contact in SuperSend has a validity_score from 0 to 100 and a corresponding intelligence_risk_level. The score is calculated from all available signals and recalculated as new events come in.

Starting point: 65 (LOW risk)

New email addresses with no history start at 65 — a low-risk baseline. This default reflects the reality that most emails in a typical business list are deliverable, and the burden of proof for marking something risky should come from actual negative signals, not absence of data.

Signal weights

Risk levels

Confidence

Alongside the score, each record has a confidence level reflecting how much data backs the score:

• HIGH confidence: Reply received, or 50+ sends, or 3+ organizations sent to this address with 5+ combined sends, or a definitive SMTP result
• MEDIUM confidence: 5+ sends, or 2+ organizations, or 3+ sends with bounce breakdown data
• LOW confidence: Minimal send history
• NONE: Only detection flags, no delivery history

A SAFE score with HIGH confidence is meaningfully different from a SAFE score with NONE confidence. The contact table displays both values.

How it compares to standalone validators

Standalone validators like ZeroBounce, NeverBounce, and MillionVerifier all perform SMTP probing. SuperSend does too. The difference is what happens when SMTP probing isn't definitive — which is a large fraction of business email lists.

The fundamental limitation of external validators is that they never actually send email. They probe mail servers and make educated guesses. SuperSend's intelligence layer uses what actually happened when email was delivered — an accuracy ceiling that SMTP-only validators structurally cannot reach.

List Health Level (Campaign Setting)

The List Health Level setting in Campaign Settings → Sending Rules controls which risk levels receive email from a given campaign.

The setting is a multi-select with five options:

Defaults: SAFE and LOW are selected by default on new campaigns, which excludes HIGH and INVALID addresses from sending.

Contacts without a risk level (pending validation, or imported without running validation) are always included regardless of the List Health Level setting. The filter only applies when an intelligence risk level has been assigned.

Contacts with valid2 = 2 (classic invalid status) and no intelligence level are treated as INVALID for the purpose of this filter.

If a contact is skipped due to List Health Level, it is progressed through the sequence with the reason EMAIL_NOT_VALID — it does not count as a send and does not consume credits.

Validation credits

Email validation costs 1 credit per address. Credits are drawn from your organization's global credit pool.

Before the validation queue processes a batch, it checks whether the organization has credits available. Orgs with zero credits are excluded from the queue entirely until credits are replenished.

Check your balance: Admin → Global Credits.

When validation runs, a CreditTransaction record is created for each address validated, with type debit and item email_verification. These transactions appear in the Global Credit Transactions log.

Placement tests use a separate credit type (3 credits per test seed) and are tracked independently.

When validation runs

At CSV upload: The final step of the CSV import modal offers a "Validate all emails" option. If your organization has sufficient credits, validation runs immediately after import. The contact list shows live validation progress via websocket.

Background queue: The validation queue runs continuously and picks up any contacts with valid2 = 0 (pending). If you import contacts without validating, they will be validated automatically when the queue reaches them.

Intelligence updates continuously: The intelligence layer is not a one-time check. Every send, bounce, and reply updates the global record. A contact validated six months ago may have a different score today if new delivery data has been recorded for that address.

Understanding your contact list after validation

After validation runs, each contact shows:

• Validity score: 0–100
• Risk level: SAFE / LOW / MEDIUM / HIGH / INVALID
• Confidence: NONE / LOW / MEDIUM / HIGH
• Email provider: Google Workspace, Microsoft 365, etc. (when detected)
• Security gateway: Proofpoint, Mimecast, etc. (when detected)
• Global send/bounce/reply counts: Aggregate across all orgs (shown as signal counts, not org-level detail)

Filtering and sorting the contact list by intelligence_risk_level is the fastest way to identify which contacts to investigate, suppress, or remove before launching a campaign.

Troubleshooting

Issue: Bounce rate is still elevated after validation.

Likely cause: A significant portion of your list is catch-all addresses. Catch-all domains accept delivery at the server level but the mailbox may not exist. If the intelligence layer has no prior delivery history for those addresses, they score as LOW or MEDIUM (not INVALID) because there is no confirmed bounce on record.

Fix: Check what fraction of your contacts are on catch-all domains. Consider setting your campaign's List Health Level to SAFE + LOW only for lists with high catch-all concentration.

Issue: Contacts I know are valid are showing as INVALID.

Likely cause: An SMTP probe returned a mailbox-not-found result and the intelligence layer has no delivery history to override it. This can happen with mail servers behind aggressive security gateways.

Fix: If you have direct knowledge that an address is valid (e.g. you have prior correspondence), you can manually override the validation status or include HIGH contacts in your List Health Level. The intelligence layer will self-correct once successful sends are recorded.

Issue: Validation finished but contacts still show as pending.

Likely cause: Your organization may have exhausted its credit balance before the queue finished processing.

Fix: Admin → Global Credits → check remaining balance. Purchase additional credits if needed.

Issue: A contact shows MEDIUM risk but I expected it to be SAFE.

Likely cause: The address matched a role-based prefix (e.g. info@, support@, sales@), a free provider domain, or is on a catch-all domain. These are risk signals, not validation failures. The address is likely deliverable, but has lower expected engagement for cold outreach.

Fix: Review the contact's risk factors in the contact detail view. Decide whether to include MEDIUM-risk contacts in your campaign's List Health Level.

Related articles

• Email Validation in SuperSend — user guide for running validation and reading statuses
• Upload Contacts via CSV
• Contacts Overview
• Campaign Not Sending: Checklist

Updated on: 19/03/2026