How to build your own SOCKS5 proxy and verify email lists through it

When verification runs from your own connection, a big chunk of addresses come back with no clear answer and everything crawls. A dedicated IP fixes that, and setting one up is far easier than it looks. Every command is ready to copy.

You queue up a 50,000-address list overnight. You come back in the morning and find this: thousands of addresses marked unknown, throughput stuck at a few per second, and worst of all, a handful of real customers flagged as invalid.

The software isn’t the problem. Neither is your list. The problem is the IP address you did the talking from.

What’s actually happening

People assume email verification is some kind of clever guesswork! It isn’t. Your verifier connects directly to the mail server behind that address and asks, in effect, “do you have this mailbox?” It reads the answer and hangs up. No email is ever sent.

The catch is that this conversation happens from your own internet connection, and a home or office IP was never built for it. Three things get in your way:

Why this kills your speed

When a receiving server doesn’t recognize your IP, it stalls. It greylists you, answers slowly, or caps you at a couple of concurrent connections. Your verifier has no choice but to wait and retry. Multiply those few-second waits by fifty thousand and you’ve lost the whole night.

With a clean, static IP, the same list runs with far more parallel connections and far less waiting.

And why it wrecks your accuracy

This matters more than the speed. When your verifier can’t get a clear answer, it has to guess, and a wrong guess costs you either way: you drop a real customer from your list, or you keep a dead address that pushes your bounce rate up.

And a high bounce rate means your sending provider starts throttling you. One sloppy verification run comes back to haunt you months later as campaigns that never arrive.

The fix

You rent a small server and run a SOCKS5 proxy on it. Your verifier stays on your own machine, but from then on it speaks with that server’s IP: static, dedicated, port 25 open, properly named.

A few euros a month, set up once, and you’re done with it. Let’s build it.

Picking a provider

We’ll use Hetzner (console.hetzner.com) here because it’s cheap and the panel isn’t cluttered. But don’t get attached to it: any Linux VPS will do the job. DigitalOcean, Vultr, Linode, Contabo, OVH, or whoever you already have an account with.

Everything happens on Ubuntu and has nothing to do with the provider. Only the button names change. Where we say “click Add Server,” yours might say Create Droplet or Deploy Instance. Same thing.

There is one real difference worth taking seriously though: port 25. The entire verification process depends on it. Spammers abused that port for years, so most cloud providers block it on new accounts and only open it on request. Some leave it open from day one.

You’ll need three things to start: an email address, an international payment method, and a domain. The domain isn’t optional — you’ll see why at the reverse DNS step.

Creating the server

First, create an account with your provider and log in. On Hetzner that’s console.hetzner.com. From your dashboard, create a new project (call it proxy) and add a server inside it.

1. Location: Anywhere in Europe; Helsinki or Falkenstein
2. Image: Ubuntu 24.04
3. Size: The smallest option; on Hetzner that’s CX22
4. Networking: Both IPv4 and IPv6 enabled
5. SSH keys: Leave empty, we’re logging in with a password
6. Name: verify-proxy or anything you want

Hit create and give it about 30 seconds.

Now click the server name. At the top you’ll see a number like 89.167.39.172. That’s your server’s address. Write it down. Anywhere this guide says SERVER_IP, put that number in.

Setting up reverse DNS

You’ll be tempted to skip this one. Don’t. Before anything else, mail servers check whether the IP talking to them has a name. No name means suspicious, and suspicious means the connection gets dropped.

Most of the errors you’ll hit later during verification trace back to exactly this step.

1. Open the Networking tab on your server.
2. Next to the IPv4 address, choose Edit Reverse DNS.
3. Enter mx-probe.yourdomain.com (your own domain).
4. Do the same for the IPv6 address.

Then create two records in your DNS panel:

Confirm it actually worked

There are two halves to this, and both have to be right and agree with each other. You don’t need to log into the server; a free online tool shows you both.

First half: what name does the IP have?

