Introducing IP Allowlisting
Good security is layered and each layer does a job the others can't. Scoping a token to a Server limits what it reaches. Rotating a token limits how long it lasts. Neither can say anything about where a request came from.
We've been hard at work to ship a new layer of protection that can.
IP Allowlisting is a new Postmark security feature that lets you name the infrastructure your email should come from. It's available now on all Postmark plans at no extra cost. It's off until you turn it on.
How IP Allowlisting works #
You add up to 10 IP ranges, in CIDR format, that are allowed to send email using the Postmark API. Send requests from outside those ranges are rejected with a 403 status code that includes the IP the request came from.
You can set your ranges in two places:
On a Server. The ranges apply to that Server, covering every Message Stream on it. This is where we'd suggest starting.
On your account. The ranges apply to every Server you have. When a Server has ranges of its own they will override account level settings.
That's it! A straightforward security control to protect your API sending. Protect individual Servers or across your account.
If you don't write CIDR blocks often, it's a quick 30 seconds to get familiar with them and the correct notation. CIDR blocks allow you to enable a grouped collection of IP addresses (aka ranges.) A CIDR block is an IP address followed by a suffix that says how many addresses it covers. The smaller the suffix, the wider the range:
198.51.100.24/32 one address, and only that address
203.0.113.0/24 256 addresses: 203.0.113.0 through 203.0.113.255
203.0.0.0/16 65,536 addresses: 203.0.0.0 through 203.0.255.255So a /32 pins the allowlist to a single machine, and a /24 covers a subnet. Most teams end up somewhere in that span.
Where you find your own ranges depends on how you send. A single VM has a static public IP you can read off your provider's dashboard. Cloud workloads behind a NAT Gateway send from the gateway's addresses, not the individual instances. On-premise infrastructure sends from whatever egress your network team has configured, and they'll know it.
The one that matters is the IP your API requests actually arrive from, which isn't always the one you'd guess. If you're unsure, a blocked request will tell you: the 403 response includes the IP Postmark detected.
Is IP Allowlisting right for you? #
Allowlisting earns its keep when your API sending comes from a known, stable set of IPs. It could be your own servers, a fixed cloud egress, or a managed NAT gateway. If you can name the IPs your email should come from, you can reject everything else.
It's a particularly good fit if you send on behalf of your own customers, operate under a compliance regime that expects network-level controls, or run sending from infrastructure a security team already governs.
If your sending IPs change often or can't be enumerated — serverless with no NAT layer, autoscaling fleets with no fixed egress, sending triggered from CI runners — allowlisting will work against you. You'd be updating ranges constantly, and any range you miss blocks your own email. In that case it isn't the right tool, and leaving it off is a reasonable answer.
How to turn it on without blocking your own email #
The failure mode here isn't subtle: a range that's missing one of your own IPs blocks your own sending. Two things prevent it.
Start wider than you think you need. A range that's broader than necessary still rejects everything outside your infrastructure. A range that's too narrow rejects you. Narrow it once you've confirmed what's actually sending.
Test on a Server you don't depend on. Spin up a test Server, add your ranges there, and send to it from your production environment. If those sends go through, your ranges cover the infrastructure you really send from. If they don't, the 403 names the IP you missed, and nothing real was at stake.
Note: Like we mentioned above, start at the Server scope rather than the account scope. Account ranges apply to every Server at once, so an incomplete range affects all of your API sending. Prove your ranges on one Server, then widen.
Once your ranges are in place, you turn the allowlist on. Nothing is enforced until you do, and you can switch it back off at any point — which is also the fastest fix if a send you expected gets rejected.
Good to know #
A few things to plan around as you set this up.
- Allowlisting only applies to email-sending endpoints. SMTP sends aren't checked against your ranges. If you don't use SMTP on a Server, disabling it there adds another layer of protection. Your other API calls — managing Templates, reading stats, handling suppressions — work from any IP with a valid token; allowlisting is a control on sending specifically.
- It's configured in the UI by design. Keeping allowlist changes out of the API adds another layer of control over who can touch your sending protections.
- Each Server and your account each keep their own settings. If you run a large fleet, set your account ranges as the default and override only the Servers that send from somewhere different.
Note: Allowlisting is a control on Postmark's send path, not a firewall or a WAF. It decides which IPs can send email through your account, and it doesn't change network-level security rules that sit in front of Postmark. An IP on your allowlist can still be blocked by protections outside Postmark's send path.
We're already looking at what comes next here, and the teams using it will shape that. If there's something you need it to do, tell us.
How IP Allowlisting differs from dedicated and shared IPs #
Two different things share the word "IP" here and they're worth separating.
Dedicated and shared IPs are about the address your email is sent from — the sending identity receiving mail servers see, and what your sending reputation attaches to. Shared IPs are the default on Postmark: carefully vetted pools, which is what lets you start sending without warming anything up. Dedicated IPs are an add-on for higher-volume senders.
IP Allowlisting is about the address your API requests arrive from — your application's egress, not Postmark's sending infrastructure. Turning it on doesn't change which IPs your email is delivered from, and it has no bearing on reputation or warmup.
It's also the reverse of allowlisting Postmark's IPs inside your own firewall. There, you're deciding what your network accepts from us. Here, you're deciding what we accept from you.
Set it up #
If your API sending comes from IPs you can name, allowlisting is a few minutes of work for a real reduction in where a token can be used.
