Why more than one sending server#
A single sending server is a single point of failure: one vendor outage halts your campaigns, one reputation hit poisons everything you send. Running 2-4 servers from different vendors buys you breathing room. Concrete reasons:
| Goal |
What multi-server gives you |
| Survive a vendor outage |
When one server is paused or rejected, the rest of the pool keeps sending. |
| Isolate marketing from transactional |
Put marketing on one server and one-off/notification mail on another, so a blocked marketing IP can't drag everything else down. |
| Grow past a per-vendor cap |
New SES and similar accounts start with a low daily ceiling. Add a second vendor and your combined headroom goes up immediately. |
| Build reputation in parallel |
Warm a new vendor's IPs at low volume while an established server carries the bulk of the load. |
Add a second server (customer side)#
Open the Sending servers screen#
In the sidebar, go to Sending → Sending servers. The page is titled Sending Servers with the subtitle "Manage SMTP and API servers that power your email delivery." Your current servers show in the table, with a search box and Active / Inactive + type filters above it.
The right rail shows your vendor mix, total hourly throughput, and warmup status at a glance — a quick way to see how concentrated your sending is on a single vendor.
The green Add server button only appears if your plan allows you to run your own sending servers. On a plan where the administrator manages the pool for you, you won't see it — skip to Choosing which server a campaign uses below.
Click "Add server" → pick a type#
The top-right Add server button opens the type picker, titled Choose a server type. It's a card grid of every provider this install supports — generic SMTP, Amazon SES (API or SMTP), SendGrid, Mailgun, SparkPost, Elastic Email, Sendmail, Gmail OAuth, and any provider added by a plugin (those appear in a separate section).
Click the provider and integration type you want. The connect form opens with fields specific to that type.
Fill in the connection and save#
For generic SMTP, the form (Connect sending server → Connection settings) asks for host, port (defaults to 587), encryption (TLS / SSL / None), username, and password:
Pick an API type instead and the fields change to match. Amazon SES (API), for example, asks for an AWS access key ID, AWS secret access key, and an AWS region:
Click Add server. AcelleMail saves the credentials and drops you on the new server's detail page. The server isn't probed automatically on save — you confirm it works in the next step.
Test the connection#
On the server detail page, use Test connection. AcelleMail tries to connect with the credentials you entered and reports back inline — "Connection successful." or "Connection failed." There's also a test-send option to push a single message through and check your own inbox ("Test email sent — check your inbox.").
If the test fails, click into the server, fix the host / port / credentials, save, and test again. A server stays Inactive until you've got a clean connection and enabled it.
Choosing which server a campaign uses#
By default a campaign uses all of the sending servers available to you, picked at random per message — that's the redundancy you want most of the time. You control this per campaign in the Sending servers section of the campaign setup step (under Show advanced settings).
- The Use all servers randomly toggle is ON by default. Leave it on and every message goes through a random pick from your whole pool.
- Turn it OFF to narrow the campaign to specific servers. Flip the include switch on the servers you want this campaign to use.
- With a narrowed selection, Adjust weights lets you set how much traffic each chosen server carries relative to the others (drag a slider per server).
This is how you get deterministic-ish routing without leaving the app: a "newsletter" campaign narrowed to your bulk vendor, a "receipt confirmation" campaign narrowed to a clean transactional server. If every server you picked happens to be inactive at send time, AcelleMail stops the campaign with an error rather than silently falling back to the full pool — so a narrow always means what you said.
On a plan where the administrator manages the pool, this section is read-only: it lists the servers your plan grants and tells you they're shared and picked at random per message. You can't narrow it from the campaign — that's an admin-side decision (see below).
The admin pool view (self-hosted operators)#
If you run a multi-tenant install, Admin → Sending Servers is the full pool across all customers. The top of the page shows three stat cards — Total, Active, and Inactive — over a searchable, filterable table of every server.
The admin-side server detail has more knobs than the customer one — connection, configuration (including the sending limit), identity / DKIM, warmup strategy, and bounce/feedback handling:
To decide which customers can send through which servers, attach servers to plans under Admin → Plans → [plan] → Sending servers. Customers on that plan then send through the servers their plan grants — that's how you give a higher tier premium sending IPs while a basic tier shares a default pool.
Common UI signals and fixes#
| What you see |
What to do |
| New server stays Inactive |
Open the server → Test connection. Fix host / port / credentials based on the failure message, save, and test again. |
| Add server button is missing |
Your plan doesn't allow your own servers (or you've hit your server quota). The pool is managed for you under your plan. |
| A campaign sent through a server you didn't expect |
With Use all servers randomly on, picks are random per message. Turn it off in the campaign's Sending servers section and select only the servers you want. |
| Customer says they only see one server |
The other server isn't attached to their plan. Go to Admin → Plans → [plan] → Sending servers and add it. |
| Campaign won't send at all |
Either the customer's plan grants no active servers, or you narrowed the campaign to servers that are now all inactive. Re-check the plan's attached servers and each server's status. |
What to do after#
- Run Test connection on every new server before you point a real campaign at it.
- If you added a brand-new vendor or IP, start it at low volume — see IP warmup schedule for new sending servers.
- Watch bounce and complaint rates after the first send from a new server — see the related article below.
Related articles#