1. Go to mxtoolbox.com/ReverseLookup.aspx.
2. Paste your server’s IP and hit Reverse Lookup.
3. The result should show mx-probe.yourdomain.com.

Second half: where does that name point back to?

1. Switch to the DNS Lookup tool on the same site.
2. This time enter mx-probe.yourdomain.com and search.
3. It should return your server’s IP, exactly.

If the second lookup shows a different address, or something like 104.21.x.x, you’ve still got a problem. It’s almost always that orange Cloudflare cloud.

Your first connection

This is the part that scares most people off. It shouldn’t. The tool is already installed on all three operating systems and the command is identical everywhere.

• macOS: hit Command + Space, type Terminal, press Enter.
• Windows: open the Start menu, type PowerShell, open it.
• Linux: open your Terminal app.

Then type this, swapping in your server’s number:

ssh root@SERVER_IP

ssh root@SERVER_IP

The first time it asks whether you’re sure. Type yes and press Enter.

Now it wants the password. The one from the email. Copy it and paste it in.

On this first login the server forces you to change the password. It asks for the current one again, then the new one twice. Save the new password somewhere safe right away, because it won’t show it to you again.

If your prompt looks like this, congratulations, you’re in:

root@verify-proxy:~#

root@verify-proxy:~#

Installing the proxy

In most tutorials this is the longest section: install the package, edit the config file, hunt down your network interface name, create a user, start the service. Happily, you don’t have to do any of it by hand.

There’s an open-source script that handles all of it with Dante and runs its own test at the end. On the server, run these two lines:

wget https://raw.githubusercontent.com/saaiful/socks5/main/socks5.sh
sudo bash socks5.sh

wget https://raw.githubusercontent.com/saaiful/socks5/main/socks5.sh
sudo bash socks5.sh

It asks you three things

That’s it. The script runs and only asks you for three things:

Nothing shows up on screen while you type the password. Same as before, that’s normal.

When it finishes, the script tests the proxy itself and prints your server’s IP details. If you see SOCKS5 proxy test successful, your SOCKS5 proxy server is live. That was the whole thing.

Changing something later

Forgot the password? Want a different port? Just run the same script again:

sudo bash socks5.sh

sudo bash socks5.sh

This time you get a menu:

Testing from your own machine

The script tested the proxy from inside the server, which is good but not enough. What actually matters is whether it answers from the outside. Open a terminal on your own computer:

curl -x socks5://USERNAME:PASSWORD@SERVER_IP:1080 https://ifconfig.me

curl -x socks5://USERNAME:PASSWORD@SERVER_IP:1080 https://ifconfig.me

It should return your server’s address, not yours. Once you see that, the proxy is ready. From this point on, anything routed through it leaves with a clean IP.

Pointing your verifier at it

The hard part is done. Now you just tell your verifier to use the proxy. In MailVexa, open Settings and find the Proxy section:

Hit Test Connection, then Save. Done.

Two more fields people skip

There are two more fields on that same screen that most people breeze past, and then wonder why verification fails for certain domains. These control how your verifier introduces itself when it talks to the destination server.

Leave them blank or fill them in wrong and Yahoo and Outlook will drop you at hello.

HELO has to match your reverse DNS. The receiving server compares the name you announce against the PTR record of your IP. If section 3 says mx-probe.yourdomain.com, put exactly that here. Not your bare domain, not some other subdomain.

Two more DNS records on that subdomain

Why the subdomain rather than your main domain? Because it keeps your verification reputation separate from your business email. If this IP ever runs into trouble, your main domain stays untouched.

Add these two records:

When something breaks

If you’re stuck, odds are good your problem is in this table. These are the ones almost everybody runs into:

And if you want to watch what’s happening live:

tail -f /var/log/danted.log

tail -f /var/log/danted.log

Every connection adds a line. If nothing appears while you’re testing, the request never reached the server at all and the problem is on your end. Press Control + C to quit.

Maintenance

This server needs almost nothing. Once a month, these two lines are enough:

apt update && apt upgrade -y
reboot

apt update && apt upgrade -y
reboot