SOCKS4 forwards raw TCP, which is why it turns up in mail client settings while HTTP proxies never do. It is also a protocol from the early 1990s with no real authentication, and mail providers now read proxied SMTP as a spam signal.
SOCKS is a circuit-level proxy protocol. Unlike an HTTP proxy, which reads and rewrites the requests passing through it, a SOCKS proxy is told where to connect and then does nothing but copy bytes in both directions. It has no idea whether those bytes are a web page, a chat protocol or a mail session, and that indifference is the whole point of it.
SOCKS4 dates from the early 1990s and is about as simple as a protocol can be. The client opens a TCP connection to the proxy and sends a short binary request:
byte 0 VN version, always 0x04 byte 1 CD command: 0x01 CONNECT, 0x02 BIND bytes 2-3 DSTPORT destination port, network byte order bytes 4-7 DSTIP destination IPv4 address bytes 8.. USERID a variable-length string last byte NULL 0x00 terminator
The proxy answers with eight bytes whose second is the status: 0x5A (90) means granted,
0x5B to 0x5D (91–93) mean rejected for various reasons. After a
granted reply the connection becomes a plain pipe to the destination. That is the entire protocol.
Two consequences fall straight out of that layout. The destination is a four-byte IPv4 address, so the client must resolve the hostname itself before it can even form the request — every DNS lookup happens on your own machine and leaves on your own network. And the USERID field is simply a string the client asserts; nothing verifies it. A SOCKS4 proxy reachable from the internet is an open proxy by construction.
SOCKS4a is a minor extension: the client writes an impossible address of the form 0.0.0.x, appends the hostname after the user ID, and the proxy performs the DNS lookup. That single change is what makes a SOCKS4a proxy usable for browsing without leaking every hostname you visit to your local resolver.
SOCKS5, standardised as RFC 1928 in 1996, is a different animal.
| Feature | SOCKS4 | SOCKS4a | SOCKS5 |
|---|---|---|---|
| Authentication | User ID string, unverified | Same | Username and password (RFC 1929) or GSSAPI |
| Destination types | IPv4 only | IPv4 or hostname | IPv4, IPv6 or hostname |
| DNS resolution | Client side only | Proxy can resolve | Proxy can resolve |
| Transport | TCP only | TCP only | TCP and UDP |
| Encryption | None | None | None |
Note the last row. No version of SOCKS encrypts anything. Whatever privacy you get comes from the protocol running inside the tunnel, which is why TLS matters more than the proxy version. If you want to see the difference on the command line, curl exposes all three:
curl --socks4 127.0.0.1:1080 https://example.com # client resolves DNS curl --socks4a 127.0.0.1:1080 https://example.com # proxy resolves DNS curl --socks5-hostname 127.0.0.1:1080 https://example.com
The link between SOCKS proxies and SMTP or IMAP is not marketing, it is a genuine technical
property. An HTTP proxy speaks HTTP. You can hand it a GET or a POST, or ask it for a
CONNECT tunnel, and in practice almost every HTTP proxy restricts CONNECT to port 443
because that is what it exists for. Mail protocols are not HTTP. SMTP on 25, submission on 587 or 465,
IMAP on 143 and 993, POP3 on 110 and 995 are all line-oriented TCP conversations that an HTTP proxy
has no way to represent.
SOCKS has no such concept. You give it a host and a port, it opens the socket, and the mail client carries on as if it were talking to the server directly. That is why desktop mail clients grew SOCKS host and port fields in their connection settings rather than HTTP proxy fields, and why any article about proxying mail ends up talking about SOCKS.
It is worth being precise about what this gets you even in the best case: the mail server sees the proxy's address instead of yours, and nothing else changes. The SMTP conversation, the envelope sender, the message headers and the authentication are all identical.
Plain SOCKS4 fails on every axis that matters in 2026. There is no authentication worth the name, so an exposed SOCKS4 port is usable by anyone who finds it — and scanners find it within hours. There is no IPv6, so a growing share of the internet is simply unreachable through it. There is no UDP, so DNS, QUIC, VoIP and game traffic cannot pass. There is no remote DNS, so every hostname you visit is resolved and logged on your side of the connection. And there is no encryption, so an unencrypted protocol inside it is readable by whoever runs the proxy.
Whether a message reaches an inbox is decided by domain authentication and by the reputation of the IP address that connected, not by whether that address was hidden. Putting a proxy in front of SMTP attacks none of the things that decide delivery and breaks several of them:
The realistic outcomes are rejection at connect time, silent delivery to a spam folder, or suspension of the account you were sending from. None of them are fixed by a better proxy.
If you are sending mail, send it authenticated through a provider that is supposed to send it: submission on port 587 with a username and password, SPF and DKIM published for your domain, a DMARC policy on top, and a warmed address if you run your own. That is the entire game, and it is decided long before anything touches the network path.
If your goal was different — reaching a mail server that your current network blocks, or reading IMAP from a hotel connection — the right tool is a tunnel to a machine you control, not a public proxy:
ssh -N -L 1993:mail.example.com:993 you@your-server.example.net # then point the mail client at 127.0.0.1:1993
That keeps the connection encrypted end to end, uses an address you are accountable for, and involves no third party reading your mail session.
To be unambiguous about it: the PyProxy residential product speaks HTTP, HTTPS and SOCKS5. It does not speak SOCKS4, and its SOCKS5 carries TCP only. It is not a mail relay, and sending email through these proxies is not something this shop supports.
What it is built for is web traffic — scraping, price and availability checks, ad verification, testing how a site behaves from another country. That is one endpoint, one set of credentials, and options carried in the username:
curl -x http://USERNAME-country-us:PASSWORD@gw.pyproxy.com:1111 https://httpbin.org/ip
Change -country-us for another country, or append a session token to hold a single
exit address for about thirty minutes when a multi-step flow needs to look like one visitor. Billing
is per gigabyte and the traffic does not expire, so an evaluation costs cents.
A circuit-level proxy from the early 1990s that forwards raw TCP connections. The client sends a short binary request naming a destination IPv4 address and port, the proxy opens that connection and then copies bytes in both directions without understanding or modifying them. It carries any TCP protocol, not only HTTP.
SOCKS4 handles IPv4 destinations only and expects the client to resolve DNS itself; its user ID field is an unverified string, not authentication. SOCKS4a adds remote hostname resolution by the proxy. SOCKS5 adds real username and password authentication, IPv6 and domain-name destinations, and UDP forwarding, and is the only version worth deploying today.
A SOCKS proxy will carry an SMTP or IMAP connection because it forwards arbitrary TCP, but that does not make it work. Mail providers treat a proxied SMTP connection as a spam signal, the connecting address will not match your domain's SPF record, most consumer and cloud networks block outbound port 25, and the usual result is rejection, silent spam filing or a suspended account.
No. The PyProxy residential product is HTTP and HTTPS only, it does not support SOCKS5, and it is not a mail relay. Sending email through the proxies is not something this shop supports. They are built for web traffic: scraping, price checks, ad verification and similar work.
