SOCKS5 proxies for mail in PowerMTA and MailerQ
Connect SOCKS5 proxies to PowerMTA and MailerQ through the Hub’s gate. One screen shows the state of your addresses, how the connections are doing and the results of sending.
Check proxies, group them into proxy pools and set rules for how to react to changes. The reason for every event stays in the log.
01 / An email’s route through a proxy
PowerMTA and MailerQ can’t send mail through SOCKS5 proxies on their own, so the Hub’s gate sits between the MTA and the proxy. The gate runs on the sending node: it takes the connection from the MTA and opens a SOCKS5 tunnel through the chosen proxy. The recipient’s mail server sees the proxy’s exit IP — that is the address you put in DNS and check against blacklists.
The MTA and the gate run on your sending server; the recipient sees the proxy’s exit address
The gate opens a tunnel to the proxy’s entry address and port — with the login and password the seller gives you. Both proxy addresses are shown in the address table.
This is the address the email arrives from at the mailbox provider. It goes into A and SPF records and is checked against blacklists — it may differ from the entry address.
02 / Data sources
The overview brings together sending results, tunnel performance and the state of each address. MTA accounting tells you whether an email was delivered, the gate counters — whether the connection succeeded, the Hub’s checks — whether the proxy itself is fit for mail. Every figure names its source and period, and the numbers are never blended into one overall “health score”.
Delivered emails, permanent failures and the trend over the chosen period — from the MTAs’ own reports.
See the accountingCounters of successful connections and tunnel failures on each sending server.
See the gatesAcceptance checks and rechecks: is the proxy fit for mail right now.
See the checksCompleted emails = delivered + permanent failures. Temporary failures are counted separately, as sending attempts.
03 / Connecting to sending
To start sending through proxies, you go through six steps: the gate, a pool, fit addresses, subdomains and DNS, writing the settings to the server, and sending points in the email platform. The Hub shows how ready each step is for the chosen node. If setup isn’t finished yet, you can jump straight from the overview to the right screen.
The hubgate service runs next to the MTA and opens connections through SOCKS5.
GatesA pool ties proxy addresses to a server and a sending domain — proxies are bound to a server only through a pool.
PoolsProxies pass an acceptance check: they respond, speak a protocol the Hub understands and can reach port 25.
ProxiesEach address needs a subdomain, and the exit addresses go into the domain’s SPF; the Hub checks that the records are visible.
Domain DNSThe gate gets the addresses and their tags, and the overview checks that the gate has the same addresses as the Hub.
Gate checkReady-made SMTP accounts go to your email platform and send emails through the configured addresses.
Path to sending04 / Rules and events
Pool rules and rechecks notice in time that a proxy has started working worse: delivery dropped, the rental is running out or port 25 closed. The overview shows the signal, what the Hub did and what needs your decision. The Hub never deletes a purchased address on its own — that decision stays with you.
The figure from MTA accounting fell below the threshold set in the rule.
The Hub takes the rule’s action and records the reason in the event. What is left for you to check: find the cause of the drop before putting the address back into sending.
The rental ends within the period set in the rule.
The address shows up in the attention block, so you can check the rental term before it ends. Your decision: renew the rental or prepare a replacement for the pool.
A recheck found that the address can no longer reach port 25.
The check result changes the address’s grade and state in the proxy list. A purchased address is kept — the Hub won’t delete it on its own. Whether to ask the seller to open the port or retire the address is your call.
05 / The interface in detail
All 11 screens of the Proxy Gate overview: setup, the proxy fleet, sending results, events, gates and the blacklist check. The screens are grouped by task — from the overall state of the module down to a single address.
The Proxy Gate overview starts with the essentials: which server and period to look at, where the numbers come from and whether the route to sending is ready. Six setup steps show what is already done for the chosen server — from the gate to the sending points in the email platform. Below are the gate’s summary and the fleet tiles: how many addresses are working, how many wait in reserve, how many are fit for mail and which ones have rentals ending soon.
The top of the Proxy Gate overview: the module tabs and a choice of server and data period — 24 hours, 7 or 30 days. Every number on the page is recalculated for the chosen server and period. The line under the tabs names the three number sources — MTA accounting, gate counters and Hub checks — so you don’t confuse sending results with tunnel performance or the state of an address. From here, the “Check all” button runs a check of all addresses, and “Import” leads to loading a new proxy list. This screen is usually where you start when something has changed: first pick the server and period, then read the blocks below. “Check all” skips only the addresses that have been retired.
EnlargeSix steps from the gate to the email platform for one server: the gate, the pool, fit addresses, subdomains and DNS, writing to the server and sending points. It opens on the server where setup has already started — mta-01 in the example, and it has passed every step. The block answers the main question before sending through proxies: at which step did setup stop. Each step leads to its own screen, so you can finish anything left undone right away. The block opens collapsed, and its subtitle — “fully set up” or how many steps are left — shows the server’s readiness at a glance; in the example mta-01 runs the hubgate 1.1.0 gate, three fit addresses and three sending points.
EnlargeOn the original screen this block can be collapsed. Here all screenshots are expanded so you can get to know the interface.
Five numbers about how the Proxy Gate works. The first three are about what is happening now: how many servers have the gate, how many proxies are sending and how many subdomains they have. The last two cover the chosen period: how many emails went out through proxies and what share of them was delivered. The summary tells you at once whether sending through proxies is running and whether delivery has dropped. If a number looks worrying, look for the reason below — in the daily chart, the address table and the events block. In the example the gate runs on mta-01 and mta-02, 5 proxies out of the 8 assigned to servers are sending, and 26,822 emails went out over the week with a delivered share of 95.1%.
EnlargeThe numbers in the screenshots come from an example infrastructure; they are not limits or a promise of results.
The proxy fleet tiles: how many addresses are working and of which grade, how many wait in reserve, ready to stand in for working ones, and how many are fit for mail. You also see separately when a purchased address has been rejected or its rental ends soon. This way the mailing owner knows in advance whether there are enough addresses for sending and what needs renewing or replacing. In the example one address of eight dropped out of the fit-for-mail group because port 25 was closed. A rejected purchased address stays in the database, while an address whose rental has expired goes to quarantine, so it is better to renew rentals in advance — in the example one address’s rental ends tomorrow.
EnlargeHow emails sent through proxies actually reach mailbox providers. The daily chart shows delivered emails, temporary and permanent failures and the delivered share. Next to it — what the fleet is made of: address grades, countries and neighbors in one subnet. The breakdown by major mailbox providers and the address table show which proxy drags delivery down, and with which provider.
A daily chart of sending through proxies for the chosen period. At the bottom of each bar are delivered emails, above them temporary failures, and on top permanent ones; the dashed line is the delivered share on its own scale. Under the chart is the total for the period. Temporary failures count as extra attempts, not as separate emails, so delivered plus permanent failures add up to exactly all emails. A dip in the chart points straight to the day when you should look for a problem address. In the example 26,822 emails went out over the week, 95.1% were delivered, and 724 temporary failures made up 2.6% of all attempts; today’s bar is paler because the day isn’t over yet.
EnlargeThe delivery rate in the screenshot is example data. MTA accounting alone doesn’t show which folder an email landed in.
What the fleet of proxies fit for mail is made of: how many addresses of each grade and from which countries. At the bottom — neighbors in one /24 subnet. Mailbox providers treat addresses in one subnet as one sender, so several neighbors are not independent IPs for mailing. The screen helps you spot such groups in advance and take them into account when you spread addresses across pools. The breakdown by grade and country shows how even the fleet’s quality is. In the example there are 2 fit-for-mail addresses of grade A, 4 of B and 1 of C, and three ProxyLine addresses sit in one subnet, 203.0.113.0/24.
EnlargeHow major mailbox providers — Gmail, Outlook, iCloud, GMX and Yahoo — accept emails sent through proxies, according to the latest MTA accounting report, which covers about a week. An overall delivery rate can hide a problem with one provider, but here it shows up at once. In the example Yahoo doesn’t accept one address of six, although that address works with the other providers. A rejection by one provider is no reason to throw a proxy away: you can keep it in a pool that excludes that provider. Look for the reason in the neighboring blocks: in the example it is px-05, whose address is on blacklists — you can see it in the proxy table and in the blacklist check window.
EnlargeThe period of the latest provider report may differ from the period chosen in the summary.
A table of all proxies that are sending emails right now — sorted by email volume. For each address you see where the gate connects and which exit IP the mailbox provider sees, who the seller is, which server the address works on, its subdomain, grade, blacklists and delivered share. A red dot in the “Blacklists” column and a red delivery bar point you straight to the address that drags sending down. The table footer explains why its total may differ from the summary: the summary includes emails from addresses that no longer send. In the example four addresses deliver 97–98%, while px-05 delivers only 78.9%.
EnlargeTime to SMTP banner comes from the address checks, not from the accounting of sent emails.
What needs your decision and how the connection itself is performing. Events no one has reviewed yet show the reason, the rule that fired and what the Hub did. The gates table tells you whether the service runs on each server and whether its addresses match those in the Hub. The blacklist check shows which lists the exit address is on — the one the recipient sees.
Proxy events no one has reviewed yet — newest first. For each you see what happened to the address, which rule fired and what the Hub did: warned that a rental is ending, sent the address to quarantine or lowered its grade. Some decisions the Hub leaves to you — for example, it won’t remove a purchased address with port 25 closed by itself. The “Dismiss” button removes an event from this block, but it stays in the log. In the example the “Delivery rate dropped” rule sent px-06 to quarantine after its delivery fell to 81.77%, and in the evening a recheck found port 25 closed and lowered its grade to D. Dismissed events can be found later in the “Log” section.
EnlargeA purchased address with port 25 closed is not deleted automatically. Contacting the seller or retiring the address remains the user’s decision.
The gate on each sending server: the service address and version, how many addresses its table holds compared with the Hub’s registry, successful connections and tunnel failures over the period. If delivery has dropped, this screen shows whether the problem is in the connection to the proxy itself or in how the mailbox provider received the email. Here you also see when a new gate version is available for a server. The gate accepts connections only from its own server’s address — PROXY protocol has no password. In the example mta-01 runs gate 1.1.0 with 3 addresses of 3 and 0.6% tunnel failures, and mta-02 has 2 addresses of 2, version 1.0.4 and 1.7% failures; if the number of addresses on the gate doesn’t match the Hub, the settings are sent to the server again.
EnlargeThe gate accepts connections only from its own node’s address; PROXY protocol offers no password authentication.
The blacklist check window opens from the dot in the “Blacklists” column of the proxy table. It checks the exit address — the one the recipient’s server sees, not the address used to connect to the proxy. For each list you see whether the address is on it and since when, and the “Check now” button queries the lists again. This makes it clear why a mailbox provider rejects emails from a particular proxy, and lets you decide what to do with the address next. In the example px-05’s exit address has been on SpamCop, Barracuda and PSBL since Oct 15, and the other five lists are clean — which explains Yahoo’s rejection in the providers block.
Enlarge06 / Questions and answers
In the overview you can go from the overall state down to a single address — right to the check result for each blacklist zone.
The gate links PowerMTA or MailerQ to SOCKS5 proxies. The service runs on the node: it takes the connection from the MTA, opens a tunnel through the chosen proxy, and the connection reaches the recipient’s mail server from the proxy’s address.
Through a pool. It ties proxies to a node and a sending domain. Once the addresses are checked and the subdomains and DNS are ready, the settings go to the gate, and the sending points are exported to the email platform.
The exit IP — the address the recipient’s mail server sees. It may differ from the address used to connect to the proxy. The table shows both; the exit address is used for A records, SPF and blacklist checks.
No. For mail, what matters is that TCP/25 is reachable. The Hub runs acceptance checks, works out the address state, and checks the port and the blacklists. Tunnel performance and sending results from MTA data are tracked separately.
It is a figure from MTA accounting for the stated period. It helps you judge the completed outcomes of sending, but on its own it doesn’t confirm that emails reached the inbox. The percentages on this page are example data from the interface.
A temporary failure belongs to a sending attempt after which the MTA may retry delivery. It can’t be added to completed emails as one more email. In the overview, delivered emails and permanent failures make up the total of completed outcomes, while temporary failures are shown separately.
A rule can move an address to quarantine when the delivered share drops, or warn that a rental is about to end. The event shows which rule fired and why. A purchased address with a closed port stays in the proxy list until the user decides.
The summary reflects sending over the chosen period, while the table shows the addresses working now. Emails sent through a proxy that later stopped sending stay in the period’s totals. The interface explains the difference in the table footer.
The gate accepts connections only from its own node’s address. This matters because PROXY protocol uses no password authentication. The service state, its version and whether its addresses match the Hub are shown in the gates table.
07 / Module sections
Each section of the module has its own job: prepare proxy addresses, link them to a node, set rules and check sending results. Start with the proxy list, then group the addresses into pools.