How to Use IP Pools for Better Deliverability in Postal

In my Postal SMTP server setup guide, we built a fully functioning send-only mail server and successfully sent our first email using the server’s primary IP address.

Now it’s time to take things further.

In this guide, we’ll learn how to configure IP pools in Postal to send emails from multiple IP addresses instead of relying solely on your server’s main IP.

This setup helps improve deliverability, isolate sender reputation, and add flexibility – especially when working with multiple clients or high-volume sending.

To make this work, we’ll use Floating IPs from Hetzner, which allow you to attach extra IP addresses to your server without losing them if the server is ever rebuilt.

We’ll cover everything from assigning and configuring Floating IPs to setting up DNS records, building your IP pools in Postal, and fine-tuning priorities for smart sending behavior.

Why Use IP Pools and Floating IPs?

Using IP pools in Postal along with Floating IPs gives you greater control over how your emails are sent – and boosts deliverability, flexibility, and reputation management.

Here’s why IP pools and Floating IPs are worth setting up:

• Better deliverability: You can isolate traffic (e.g. newsletters, transactional emails, client mail) to different IPs, so if one gets flagged, the others aren’t affected.
• Easier reputation management: Separate IPs mean cleaner reputation tracking per sender, project, or email type.
• Scalable sending strategy: Add more IPs as you grow without disrupting existing mail flow.
• Portability: If your server goes down or you need to rebuild it, you can reassign your Floating IPs to a new server without losing them.
• Reputation retention: Since your IP address stays the same even across servers, you don’t lose the reputation you've built.

Combined, they let you build a more robust and professional email sending setup.

Setting Up Floating IPs

To send emails from multiple IP addresses in Postal, you’ll need to set up Floating IPs on your server.

This example walks you through creating and configuring two Floating IP sets (IPv4 + IPv6 pairs) using Hetzner, though the process is similar with other providers that support floating or additional IPs.

Create Floating IPs in Hetzner

1. In the Hetzner dashboard, go to Floating IPs from the left menu
2. Click Add Floating IP
3. Choose the same location as your Postal server
4. Add two IP pairs:
   1. Two IPv4 addresses
   2. One IPv6 block (/64) – you’ll create multiple usable IPv6 addresses from it (e.g. ::1, ::2)
5. Give each IP set a clear name to stay organized

Assign Floating IPs to Your Server

For each IP address:

1. Click the three-dot menu next to the IP
2. Choose Assign
3. Select the server where Postal is installed

Configure the IPs on Your Server

Although the IPs are now assigned, your server still doesn't know how to use them.

You need to manually configure the IPs in your network settings to make them active and routable.

To do this, access the server and create a configuration file inside the /etc/netplan/ directory. You can do this by running:

sudo vim /etc/netplan/60-floating-ips.yaml

Then add your IPs. Replace the addresses below with your actual ones:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      addresses:
        - 89.107.50.13/32           # Floating IPv4 - ip-set-1
        - 2a04:2f8:1c0c:a0a2::1/64  # Floating IPv6 - ip-set-1
        - 90.92.38.139/32           # Floating IPv4 - ip-set-2
        - 2a04:2f8:1c0c:a0a2::2/64  # Floating IPv6 - ip-set-2

Use /32 for IPv4 and /64 for IPv6.

You can create multiple IPv6 addresses from your block by simply appending different values (like ::3, ::4, etc.).

Apply and Verify

Set the proper permissions to avoid receiving a warning:

sudo chmod 600 /etc/netplan/60-floating-ips.yaml

Apply the configuration:

sudo netplan apply

Check that your new IPs are active:

ip addr show

You should see all assigned IPs listed under your network interface (eth0).

Creating an IP Pool

Before you can use multiple IPs for sending, you need to enable IP pool support in Postal.

Open the Postal configuration file:

sudo vim /opt/postal/config/postal.yml

Under the postal: section, add the following line:

postal:
  use_ip_pools: true

Save and close the file, then restart Postal:

sudo postal restart

Once Postal is back up, head to the web interface:

• From the top menu, click on IP Pools
• Click Create the first IP pool
• Give your pool a descriptive name (e.g. dedi, client-a, transactional) and click Create IP pool

You’ll now see an empty table where you can start adding IP addresses to this pool.

Adding Two IP Pairs to the Pool

Now that you've configured two Floating IP pairs on your server, it’s time to add them to your IP pool.

If you name your pool dedi like me, here’s how you can add each IP pair to it:

To add them:

• Click Add an IP address to pool
• Enter the IPv4, IPv6, and Hostname for the first pair
• Enter a priority value
• Click Create IP address
• Repeat for the second pair

If you want to use just one specific Floating IP set for sending, make sure only that set is in the IP pool. If you add multiple IP sets to the same pool, Postal will use them all – based on their priority values.

Each IP set in a pool can have a priority between 1 and 100. This priority determines the likelihood that a specific IP will be chosen when sending an email. The higher the number, the more likely it is to be used.

By default, the priority is set to 100.

DNS Setup

Now that you've added your IP pairs to the pool, it's time to configure the DNS records for each one.

