Planning infrastructure for email sending Servers and cost estimate before you rent a VDS.

The estimate starts with choosing a mode. “MTA-Hub recommendation” picks the make-up for the size of your list and safe limits, “Limit the speed per day” — for the number of emails you need a day, and “Budget limit” — for the amount you are ready to spend, and it tells you what had to be given up. Then come questions about the list: where it came from and how long ago it was last mailed set the sending pace and the risk level, and so how many addresses and servers you will need. If you are unsure of your answers, start with “MTA-Hub recommendation”: the builder recalculates as you fill it in, and you see the result right away.

Enlarge

• Planning mode — three buttons at the top: MTA-Hub recommendation, daily speed limit or budget limit.
• List size and quality — how many addresses and where they come from: your own engaged list, a cooled-down one, mixed, partner or bought. The source sets the sending pace and the safe daily limit per address.
• Spread across mailbox providers — a list spread over many mailbox providers ramps up faster. A list concentrated at a single provider is riskier: its filter covers all your sending at once.
• Months since the last send and topic — a long gap since the last send or a “heavy” topic raises the risk: you get fewer addresses per server and more different hosting providers.
• Scenario for the list — cleaning only, straight to the offer, cleaning and offer, or the full chain: cleaning, activation, segmentation, sales series.
• Days for cleaning, domain zone, MTA and geography — these decide the timing, the domain price, the choice between PowerMTA and MailerQ and the recommendations on zones and countries.
• Name and “Save” — the finished estimate goes into the list of specifications.

Enter real data: different answers in the questionnaire can change the number of servers, IP addresses, domains and the cost.

Here you set how the work with the list will go and how new addresses will be warmed up. For each part of the sequence you enter the number of emails and how many days each email gets — from this the builder works out how many sending points you need: each email in the sequence goes out from its own IP address and its own domain. Next to the heading you see right away how many emails the sequences hold in total, and the hint above the fields shows the minimum number of SMTPs. The second part is warm-up: whether your addresses are new or already warmed up, and at what pace to ramp them up. In the example the sequence is 7 + 3×5 + 3×5 = 37 emails, so you need at least 37 SMTPs plus addresses for cleaning.

Enlarge

• Activation emails, segmentation topics, emails per topic and sales emails — the length of each part of the sequence. In the example 7 + 3×5 + 3×5 = 37 emails, so you need at least 37 SMTPs plus addresses for cleaning.
• Days per email — how much time each email in the sequence gets; this sets how long the stages take.
• A separate sending point for each email — if one email damages its reputation, the other emails in the series are not affected.
• Addresses — new ones that need warming up, or already warmed up.
• Warm-up pace — careful, balanced or fast — the same paces as in the Hub’s warm-up module.
• Warm-up recipients available and reach volume in (days) — how many recipients you have for warm-up and by when you need working volume. If you do not know, leave “don’t know” and “doesn’t matter”.

Only the plan is set here. The warm-up itself is started and tracked in a separate Hub module.

Here you enter your real purchase terms: “this VDS at this hosting provider at this price”. From these items the builder picks servers for each task on its own — taking the cheapest one that fits — and calculates the cost estimate at your prices. You can also set your own domain registration price per zone here. If you have no items of your own, the estimate uses market plans from the “Hosters” directory. A ready configuration from the directory can be added to your list with one click. A configuration is described the same way as at the hosting provider: CPU, memory, disk, city, how many IP addresses the price includes and what an extra one costs.

Enlarge

• VDS configurations — CPU, memory, disk, hosting provider and city, how many IP addresses the price includes, the price of an extra address and the monthly price.
• From the “Hosters” directory — a ready configuration can be added with one click.
• Choice per task — each task gets the cheapest configuration that fits.
• Domain registration — the yearly domain price per zone. Your price replaces the directory’s reference price.

If you have no prices of your own, the builder takes the data from the directory. Before buying, check that the plans have not changed and the resources are available.

