Operators relying on traditional SMTP verification no longer get an accurate view of email list risk, up to 60% of B2B addresses sit behind catch-all domains or security defenses that defeat verification. Revenue, deliverability, and sender reputation now depend on tracking real-world metrics and engagement, not just a 'valid' badge from the hygiene vendor.
Key takeaways
- Catch-all domains comprise 40%, 60% of B2B addresses and invalidate SMTP verification accuracy for individual mailboxes.
- Modern mail servers deploy greylisting, tarpitting, and rate-limiting, making SMTP-based checks unreliable for high-security domains.
- SMTP verification cannot detect spamtraps, abandoned accounts, or filtered mailboxes, risking high hard bounce rates after list hygiene.
- Key list health metrics now include hard bounce rate (<0.5%), spam complaint rate (<0.1%), engagement recency, and post-send bounces.
- Klaviyo and HubSpot enable segmentation and automation based on engagement, which is necessary to mitigate risks from unverifiable addresses.
SMTP Verification: What It Validates, and Where It Stops
SMTP verification assesses whether an email address appears to exist at the exact moment of testing by imitating the initial steps of a delivery attempt. This process involves the SMTP handshake, starting with the HELO or EHLO command, followed by MAIL FROM to set the sender, and RCPT TO to designate the recipient. The critical moment comes at RCPT TO: if the server replies 250 ("Requested mail action okay, completed"), it signals acceptance and suggests the address is accessible at that point. A 550 ("Requested action not taken: mailbox unavailable") means rejection, indicating a non-existent or unreachable mailbox. Temporary codes like 451 reflect indeterminate status, highlighting that all responses are a snapshot of current accessibility, not a guarantee of ongoing validity (Wikipedia: Email Address Verification).
A 250 Accepted signals the server is currently willing to accept mail, while a 550 User Not Found indicates a definitive fail for that address. These outcomes, though, only reflect technical accessibility during the test, they do not confirm future operability or human engagement. Domains configured as catch-all or running specific security policies may distort these results, giving false-positive signals for broad address ranges (VeriMails: Catch-All Email Verification Guide, EmailVerifierAPI Blog).
The Rise of Catch-All Domains: A Deliverability Dead Zone
Catch-all (or wildcard) mailboxes are configured to accept messages sent to any local-part at a given domain, regardless of the existence of the specific mailbox. This is standard in many corporate, anti-spam, and managed services environments, including Google Workspace, Fastmail, and Microsoft 365, where inbound routing often simulates universal acceptance (VeriMails, ZeroBounce Blog).
For instance, a domain with catch-all enabled responds with 250 OK for any address, authenticated or not. Managed providers such as Google and Fastmail allow administrators to enable this with a simple control. Microsoft 365 sometimes appears as catch-all from the outside, because of its default handling of invalid addresses (ZeroBounce Blog).
SMTP verification on these domains always signals "deliverable," regardless of whether a real mailbox exists, misleading database hygiene processes and inflating perceived list quality. Research and vendor consensus confirm that 40%, 60% of B2B domains globally operate in catch-all mode at some stage (EmailVerifierAPI Blog). Catch-alls in B2C are less common, seen mostly in niche privacy services or smaller providers.
- Google Workspace, Fastmail, Microsoft 365: Enable or simulate catch-all responses by default for many organizations (ZeroBounce Blog).
- B2B-targeted domains: 40%, 60% flagged as catch-all in recent verification studies (EmailVerifierAPI Blog).
- B2C/consumer: Rare, except for specialized privacy services.
Mechanistically, catch-all domains will report 250 OK for every possible address, even routing invalid mail to null mailboxes or simply dropping it. The result: hygiene tools are fed false deliverability data, leading to unexpected bounce problems and damage to sender reputation (VeriMails, MCA Rocket).
Modern Mail Security: Greylisting, Rate-Limiting and Verification-Busting Policy
Providers combat unsolicited probing using measures that degrade the effectiveness of SMTP verification. Greylisting, standard at Google Workspace and Zoho Mail, returns a temporary 4xx error on the first attempt from unknown senders, demanding a retry delay and causing verification tools to either misclassify or leave status undetermined (EmailVerifierAPI Blog).
Tarpitting introduces deliberate SMTP response delays when servers detect automation, further obfuscating mailbox states. Gmail and Microsoft 365 will artificially slow response times or inject ambiguous banners once per-connection or per-IP thresholds are crossed, making bulk checks unreliable. These throttles are visible via admin logs on both Gmail and Microsoft, where events such as "Rate limit exceeded" or similar appear (ZeroBounce Blog).
Rate-limiting policies, set globally and per-domain, limit the number of probes from any source. Providers like Zoho and Outlook enforce typical thresholds of 20, 100 RCPT TO commands per hour before starting to degrade or block further traffic, as evident from Microsoft 365 event logs (VeriMails).
Security frameworks such as SPF, DKIM, and DMARC now influence SMTP response quality. Probes from unauthenticated or low-reputation IPs often get ambiguous or misleading replies, regardless of real address existence. Microsoft 365, in particular, applies these rules universally, impeding attempts to validate mailboxes without corresponding SPF alignment (ZeroBounce Blog).
Repeated verification attempts or "double-checking" do not improve accuracy once these barriers, such as greylisting or rate-limit, have been activated. The outcome is persistence of ambiguous responses or intentionally misleading acceptance, increasing the risk of false-positives. This is a material issue, as between 40% and 60% of B2B records already reside behind such policies (EmailVerifierAPI Blog). Mailers should regard positive SMTP responses from these providers as structurally compromised signals (MCA Rocket).
Failure Modes in Real Lists: What SMTP Verification Misses in Practice
SMTP checks may label addresses as 'valid' but do not identify many operational failure types. List-scale issues include hard bounces from catch-all domains, spamtraps that never engage, and full or abandoned inboxes. For example, Microsoft 365 business domains typically present all addresses as valid to outside checks, but many may not exist at all (EmailVerifierAPI, ZeroBounce Blog).
Silent Failures on 'Valid' Addresses
- Catch-All Domains: All emails appear deliverable at probe time, even if invalid. This affects 40, 60% of B2B addresses (EmailVerifierAPI).
- Spamtrap and Filtered Addresses: Spamtraps are deliberately set up to look operational; SMTP checks do not detect their purpose, exposing marketers to blacklisting. Filtered or dormant accounts also appear live but contribute to spam placement and decay.
- Full or Abandoned Inboxes: A full mailbox passes SMTP at test time, only to bounce emails later when quota is exceeded or after inactivity.
Why 'Valid' Lists Still Generate Bounces
Even lists marked as 99% valid by SMTP methods experience post-send bounce issues. In ecommerce databases, typical post-validation rates (from vendor reporting) are:
- Hard Bounces: 0.8%, 2.3%, majority due to unverifiable catch-all addresses (MCA Rocket).
- Soft Bounces: 0.6%, 1.4%, mostly tied to full inboxes or greylisting at major platforms.
- Spamtraps and Honeypots: 0.01%, 0.04%, small in volume but high in risk for deliverability.
Vendors like NeverBounce, ZeroBounce, and BriteVerify label ambiguous/verifier-thwarted addresses with codes such as catch_all, unknown, or similar (ZeroBounce Blog). These should be isolated from core marketing flows, as sending to them tracks with increased hard bounce rates and risk (EmailVerifierAPI).
| Vendor | Error Code/Status | Caveat |
|---|---|---|
| ZeroBounce | catch_all, unknown | Does not confirm inbox existence; bounce risk elevated for Microsoft 365/Google Workspace. |
| EmailVerifierAPI | Accept-All | Server accepts all mail without verifying live user status. |
| VeriMails | catchall | Address unverifiable; not recommended for campaigns. |
Operators relying only on SMTP verification underestimate risks. Segmenting list risk based on metadata and watchlist codes is essential for database health, especially with the rise of catch-all domains.
Beyond SMTP: What Metrics Actually Track List Quality
As the volume of unverifiable addresses grows, shifting to behavior-driven and engagement-based metrics is fundamental for modern list health. SMTP verification only reveals technical status at probe time; it cannot diagnose issues central to reputation and revenue.
- Hard Bounce Rate: Should remain below 0.5%. Klaviyo's
bounce_reasonallows reporting and segmentation by bounce type. HubSpot's Email Performance and API expose bounces by thestatus=BOUNCEDproperty (HubSpot API reference). - Soft Bounce Rate: Should not exceed 2%. Both Klaviyo and HubSpot expose soft bounce counts and rates in email reporting interfaces and APIs.
- Spam Complaint Rate: Must stay under 0.1%. Both ESPs expose complaints via reporting and API fields (
complaintsin Klaviyo,spam_reported_countin HubSpot). Breaching this threshold signals reputational risk, often correlating with misidentified catch-all addresses (MCA Rocket). - Send-to-Open Lag: High lag implies disengagement or out-of-date segments. Both platforms support delivery and engagement timestamp analysis in campaign-level or API reporting.
- Engagement Recency: Recipients with no engagement in the past 90 days should be excluded from active campaigns. Klaviyo and HubSpot allow filtering on
last_openorlast_engaged_timeto automate this process.
These data points are visible in the reporting suites of major ESPs and must be monitored persistently (VeriMails, ZeroBounce Blog).
Operational Recommendations: Measurement, Monitoring and Progressive List Hygiene
Instead of relying on ambiguous SMTP or vendor outputs, focus operations on frequent metric monitoring and dynamic segmentation. In platforms like Klaviyo, actionable fields include Bounce Rate, Spam Complaint Rate, and engagement time properties in the Analytics and Account Overview screens. HubSpot's Email Performance dashboard and Workflows allow operators to trigger automatic segment suppressions or internal alerts if risk thresholds are breached (MCA Rocket).
Best practice segmentation in Klaviyo includes logic such as:
- Opened or clicked at least once in 90 days
- No bounce events in last 30 days
- No spam complaints recorded
Pre-send verification alone is insufficient for database cleanliness. Apply ongoing engagement-based cycles, automatically suppressing or flagging users who exhibit no activity within specified windows, and triggering alerts for abnormal bounce or complaint levels, notification setups for these thresholds are available in both Klaviyo and HubSpot.
| Platform | Screen/Report | Metrics for Monitoring | Automation/Alert Feature |
|---|---|---|---|
| Klaviyo | Analytics > Campaigns/Flows, Account Overview | Bounce Rate, Spam Complaint Rate, Open/Click in N days | Notifications (Account Settings), Segments, Flows |
| HubSpot | Email Performance Report, Active Lists | Hard Bounce Rate, Spam Reported Rate, 'Opened', 'Clicked' filters | Workflows, Internal Alerts, Active List Triggering |
This approach, applied consistently, mitigates list decay and delivers the operational visibility needed as catch-all domains and modern mail security erode the value of classic verification (VeriMails).
Summary Table: What Each Method Tells You, and What It Hides
Comparing three core detection and list hygiene approaches underscores why no single layer is sufficient. The table below details capabilities and limitations for each, highlighting the inherent "catch-all blind spot."
| Detection Method | Non-Existent Addresses | Catch-All Blind Spot | Spamtraps | Dormant Inboxes | Soft Bounces |
|---|---|---|---|---|---|
| SMTP Verification | Detects most invalid addresses except those on catch-all domains (VeriMails). | Cannot distinguish mailbox status for 40%, 60% of B2B addresses (EmailVerifierAPI Blog). | Does not flag spamtraps; no access to blacklists or engagement data. | Cannot detect dormant accounts, only immediate existence. | May catch addresses later if a bounce is returned, but not predictive. |
| Vendor API Verifier | Similar limits to SMTP; adds pattern and blacklist checks but still blind to catch-alls (VeriMails). | Same blind spot; classifiers like 'catch-all' or 'unknown' recognize, but do not resolve (EmailVerifierAPI Blog). | Partial detection via known lists, coverage incomplete. | No insight to activity; cannot catch dormant/unengaged users. | Post-send soft bounces possible if ESP feedback loop exists. |
| Engagement/Deliverability Metrics | Flags non-existent recipients after a hard bounce occurs (MCA Rocket). | Diagnoses catch-all problems only retrospectively, through high bounce trends (MCA Rocket). | Can infer spamtrap risk via inactivity and heuristics, not direct evidence. | Identifies dormant inboxes by absence of engagement over time. | Captures all soft bounces logged by the ESP, supporting iterative hygiene (ZeroBounce Blog). |
Direct reliance on classic email verification cannot provide complete list security, especially in the era of rising catch-all domain use and increasingly aggressive server security. Operators must adopt a layered approach, blending SMTP checks, vendor verifier outputs, and real engagement telemetry to sustain revenue and reputation as threat surfaces evolve (ZeroBounce Blog).