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. Most production setups run 2-4 servers from different vendors. Concrete reasons:
| Goal |
What multi-server gives you |
| Survive a vendor outage |
Active failover — second server picks up when first goes down |
| Isolate marketing from transactional |
Marketing on one IP/server, password resets on another. A blocked marketing IP can't break login emails. |
| Grow past a per-vendor cap |
SES throttles new accounts to 200/day. Stack 3 vendors → 600/day on day one. |
| Build reputation in parallel |
Warm a new vendor's IPs while existing one carries the load. |
Add a second server (customer-side)#
Open the Sending servers screen#
In AcelleMail's sidebar, click Sending → Sending servers. Your current setup shows in the list:

Click "Add server" → pick the type#
Top-right Add server button opens the type selector. Card-grid of every vendor AcelleMail supports — SMTP (any vendor), Amazon SES, SendGrid API, Mailgun API, Postmark, Mailchannels, plus more:

Pick the vendor + integration type. The create form opens with vendor-specific fields. SMTP form (universal pattern — host + port + credentials):

For an API-typed server like Amazon SES, the form changes to vendor-specific fields (Access Key ID + Secret + region):

Fill credentials + save#
For SMTP: host + port + encryption + username + password. For API-typed servers: API key + region. AcelleMail encrypts and stores; credentials are never returned by the API.
Click Add server — the new server appears in your list with a Testing badge while AcelleMail probes the connection. Within a few seconds it flips to Active (or surfaces the connection error inline).
Verify in the admin pool view (multi-tenant installs)#
Self-hosted operators managing a SaaS install see the full pool at Admin → Sending Servers:

Pool view shows: Total / Active / Inactive cards · server-type breakdown bar · per-server quota usage · which plan(s) the server is attached to. The admin side is where you set the Default server for new customers and assign servers per plan tier.
The admin-side server detail has more knobs — pool-wide bounce handler, FBL handler, warmup strategy, identity (DKIM keys), and per-customer access rules:

Routing — which server sends which campaign#
AcelleMail's default routing: round-robin within the pool the customer's plan grants access to. The campaign builder doesn't ask the user to pick a server; the dispatcher does it at send time based on:
- Plan-attached servers — only servers attached to the campaign owner's plan are candidates
- Daily quota remaining — if Server A has hit its daily cap, Server B handles the next batch
- Per-server warmup state — warming servers get prioritized for low-volume campaigns to grow gradually
- Round-robin within candidates — even distribution after the above filters
For deterministic routing (e.g. always send marketing through Server A, transactional through Server B), use the admin Sending Plan feature to scope a plan to a specific server. Then attach the right plan to the right customer/automation.
Common UI signals + fixes#
| Symptom |
Likely cause |
UI fix |
| New server stuck on Testing |
Wrong port / credentials |
Click into the server → fix credentials → save → AcelleMail re-tests |
| Campaign sends from "wrong" server |
Round-robin distributed it to another server in the pool |
If you need deterministic routing, scope via Plan → Sending Servers attach |
| One server hits quota daily, others idle |
Per-server quota mismatch |
Open each server's Sending limit → align caps; OR set higher quota on the underutilized server |
| Customer sees only 1 server but you added 2 |
New server not attached to their Plan |
Admin → Plans → [plan] → Sending Servers → attach the new server |
| Both servers show Active but campaigns still fail |
Plan doesn't grant access OR all servers daily-capped |
Tracking log shows the failure reason per-message; check for OutOfCredits or NoSendingServer |
Advanced: programmatic server provisioning + automated failover via API
For SaaS operators managing many tenants, manual server config doesn't scale. AcelleMail's admin REST API supports server-CRUD:
# Create a new SMTP server programmatically
curl -X POST "https://acellemail.com/api/v1/admin/sending-servers" \
-H "Authorization: Bearer $ADMIN_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"type": "smtp",
"name": "Cluster B SMTP",
"host": "smtp-b.example.com",
"port": 587,
"encryption": "tls",
"smtp_username": "...",
"smtp_password": "...",
"default_from": "noreply@example.com",
"sending_limit": 5000,
"sending_limit_period": "hour"
}'
Automated failover — for true active/passive failover, poll AcelleMail's queue depth + per-server health every minute via the /api/v1/admin/sending-servers/{uid}/health endpoint. When primary degrades (rejected-connection-rate > 1% over 5min), the script:
- Disables the primary server (PATCH
status: disabled)
- Boosts the secondary's daily quota (PATCH
sending_limit: <doubled>)
- Sends an alert via your incident channel
- Re-enables primary after manual all-clear + verifying connection
Per-customer attached-servers via API:
curl -X POST "https://acellemail.com/api/v1/admin/plans/{plan_uid}/sending-servers" \
-H "Authorization: Bearer $ADMIN_TOKEN" \
-d '{"server_uids": ["uid-1", "uid-2"]}'
This grants the plan's customers access to those servers. Useful when you want a high-tier plan to get premium sending IPs while basic-tier shares a default pool.
Server health monitoring — wire AcelleMail's delivery_failed webhook to your incident channel. When a server hits N consecutive failures in M minutes, you get a Slack/PagerDuty page before customer complaints arrive.
Related articles#