This step is crucial – without proper DNS records, your emails might never make it to inboxes or could be flagged as spam.

A and AAAA Records

For each IP pair, you’ll need to create both A and AAAA records that point to the respective IPv4 and IPv6 addresses.

Here’s how you would configure them based on the example IPs and hostnames:

Each hostname must resolve to the exact IPs you've assigned in the pool.

PTR (Reverse DNS)

Once you've configured your A and AAAA records, the next step is to set the PTR (Reverse DNS) records for your Floating IPs.

This is important because many mail servers check if your IP address points back to the same domain name you're sending from. If it doesn't match, your email might get flagged as spam or blocked entirely.

Here’s how to do it in Hetzner:

1. Log in to the Hetzner Cloud Console and navigate to your project.
2. From the left-hand menu, click Floating IPs.
3. You’ll see your assigned IPv4 and IPv6 addresses listed.
4. For each IP:
   1. Click the three-dot menu on the right.
   2. Choose Edit Reverse DNS.
   3. Enter the matching hostname for that IP.

Make sure your PTR record matches the A/AAAA record exactly. This reverse DNS match is a key requirement for being accepted by many recipient mail servers.

SPF Record

To improve your email deliverability and avoid getting flagged as spam, you need to configure SPF (Sender Policy Framework) records in your DNS.

SPF helps receiving mail servers verify that your server is authorized to send emails for your domain.

If you followed my Postal setup guide, you should already have a global SPF record for your server’s primary IPs that looks something like this:

Now that we’ve created a dedicated IP pool using Floating IPs, we’ll need a separate SPF record for them:

Finally, update your global SPF record to include the new one:

This setup ensures that all IPs in your dedi pool are authorized to send emails for any domains you add in Postal.

Why SPF Can’t Fully Isolate IP Pools

If you include both your dedi pool IPs and your primary server IPs in the same SPF, receiving mail servers will treat all of those IPs as valid senders for @example.com – even if, at the Postal level, you’ve told Postal to use only the dedi pool.

In other words, including both in one SPF means you cannot restrict the domain to just the dedi pool.

This means:

• No True Isolation: Even if you plan to send some mail only from the dedi pool, the SPF record still authorizes your primary server IPs (and later, any other pools you include). As a result, you cannot stop a hard-coded domain from accidentally using the wrong IP if Postal ever sends from it.
• The Return-Path Problem: Postal always uses a single return-path (MAIL FROM) hostname – something like rp.mail.example.com – for every email it sends. The receiving server checks SPF against that return-path hostname. If that hostname’s SPF record includes both your primary and dedi IPs, there’s no way to tell Postal "when sending from the dedi pool, use a different return-path". Postal simply doesn’t let you override the return-path per domain or per pool. As a result, even if you add a separate spf.dedi.example.com record, Postal will still send everything as @rp.mail.example.com, so the only SPF that actually matters is the one on rp.mail.example.com, and it will include all your IPs.

You have two choices:

• Live With It: Accept that your SPF lists both (or all) of your IPs under the single return-path hostname. Any sending domain pointing at that SPF can egress on any of them. You get simplicity and fewer records, but you lose the guarantee that Domain A will only ever use the dedi pool.
• Run One Postal Instance Per Pool: If you truly need Domain A to use only the dedi IPs and Domain B to use another pool IPs, you must run two separate Postal servers – each with its own hostname and its own rp.* return-path. That way, Postal’s built-in return-path SPF is tied to just one pool, and you regain full separation at the cost of extra infrastructure.

If you’re not running Postal in a mission-critical environment where strict IP separation is absolutely required, it’s perfectly acceptable to live with a combined SPF record.

In practice, the pool-level routing that Postal provides has been reliable, and I’ve never experienced misrouted or mis-authorized mail because of this setup.

If you ever find you need airtight isolation, you can think about the two-instance approach – but for most use cases, trusting Postal’s pool assignment and a single SPF record is simple and works just fine.

Put Your IP Pool Into Action

Now that your IP pool is set up and your DNS is configured, it’s time to put it to use.

Go back to your organization in Postal, and you’ll see a new tab called IPs. Open it and select the IP pool you just created (e.g. dedi). This enables your organization to use that pool for sending across all mail servers associated with it.

If you assign multiple IP pools, you can choose which one to use for each mail server from the Server Settings.

Conclusion and Final Thoughts

That’s it – you’ve successfully set up and configured IP pools in Postal using Floating IPs!

This setup gives you more control over your sending infrastructure, helps protect your IP reputation, and improves deliverability by isolating different types of email traffic.

If you ever need to add more IPs or create additional IP pools (for example, for new clients or projects), just repeat the same process:

• Add new Floating IPs
• Configure them on your server
• Update DNS records (A, AAAA, PTR, SPF)
• Add them to an IP pool in Postal
• Assign the pool to the appropriate organization

If you run into any issues or need further help, feel free to revisit this guide or reach out for assistance.

If you found value in this guide or have any questions or feedback, please don't hesitate to share your thoughts in the discussion section.