Perfect math. Perfect balance. The wrong result.
Meera runs data operations at a sales-tool startup. Her team verifies about 500,000 email addresses every day for customers. She had 50 proxy IPs and a script she was proud of.
The script was simple. Each IP made one check every 8.64 seconds. That number is not random — 86,400 seconds in a day, 10,000 checks per IP (500,000 ÷ 50), so 86,400 ÷ 10,000 = 8.64 seconds. Every IP stayed busy all day, none was overloaded, and the day's target was met exactly. Her dashboard showed flat, clean lines.
Replacing the whole pool changed one point. That told her the problem was not which IPs she used. It was how her traffic behaved. She found four things wrong, one at a time. This post follows the same order.
My view before we start: swapping IPs is the most overused fix in bulk verification. It is expensive, and most of the time it treats a symptom. Fix the behaviour first, and change IPs only when the IP itself is the problem.
Mail servers see connections — not people
Nobody types email addresses into an SMTP server by hand. So "mimic human behavior" cannot mean copying a person. Mail servers do not see people. They see connections: how often, how many checks per connection, how regular the gaps are, and how much arrives from many IPs at the same time.
Real mail traffic has a shape. Gaps are uneven. A connection carries a few recipients, then closes. Traffic to one destination is spread across the day, not stacked in a block. That shape is what you are copying.
One honest note: mail providers do not publish how they judge verification traffic. Every number below is a starting value, not a known limit. Watch your own unknown rate and adjust.
Eight point six four seconds, every time, on every IP. Real traffic never looks like that. A perfectly even gap is itself a pattern. The obvious fix is "add random delay" — but where most teams stop is not enough.
Meera also added intentional long pauses — 2% of her gaps became ~90-second pauses. But pauses cost time. Every bit of variance you add must fit inside your time budget.
An IP is where traffic comes from. A session is one connection to the mail server — from opening to closing. They are two different things, and Meera only ever changed one. Her script opened a connection on each IP and kept it open for hours, running thousands of checks down the same connection. A connection that runs for hours does not look like mail. When she replaced the IPs, each new IP did the same long-running thing.
A session problem is fixed by a new session. An IP problem is fixed by a new IP. Meera had used the expensive fix — 50 new IPs — for the cheap problem: long sessions.
Each IP made only one check every 8.64 seconds, which looks polite. But her list was sorted by domain — so she processed all Microsoft-hosted addresses together in one block. From the mail server's perspective, 50 IPs were all hitting the same destination with the same rhythm, simultaneously, for 7.2 hours.
One practical detail: pace by where the mail is hosted, not by the domain name. Thousands of different company domains route through the same Microsoft servers. Group domains by their MX host and set the cap on the group. Meera shuffled her list so hosting groups mixed through the day, and set a cap of 2 checks per second on the Microsoft-hosted group.
Per-domain caps have a floor your list decides. At a cap of 1.5 per second, the most you can do in 24 hours is 129,600 checks. Adding more IPs does not fix this — the cap is on the whole group, not each IP. Your only options are to accept carry-over to the next day, give the run more hours, or raise the cap.
Meera's setup after four weeks of fixes
Her unknown rate on Microsoft-hosted addresses went from 21% to 12% over two weeks. It did not go back to 9%. Some servers never give a clear answer however you behave, and it is better to say that plainly than to promise a number you cannot hit.
If you verify a few thousand addresses a day across many different domains, you do not need all of this. Basic random gaps and closing sessions regularly is enough. The list-shuffling and group caps matter when volume is high and a large share of your list sits on the same few mail hosts.
average ÷ e^(sigma²/2). The resulting gaps will average to your target while appearing naturally varied.
Residential proxies with session and pacing controls built in
Proxy25 provides residential proxy infrastructure for email verification, with session and pacing controls built in so you do not have to build this logic yourself.