IP Allowlisting adds a layer of protection to API sending. You define the IP ranges allowed to send email through the Postmark API and a send request from any IP outside them is rejected with a 403 status code.
It's built for teams that know the details of their sending infrastructure and want to lock it down further. If you can name the exact IPs or IP ranges your application sends from — a fixed server, a NAT gateway, a data center egress point — allowlisting turns that knowledge into an enforced boundary.
You add up to 10 IP ranges (in IPv4 CIDR format) at the account-level or per Server. Any send request to the Postmark API from an IP inside your ranges goes through as usual. Any send request from an IP outside them is rejected with a 403 status code.
203.0.113.0/24 # a /24 block: 203.0.113.0 through 203.0.113.255
198.51.100.24/32 # a single IP addressAllowlisting gates the email send endpoints of the Postmark API. The rest of the API is unaffected — managing Templates, reading stats, searching messages, handling suppressions, and every other call works from any IP with a valid token.
Note. Allowlisting is protects ONLY API email sends. SMTP sending is not checked against your ranges.
Ranges are set on a Server or on your account, not on individual Message Streams. Ranges on a Server cover every Stream on that Server, and ranges on your account cover all API sending across the account.
Ranges set on a Server apply to that Server instead of your account-level ranges. They aren't combined.
| Account ranges | Server ranges | What applies to that Server |
|---|---|---|
| Set | Not set | Your account ranges |
| Set | Set | The Server's ranges only — account ranges are ignored for this Server |
| Not set | Set | The Server's ranges |
| Not set | Not set | No IP restriction |
That gives you one account-wide default, with per-Server overrides for the Servers that send from somewhere different.
Allowlisting rests on one assumption — that you can name every IP address your application sends email from. A range that's too broad still blocks everything outside your infrastructure. A range that's too narrow blocks your sending. If you're unsure how tight a range should be, start wider than you think you need and narrow it once you've confirmed what's actually sending.
Your infrastructure will help decide whether this is a good fit:
Good fit — stable, enumerable IPs
Poor fit — unpredictable or unbounded IPs
If your setup looks more like the second group, allowlisting will potentially cost you more in blocked emails than it earns you in protection. Leave it off.
If those sends go through, your ranges cover the infrastructure you actually send from. If they get a 403 status code with a 1480 error code, the response tells you which IP was refused, and you can add it before anything real is at stake.
While you're building the list, check for sending paths that are straightforward to overlook:
Allowlisting is configured in the Postmark UI. There's no API for reading or writing your ranges.
Setup happens in two stages: you add your ranges, then you turn the allowlist on. Nothing is enforced until you turn it on, so you have room to get the list right before it affects any sending.
For one Server:
Account-wide, for every Server:
You can add as many ranges as you need up to 10. While one range is being added, editing the rest of the list is locked until that add finishes.
Your ranges do nothing until you enable the allowlist. Switch it on and confirm on the prompt — the confirmation is there because enforcement begins the moment you accept it, and any sending IP you've missed starts getting rejected.
Read that prompt rather than clicking past it. The most common allowlisting problem is an incomplete list.
The toggle is also your way out. If email you expected to go through starts getting rejected and you can't immediately tell which range is wrong, switch the allowlist off. Sending returns to normal, and you can correct the list and turn it back on without any rush. You'll see the same confirmation prompt on the way off.
A send from an IP outside your ranges fails with an HTTP 403:
{
"ErrorCode": 1480,
"Message": "You are not authorized to send emails from your current IP address: 198.51.100.24."
}The response includes the IP address Postmark detected so you can compare it against your ranges directly. If it's an IP you recognize, your allowlist might be missing a range.
A 403 status code here is a configuration result, not a transient failure. If retrying from the same IP produces the same response, treat it the way you'd treat other errors: log, alert, and don't queue it for retry. Your application logs are your signal.
Note. Allowlisting is a control on the Postmark send path, so a 403 with error code 1480 confirms the block came from IP Allowlisting. A 403 with an HTML body and no Postmark message is coming from network-level protections that sit in front of Postmark, and adding an IP to your allowlist won't change it. Send us the full response and we'll trace it.
Each Server and account is configured on its own. If you run a large fleet of Servers, set your account-level ranges as the default and override only the Servers that need something different.
Allowlisting is 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.
It's a different thing from allowlisting Postmark's IPs. Allowlisting runs in the other direction: you're telling Postmark which of your IPs may send through the API. It's unrelated to allowlisting Postmark's own sending or webhook IPs inside your firewall.
SMTP is not supported. Allowlisting is protects ONLY API email sends. SMTP sending is not checked against your ranges.
If email is being blocked right now and you need it flowing again, switch the allowlist off first, then troubleshoot. From there, check three things in order. First, confirm the failure is actually ours: a 403 with error code 1480 confirms IP Allowlisting is the cause; a 403 with an HTML body and no Postmark error message is a network-level block, not an allowlisting result. Second, that the range actually covers the IP named in the 1480 message. Third, whether the Server has its own ranges that are overriding the account-level ranges you think are active — Server ranges override completely.
Allowlisting only rejects sends for accounts and Servers that have ranges configured, and it always returns error code 1480 when it's the cause. If you haven't set any ranges and a send is still being refused, check the response for that code first. No 1480 means the block isn't coming from IP Allowlisting — contact support with the full response and we'll dig in.
Not today. You supply your own ranges.
The IP, the account, and the timestamp. No message content.