The main table of the estimate. Each row is a stage of work with the list: how many emails it has, which audience, how many emails a day need to go out and which resources that takes. Above the table — the risk level and the chosen MTA, a note on the pace and the total time for all the stages. The total row adds everything up: how many SMTPs, servers, hosting accounts, domains and how much money you need in total. The (i) icon on each stage explains why it is needed and where the numbers came from. Under the table — how many sending points are kept in reserve because of the risk, and why tasks are spread across different hosting accounts.

Enlarge

• Risk and MTA — the risk level for your list and topic, and the chosen PowerMTA or MailerQ.
• Pace note — how many emails a day one address could send with no limits, and which safe limit was taken for a list and topic like yours.
• Timing — how many days the whole job will take and what makes it up: cleaning, warm-up, activation, segmentation, sales series.
• Stage table — emails in the sequence, audience, emails per day, SMTP (IP), servers, hosting accounts, domains and costs. The (i) icon explains why the stage is needed and where the numbers came from.
• Under the table — how many sending points are kept in reserve because of the risk, and why tasks are spread across different accounts.

The figures in the screenshot come from a builder example. For another list of the same size they may differ.

The cost estimate answers the main money question: how much you need at the start and how much every month after that. One-time domain costs are shown separately so they are not confused with monthly rent. This way the budget is clear before you order servers and register domains. In the example you need 1,498 USDT to start, 442 USDT a month from the second month, and 88 domains cost 1,056 USDT once for the year. In total 30 VDS are rented from 28 hosting accounts with 88 addresses. If the amount does not suit you, go back to the questionnaire or switch the mode to “Budget limit” — the builder will show what can be done for that money.

Enlarge

• Cost to start — the first month of servers and IP addresses plus domain registration.
• From the second month — rent for servers and extra IP addresses.
• Domains, one-time per year — how many domains and what they will cost. Not part of the monthly costs.
• VDS rented in total — how many servers, with how many hosting providers and how many IP addresses.

The cost estimate includes only what is in the calculation. Count licenses and other services separately if they are not in the estimate.

The warm-up plan shows how new addresses will reach working volume. Each address starts with a small number of emails a day, the rate grows in steps — and only if the previous step went cleanly — and then holds for a few days without growth so mailbox providers get used to the sender. You also see how many recipients and different emails this takes and how many emails the whole warm-up will send. In the example the rate grows from 50 to 403 emails a day per address over 17 days: 10 days of ramp-up and 7 of stabilization. The warm-up itself is started and tracked in a separate Hub module — here there is only the plan and the timing.

Enlarge

• Rate per address — how many emails a day we start with and how many we will reach: in the example 50 → 403.
• Timing — days of ramp-up and stabilization: in the example 17 days — 10 of ramp-up and 7 of stabilization.
• Warm-up audience — how many recipients who open and reply are needed, and whether your list has enough of them.
• Email variants — how many different emails it takes for the warm-up not to look like a robot mailing: 15 in the example.
• How the warm-up goes — step by step: start, ramp-up, stabilization, who we send to and what, what breaks a warm-up. At the bottom — how many emails the whole warm-up will send.

This is only a plan. How recipients respond, how many bounces and complaints there will be, is visible only during the real warm-up. The timing in the plan is not a guarantee of the result.

A ready shopping list. For each server role it says why it is needed, which configuration it requires and how many such servers to order. This list is handy to take to the hosting provider, and under it are the requirements without which a sending server is useless: a supported OS, outgoing port 25 open and reverse DNS (PTR) you can set up. In the example the list-cleaning server is kept apart from the production ones — its reputation burns out first — and activation needs 14 servers with 2 vCPU · 4 GB · 40 GB. You rent the servers yourself from the hosting provider you choose, and then connect them to the Hub through MTA installation.

Enlarge

• Role and purpose — what task the server is needed for.
• Configuration and quantity — which resources are needed and how many servers of this role to order.
• Operating system — the server must run a supported OS.
• Port 25 — the hosting provider must allow outgoing connections on TCP port 25.
• Reverse DNS (PTR) — ask the hosting provider in advance whether it can be set up.

The list helps you prepare the purchase. You rent the servers yourself from the hosting provider you choose.

