Building Real‑Time SMTP Email Verification at Scale for findmemail.io

The Problem: Stale or Unverified Emails Destroy Deliverability

Most B2B email‑finder services run verification as a background job. Their databases contain a mix of fresh, stale, and never‑checked addresses. When a user receives a list, they cannot tell which rows are trustworthy. In practice this leads to bounce rates of 5 % – 10 % and, for low‑quality data, sometimes 30 % or more. A single high bounce rate can get a sending domain throttled or black‑listed, killing any outbound campaign.

findmemail.io set a hard constraint: no email is ever returned unless it has been SMTP‑probed in the last seven days. This decision forces the entire system to be built around real‑time verification, not batch cleanup.

---

Solution Approach

1. The Minimal SMTP Probe

The probe is deliberately lightweight:

1. MX lookup – Resolve the domain’s mail exchange records.
2. TCP connect – Open a socket to port 25 of the MX host.
3. HELO/EHLO – Identify ourselves.
4. MAIL FROM – Use a throwaway sender (e.g., [email protected]).
5. RCPT TO – Ask if the target mailbox would be accepted.
6. QUIT – Close the connection without sending DATA.

Only the RCPT TO response matters. A 250 means the server would accept mail for that address; 550 signals a hard reject; 421/451 are temporary failures.

2. Fighting Anti‑Verification Defenses

Mail servers have learned to treat probes as spam harvesters. The system must detect and adapt to five common defenses:

Defense	Symptom	Mitigation
Catch‑all domain	RCPT TO returns 250 for any address	Probe a known‑bad address (asdf‑not‑real‑12345@domain). If it also returns 250, tag the domain as catch‑all and stop returning individual addresses for it.
Greylisting	First probe returns 451 and expects a retry	Retry with exponential back‑off (e.g., 10 s → 30 s → 2 min) up to three attempts over an hour. Store the retry schedule per domain.
Rate limiting	After a burst of probes the server stalls or returns 421	Rotate a pool of outbound IPs, enforce a per‑domain rate limit of 1 probe per minute, and spread traffic across the pool.
Anti‑spoofing checks	Server rejects unless the sender domain has valid SPF/DKIM/DMARC	Operate a dedicated, warmed‑up sending domain (probe.findmemail.io) with fully published SPF, DKIM, and DMARC. Use this domain for all MAIL FROM commands.
Honeypot / tarpit	Responses take >5 s, or every address returns 250 but later bounces	Measure latency; if >5 s, flag the host as suspicious. Cross‑probe two known‑good addresses; if they all accept but later bounce, downgrade confidence for the whole domain.

3. Caching for Latency and Load Management

Running a full probe on every API call would push response times past 2 s and hammer MX hosts. The cache works as follows:

• First‑time probe – Store the result with a TTL of 7 days.
• Cache hit – Return the cached verdict instantly (typical < 100 ms).
• Cache miss – Trigger a fresh probe, update the cache, and return the new verdict.
• Feedback loop – If a user reports a bounce, invalidate the cache entry immediately and re‑probe.
• Hot‑list refresh – The top 1 000 most‑queried addresses are re‑validated daily in the background to keep the p50 API latency under 800 ms.

4. Handling Providers That Refuse Probes

Large providers (Google Workspace, Microsoft 365, AOL) often return a generic 252 or 550 5.7.1 for any RCPT TO attempt, effectively saying "we won't tell you". The system falls back to a layered heuristic:

1. Pattern matching – Compare the address to historically verified addresses from the same domain.
2. LinkedIn name verification – Use public profile data to confirm first‑name/last‑name combos.
3. Domain‑wide enrichment – If at least three other emails at the same company are verified, treat similar patterns as likely valid.

These fallbacks are labeled "deliverable, lower confidence" in the API response, allowing downstream callers to decide whether to include them.

---

Trade‑offs and Lessons Learned

Aspect	Benefit	Cost / Complexity
Real‑time verification	Guarantees < 2 % bounce rate, protects sender reputation.	Requires a robust probe infrastructure, monitoring, and IP rotation.
Cache TTL of 7 days	Keeps latency low, reduces MX load.	Stale data risk if a mailbox is deactivated within the window; mitigated by feedback invalidation.
Greylist retry logic	Improves success rate on servers that enforce greylisting.	Increases probe latency for those domains (up to ~1 hour before a result is ready).
Catch‑all detection	Prevents polluting results with generic acceptances.	Must maintain a list of known‑bad test addresses and periodically re‑evaluate domains.
Fallback heuristics	Provides coverage for providers that block probes.	Confidence is lower; callers must handle the extra field in the response.

Operational Realities

• IP pool size – We started with a single /28 block; after hitting rate limits on gmail.com we expanded to three /24 blocks across two cloud regions.
• Monitoring – Every probe logs latency, response code, and IP used. Alerts fire if the average latency for a domain exceeds 5 s or if the failure rate climbs above 15 %.
• Legal compliance – Probing is performed only on domains that appear in a user‑initiated request, respecting the principle of explicit consent.

---

What This Enables for Customers

Because each email is freshly verified, customers of findmemail.io see bounce rates below 2 %, compared with the 5 %–10 % typical of large B2B data providers. The API also returns a deliverabilityConfidence field (high, medium, low) so developers can filter or weight contacts programmatically.

The trade‑off is a smaller overall dataset (≈ 32 k companies vs. millions for competitors), but the higher quality translates directly into higher campaign ROI and fewer reputation incidents.

---

Takeaways for Engineers Building Their Own Email Finder

1. Make verification a first‑class constraint – Treat it as a non‑negotiable part of the data model, not an after‑thought batch job.
2. Expect anti‑verification defenses – Implement catch‑all detection, greylist retries, and rate‑limit throttling from day one.
3. Cache aggressively, but keep a fast invalidation path – A 7‑day TTL works well when you have a reliable bounce‑feedback loop.
4. Plan for providers that refuse probes – Have a secondary confidence model based on pattern and public data.
5. Monitor latency and response codes – Real‑time probes can become a source of latency spikes; observability is essential.

If you are building a B2B email finder and want to discuss architecture details, feel free to drop a comment below.

---

Ready to try it? The free tier gives you 50 verification credits with no credit card required. The API response includes a confidence flag so you can decide which addresses to use in your campaigns.

---

Related reading:

• SMTP Verification Explained – Mailgun Docs
• How to Build a Scalable Email Verification Service – AWS Architecture Blog
• Understanding Greylisting – Postmark Blog