Before installing BillionMail, confirm that the VPS supports its deployment method, the required ports are available, your provider permits mail traffic, and you control the DNS and reverse DNS needed for your chosen hostname. A server already running aaPanel Mail Server needs a deployment plan before another mail stack is added.
This is the preparation guide for our separate BillionMail series. We checked an existing Ubuntu lab on 16 October 2026 using read-only commands. BillionMail was not installed, no existing service was stopped and no DNS or firewall settings were changed.
![[Image: attachment.php?aid=365]](https://adminsforum.com/attachment.php?aid=365)
Formatted summary of our actual port checks, not a BillionMail dashboard screenshot. Existing mail and web services already occupy the relevant default ports.
1. Choose an isolated installation target
Treat an existing hosting server as occupied until you inspect it. In our lab, the SMTP ports were already held by the current mail stack, mailbox ports by Dovecot and web ports by Nginx. Starting a second stack with the same host-port bindings would create conflicts.
For a first tutorial deployment, use an isolated Linux VPS or equivalent environment with its own planned network access and recovery path. A container is not automatically isolated from host-port conflicts: published container ports still need compatible host bindings. Changing only the dashboard port does not resolve a conflict on SMTP port 25.
Do not stop the working mail service just to make an installer proceed. Existing mailboxes, queues, websites, certificates and scheduled tasks may depend on it. Any migration needs its own backup, cutover and rollback plan.
2. Check the current requirements
BillionMail's official Quickstart currently lists Linux on amd64 or arm64, with minimum hardware of one CPU core, 1 GB RAM and 20 GB disk. Treat these as published minimums, not a capacity promise for your mailbox count, retention period or sending workload. The Docker deployment requires Docker and Docker Compose.
Before provisioning, confirm that the intended OS and architecture are supported by the deployment instructions you will actually use. Record the release or commit being deployed. A moving development branch and a released version are not necessarily the same software.
These commands inspect a Linux machine without installing packages:
uname reports architecture; df reports filesystem capacity; free reports memory. Check the mount that will hold application and mail data too. Our occupied lab reported x86_64, 26 GB available on its root filesystem and approximately 2.6 GiB available memory. Resource headroom did not remove its port conflicts.
3. Check local listeners before opening firewall rules
On the candidate server, inspect listening TCP ports as an administrator:
In the output, compare Local Address
ort with the deployment's published ports and note the process responsible. A listener on all addresses is different from a listener restricted to one address. Our exact local findings were:
4. Plan mail traffic in both directions
Port 25 is used for normal server-to-server SMTP. An authenticated client submission port such as 587 does not simply replace it for direct delivery to other mail servers. Ask the VPS provider whether inbound and outbound port 25 are permitted and whether reverse DNS can be configured. Record any sending limits too.
The other listed mail ports serve different client protocols: 465/587 for submission, 143/993 for IMAP and 110/995 for POP3. Check the current deployment configuration and the clients you intend to support. A local listener proves only that a process is bound; it does not prove provider routing, firewall reachability, TLS or authentication succeeds.
Before deployment, test external reachability separately from local binding. For an outbound connection test, use a permitted remote SMTP destination and stop after the connection/banner check unless you are deliberately testing an authorized message. Our preflight did not test a new BillionMail server's inbound or outbound delivery.
5. Choose the hostname and prepare DNS access
Choose an explicit hostname, such as mail.example.com, for the new server. The example is a placeholder; do not point records to an unprepared server. Keep the existing mail domain's MX unchanged until the new destination is ready and a cutover is planned.
BillionMail's Domain screen supplies the DNS values for its domain configuration. Plan to verify the A/AAAA, MX, SPF, DKIM and DMARC records against those generated values. PTR/reverse DNS is normally configured by the IP provider. A new DKIM key must come from the actual installation; do not reuse a screenshot's sample key.
Keep a record of the old DNS configuration before editing. DNS propagation and cached records mean a migration may temporarily reach both old and new destinations. Plan how both will handle mail during that period rather than assuming the dashboard's Save button completes the migration instantly.
6. Reserve certificate and management access
The Docker guide documents HTTP/HTTPS ports alongside mail ports. Its documented Let's Encrypt HTTP validation requires port 80, with the hostname resolving appropriately. Check which process receives that request before expecting automatic issuance to work.
Separate the management address from mailbox addresses in your notes. Confirm how you will obtain and verify the access URL after installation, secure the administrator account, deploy trusted certificates and preserve recovery access. Do not publish configuration files containing passwords, private keys or API tokens in a tutorial.
7. Prepare recovery and the first verification tasks
Before installation, decide where backups will live and how you will restore the application configuration, mail data and databases. A copy on the same disk is not protection against loss of that disk. Keep the target disposable until you have tested the required functions.
The installation lesson should verify service/container health and trusted management access first. Later lessons will cover adding a mail domain, generated DNS, certificates, mailboxes, sending and receiving, contact lists, campaigns, bounce handling and recovery. An installer completing is not evidence of inbox delivery or a particular spam-test score.
Ready to install?
Proceed when the target environment is identified, port conflicts are resolved by design, provider mail policy is confirmed, DNS/PTR control is available and recovery is prepared. Our existing mail lab did not pass the port-conflict check for an additional default stack; it remains in service for the aaPanel Mail Server tutorials.
References
BillionMail Quickstart requirements and ports.
BillionMail Docker deployment configuration.
BillionMail domain, DNS and certificate setup.
More BillionMail how-to guides
This is the preparation guide for our separate BillionMail series. We checked an existing Ubuntu lab on 16 October 2026 using read-only commands. BillionMail was not installed, no existing service was stopped and no DNS or firewall settings were changed.
Formatted summary of our actual port checks, not a BillionMail dashboard screenshot. Existing mail and web services already occupy the relevant default ports.
1. Choose an isolated installation target
Treat an existing hosting server as occupied until you inspect it. In our lab, the SMTP ports were already held by the current mail stack, mailbox ports by Dovecot and web ports by Nginx. Starting a second stack with the same host-port bindings would create conflicts.
For a first tutorial deployment, use an isolated Linux VPS or equivalent environment with its own planned network access and recovery path. A container is not automatically isolated from host-port conflicts: published container ports still need compatible host bindings. Changing only the dashboard port does not resolve a conflict on SMTP port 25.
Do not stop the working mail service just to make an installer proceed. Existing mailboxes, queues, websites, certificates and scheduled tasks may depend on it. Any migration needs its own backup, cutover and rollback plan.
2. Check the current requirements
BillionMail's official Quickstart currently lists Linux on amd64 or arm64, with minimum hardware of one CPU core, 1 GB RAM and 20 GB disk. Treat these as published minimums, not a capacity promise for your mailbox count, retention period or sending workload. The Docker deployment requires Docker and Docker Compose.
Before provisioning, confirm that the intended OS and architecture are supported by the deployment instructions you will actually use. Record the release or commit being deployed. A moving development branch and a released version are not necessarily the same software.
These commands inspect a Linux machine without installing packages:
Code:
uname -m
df -h /
free -m3. Check local listeners before opening firewall rules
On the candidate server, inspect listening TCP ports as an administrator:
Code:
ss -lntport with the deployment's published ports and note the process responsible. A listener on all addresses is different from a listener restricted to one address. Our exact local findings were:- 25, 465 and 587: existing mail-service master process.
- 110, 143, 993 and 995: Dovecot.
- 80 and 443: Nginx.
4. Plan mail traffic in both directions
Port 25 is used for normal server-to-server SMTP. An authenticated client submission port such as 587 does not simply replace it for direct delivery to other mail servers. Ask the VPS provider whether inbound and outbound port 25 are permitted and whether reverse DNS can be configured. Record any sending limits too.
The other listed mail ports serve different client protocols: 465/587 for submission, 143/993 for IMAP and 110/995 for POP3. Check the current deployment configuration and the clients you intend to support. A local listener proves only that a process is bound; it does not prove provider routing, firewall reachability, TLS or authentication succeeds.
Before deployment, test external reachability separately from local binding. For an outbound connection test, use a permitted remote SMTP destination and stop after the connection/banner check unless you are deliberately testing an authorized message. Our preflight did not test a new BillionMail server's inbound or outbound delivery.
5. Choose the hostname and prepare DNS access
Choose an explicit hostname, such as mail.example.com, for the new server. The example is a placeholder; do not point records to an unprepared server. Keep the existing mail domain's MX unchanged until the new destination is ready and a cutover is planned.
BillionMail's Domain screen supplies the DNS values for its domain configuration. Plan to verify the A/AAAA, MX, SPF, DKIM and DMARC records against those generated values. PTR/reverse DNS is normally configured by the IP provider. A new DKIM key must come from the actual installation; do not reuse a screenshot's sample key.
Keep a record of the old DNS configuration before editing. DNS propagation and cached records mean a migration may temporarily reach both old and new destinations. Plan how both will handle mail during that period rather than assuming the dashboard's Save button completes the migration instantly.
6. Reserve certificate and management access
The Docker guide documents HTTP/HTTPS ports alongside mail ports. Its documented Let's Encrypt HTTP validation requires port 80, with the hostname resolving appropriately. Check which process receives that request before expecting automatic issuance to work.
Separate the management address from mailbox addresses in your notes. Confirm how you will obtain and verify the access URL after installation, secure the administrator account, deploy trusted certificates and preserve recovery access. Do not publish configuration files containing passwords, private keys or API tokens in a tutorial.
7. Prepare recovery and the first verification tasks
Before installation, decide where backups will live and how you will restore the application configuration, mail data and databases. A copy on the same disk is not protection against loss of that disk. Keep the target disposable until you have tested the required functions.
The installation lesson should verify service/container health and trusted management access first. Later lessons will cover adding a mail domain, generated DNS, certificates, mailboxes, sending and receiving, contact lists, campaigns, bounce handling and recovery. An installer completing is not evidence of inbox delivery or a particular spam-test score.
Ready to install?
Proceed when the target environment is identified, port conflicts are resolved by design, provider mail policy is confirmed, DNS/PTR control is available and recovery is prepared. Our existing mail lab did not pass the port-conflict check for an additional default stack; it remains in service for the aaPanel Mail Server tutorials.
References
BillionMail Quickstart requirements and ports.
BillionMail Docker deployment configuration.
BillionMail domain, DNS and certificate setup.
More BillionMail how-to guides
- Send API for transactional email
- WordPress email through BillionMail SMTP
- Import contacts, groups and tags
- Email templates explained
- SMTP relay with Amazon SES, Brevo or Mailgun
- Mailboxes and webmail
- Campaign analytics explained
- IP warm-up plan
- Move from Mailchimp or Sendy
- Add a second sending domain