The DNS plan shows how many DNS accounts and domain zones you will need and what that will cost. You need a zone for each sending point, and accounts are split by task: in the example, 88 domains come to 4 accounts with 50 zones each. You register the domains yourself; the Hub only needs access to the DNS accounts to create the zones and records. DNS usually costs nothing extra: the hosting provider gives you DNSmanager with the server, and Cloudflare is free. The layout — a separate DNS account for each task — can be changed before the diagram is built, and you need one zone for each sending point.

Enlarge

• DNS accounts — how many you need and how many zones fit in one.
• Zones in total — one domain for each sending point.
• Costs — DNS usually costs nothing extra: the hosting provider gives you DNSmanager with the server, and Cloudflare is free.
• Layout — a separate DNS account for each task. It can be changed before the diagram is built.

Each DNS service has its own price and terms — check them before launch.

Geography recommendations adapt to where your recipients live. The builder suggests which domain zones to use and in which countries to place servers, which zones are better avoided — and explains why: the domain zone is part of your reputation, and the server’s country is the route and the network. In the example, for Europe it recommends the .com, .net, .eu, .de and .fr zones and servers in DE, NL, FR and FI, while free and “junk” zones like .tk or .top are best avoided. There are also tips to send at the recipients’ local time and write in the region’s language. Get domains in advance: a domain registered yesterday is a warning sign for a filter.

Enlarge

• Regions and zones — where to place servers, which domain zones to use and which to avoid.
• Why — the domain zone affects reputation, the server’s country affects the email route.
• Preparation — get domains in advance, and records are needed for each region.
• Time and language — send at the recipients’ local time and write in the region’s language.

Geography is only one of the plan’s conditions. On its own it does not decide whether emails get through.

The estimate itself tells you where your answers lead to risk and why the numbers came out the way they did. Yellow marks what needs attention, blue marks explanations. Read them before approving the plan: they suggest how to lower the risk and the number of addresses. In the example, with a list like this one address can safely send 8,400 emails a day, not 28,800, so more addresses are needed; reaching the offer takes about 98 days, and with more than 8 IPs it advises taking them from at least two /24 subnets. If the conditions change, create a new version of the specification and compare it with the previous one.

Enlarge

• Warnings — for example, a stage had to be packed tighter: that many hosting providers with port 25 open cannot be found, and blocking one account will hit several servers at once.
• Why so many addresses — with a list like this, one address can safely send fewer emails than the maximum speed would allow. If you want fewer addresses, spread the mailing over a longer time or use a warmer list.
• Layout across accounts — why tasks are spread across different hosting providers: an account burned on cleaning will not drag production sending down with it.
• Timing and subnets — how many days until the offer and from how many /24 subnets to take IP addresses.

Read the warnings together with the cost estimate and the make-up. If the conditions change, create a new version of the specification.

The top row tells you how many estimates have already become working infrastructure and what it costs. Drafts and approved but not yet deployed options are counted separately — for now they are estimates on paper. A new estimate also starts here: the “New specification” button opens the builder with the questionnaire. Peak capacity here is an estimate based on deployed specifications; how many emails actually go out is shown by the running MTAs. Planned cost is the monthly total for the deployed specifications once they are fully assembled, and the caption under “Applied” names the infrastructures themselves.

Enlarge

• Applied — how many specifications have been deployed as infrastructure; the caption names the infrastructures.
• Awaiting decision — drafts and approved specifications that are not deployed yet.
• Planned cost — the monthly total for the deployed specifications once they are fully assembled.
• Peak capacity — how many emails a day the infrastructure can send when fully assembled, and the total size of the lists it was calculated for.
• “New specification” — opens the builder for the next estimate.

The peak capacity in the summary is an estimate, not an actual figure. How many emails actually go out is shown by the running MTAs.

