| NetEase 126 | |
|---|---|
| Domains | 126.com |
| Mail routing | 126mx00.mxmail.netease.com and its siblings, on NetEase's shared mail platform. |
| What we can resolve | We resolve few mailboxes here |
How NetEase 126 answers a probe
What the server does when we open a connection and ask about one address.
- Foreign probe connections are dropped or refused in the same pattern as 163.com.
- The two domains share infrastructure and rate-limiting policy, so probing both changes nothing.
- Responses follow standard conventions on the rare occasions a connection completes.
- 126.com tends to hold slightly newer accounts than 163.com, which came first.
The part that catches people out
What we do about it
We treat the NetEase domains as one provider for rate-limiting purposes and report unresolved addresses as unknown with the cause stated. That is the whole honest answer available from outside China.
Sending to NetEase 126 mailboxes
Verification is one step. These are the things that decide whether the message lands.
- The same Chinese regulatory considerations apply as for any mainland recipient.
- 126.com appears on B2B and trade data alongside 163.com for the same reason.
- Segment mainland Chinese addresses out of coverage expectations built on Western lists.
li.wei@163.com and li.wei@126.com are two accounts
Shared servers don't mean shared mailboxes at NetEase. The company registers 163.com and 126.com addresses separately, so li.wei@163.com and li.wei@126.com can belong to two people who've never met. Say you're merging a trade-show list with a directory export, 900 NetEase rows in total, and your dedupe step keys on the local part because it's all one provider. Every collision it finds is a coin toss, and each wrong merge attaches one person's name and order history to another person's inbox.
Dedupe on the full address for these domains. Group by provider for pacing and reporting, where the shared infrastructure does matter, and keep identity matching strict. The two jobs use the same word, provider, and need opposite rules. If your CRM has already merged NetEase rows this way, pull the merge log and split them again before the next send, since the damage compounds each time someone updates the wrong record.
What an all-unknown segment should cost you
Here's the arithmetic on a list where a third of the rows can't be checked. Say you upload 30,000 addresses and 10,000 of them are on 126.com and 163.com. From outside China those 10,000 will mostly come back unknown. Unknowns aren't billed, so the run consumes roughly 20,000 credits. At our pay-as-you-go rate 10,000 credits cost $25, and whatever you don't use stays on the account, because credits never expire.
Compare that with a tool that bills every row submitted. You'd pay for 10,000 results that carry no information, and you'd likely get them labeled with something more confident than unknown to make the invoice feel fair. When you compare quotes, ask each vendor two things: what they charge for a row they couldn't resolve, and what label that row gets. For a China-heavy list those two answers matter more than the per-email price.
Questions people ask
Is 126.com different from 163.com?
Only in name and account vintage. They share NetEase's infrastructure, rate limits and posture toward foreign connections.
Will coverage improve on a Chinese list over time?
Not through anything we can do at the protocol level. It is a network-reach problem rather than a verification technique problem.
What should I do with these addresses?
Keep them, mark them unresolved, and judge them by replies. Deleting them on a guess is worse than carrying them with an honest label.