What changed
On August 27, 2026, Postmark added IP Allowlisting for API email sending. An account can define up to ten trusted IPv4 CIDR ranges at the account level or on an individual Postmark Server. Sending requests to the Postmark API from outside the applicable list are rejected with HTTP 403. A Server-specific list overrides the account-level list for that Server; otherwise the account policy applies. Postmark intentionally makes allowlist changes through its UI rather than exposing them through the API. The control applies to API sends only and does not restrict SMTP sending.
Why it matters
API tokens are bearer credentials: if one leaks, an attacker can normally use it from infrastructure the account owner never intended to trust. Postmark's allowlist adds a second independent condition to API sending—source network location—so a valid token used from an unapproved IP cannot send mail. For SaaS products, that can reduce the blast radius of a credential leak and make transactional-email infrastructure easier to constrain around fixed servers, NAT gateways or data-center egress points. The boundary is deliberately narrow: it is not a firewall, it does not cover SMTP, and it can break legitimate sending when infrastructure uses dynamic or unexpected outbound IPs.
Account and Server policies provide two scopes
An account-level allowlist applies to API email sends across the account unless a Server has its own list. A Server-level list replaces the account list for that Server rather than merging with it. Teams can therefore keep a broad account default and make particularly sensitive sending streams narrower, but they need to understand the override behavior before rollout.
The API token is no longer sufficient on its own
Once allowlisting is enabled, Postmark checks the source IP of a send request against the configured IPv4 CIDR ranges. Requests from outside the list receive HTTP 403 even when the API credential is otherwise valid. This does not eliminate the need to rotate and protect tokens, but it creates another barrier to off-network misuse.
Configuration is deliberately kept out of the API
Postmark says allowlists are changed through the UI by design. That makes it harder for an attacker or buggy automation holding an API credential to relax the same control that protects that credential. Teams should still restrict who has dashboard access because UI privileges now include the ability to change a significant sending-security boundary.
SMTP remains outside the allowlist
Postmark explicitly says SMTP sending is not checked against the configured ranges. A product using both API and SMTP therefore has two different security models. Teams that want the new boundary to meaningfully reduce sending risk should inventory every send path rather than assuming enabling the setting covers the whole Postmark account.
Static egress becomes an operational prerequisite
IP allowlisting works best when the application sends through predictable egress such as a fixed server address or NAT gateway. Serverless and cloud architectures with changing outbound addresses may need static-egress infrastructure before enabling the feature. A mistaken or incomplete list can convert an email-security improvement into a production outage.