A summary of everything deployed: on the left — what is planned and how much of it is already assembled; on the right — what it costs. The key line is “in place”: it compares the plan with what is actually in place and shows how many servers, IP addresses and domains are really connected to the infrastructure already — for example, “12 of 40 nodes”. Below is the four-step path: calculated, approved, deployed, warm-up. The cost estimate on the right shows the five largest cost items, the monthly total and one-time costs. The “Diagram” and “Nodes” buttons lead on — to the infrastructure diagrams and to the server list.

Enlarge

• “Applied” — and the list of infrastructures created from specifications.
• “Awaiting decision” — how many estimates are not deployed yet; “Open the first” shows such an estimate in this card.
• Capacity, servers, addresses, domains — added up across all deployed specifications.
• “In place” — all slots taken, some taken — for example, “12 of 40 nodes” — or nothing yet.
• Four steps — calculated → approved → deployed → warm-up. The counter on the last one shows how many deployed specifications are warming up.
• Cost estimate on the right — the five largest items as bars, the rest in one “Other” row, the monthly total and one-time costs.
• “Diagram” and “Nodes” — go to the infrastructure diagrams and to the server list.

This is a summary across several infrastructures, so its figures do not match the figures of a single specification.

All saved specifications are in one list: what each estimate promises, what it costs and which step it is on. You can find the option you need, go back to a task without filling in the questionnaire again, export an estimate or tick several rows to compare them. Clicking a row opens the specification in the card at the top. The “version 2 of 2” label means the estimate was recalculated, and the risk — low, medium or high — shows how widely the estimate spreads the sending. From the ⋮ menu you can rename a row, create a new version, export to PDF and CSV, deploy or delete.

Enlarge

• Search and filters — search by name; filters — all, drafts, approved, applied.
• Specification — name, version (“version 2 of 2” means the estimate was recalculated), date and MTA.
• Capacity, make-up and price — emails a day at peak, servers, IP addresses and domains in one badge, the monthly estimate total. The list sorts by name, capacity and price.
• Risk — low, medium or high: an assessment of the list and topic that decides how widely the estimate spreads the sending.
• Status — the four steps of the path and the same in words: draft, approved, assembling, deployed, warming up.
• Task — the starting condition of the estimate: list size, target speed per day or budget cap.
• ⋮ menu — open, rename, new version, export to PDF and CSV, deploy, delete.

Click a row to open the specification. Tick several rows to compare them.

Before choosing, compare up to three saved estimates in one table: the capacity each one gives, how many servers, addresses and domains it needs, what it costs and how many days it takes to launch. This shows what an extra dozen servers would give you and what they would cost. Green marks the better value in a row — more capacity, lower costs, a shorter launch time. In the example, Lumacart’s running marketing infrastructure stands next to a draft for the sales season. MTA, make-up and risk have no “better” or “worse” — only the difference is shown there.

Enlarge

• Comparison rows — capacity, MTA, servers, IP addresses, domains, monthly costs, risk, launch time in days and status.
• Green — the better value in the row: more capacity, lower costs, a shorter launch time. MTA, make-up and risk have no “better” or “worse” — only the difference.
• Example on screen — Lumacart’s running marketing infrastructure next to a draft for the sales season.

Look at warm-up separately: its result depends on the list and on how the recipients’ mailbox providers react.

Clicking a row in the list opens the full specification in the top card — you can examine any option without leaving the page. This is a convenient place to check an estimate before approving it, export it to PDF or CSV for colleagues or a client, and deploy it as infrastructure. The “New version” button recalculates the option with different questionnaire answers. “Deploy” creates slots in the Hub for servers and DNS accounts, to which real servers are connected later — MTA installation is a separate step. The “not deployed” label means the estimate is still on paper.

Enlarge

• Name, version and date — and a “not deployed” label if the estimate is still on paper.
• PDF and CSV — export the estimate, for example to show a client.
• “New version” — recalculate with different questionnaire answers.
• “Deploy” — the Hub creates slots for servers and DNS accounts, to which real servers and accounts are connected later.
• Make-up and cost estimate — capacity, servers, addresses and domains, cost items, monthly total, one-time costs, risk and approximate launch time.

Creating the structure in the Hub and installing the MTA on servers are two different steps.