Set up DMARC and see who's sending email using your brand's domain.

Static IP Deprecation: Postmark will no longer support IP allow-listing for our API

In the coming weeks, we’ll be making some changes to Postmark that will result in our API no longer being accessible on a static set of IPs. As such...

  • IP allowlisting for our API will no longer be supported starting August 23, 2023.
  • This change only applies to Postmark’s API and does not affect our SMTP and Webhook IPs.
Show details

Why are things changing?

Postmark’s infrastructure has changed a lot over the years, evolving from physical datacenter racks to an almost completely cloud-based system. We are using more and more managed services that provide a more secure and maintainable platform for Postmark so we can provide you with a more reliable and more scalable product. As a side effect of this, it is becoming increasingly difficult to support static, predictable IPs for various parts of our system.


We’ll retire support for static IPs on August 23, 2023 but we’ll be running a set of blackout periods before that to help you (and us!) catch any issues. Here’s what to expect:

  • July 26: First blackout period
    From 12.00pm-12.30pm ET (30 min)

  • August 2: Second blackout period
    From 6.00am-6.30am ET (30 min)

  • August 9: Third blackout period
    From 4.00am to 4.00pm ET (12 hours)

  • August 23: Final Cutoff

My Postmark setup relies on allowlisting. What do I need to do now?

We realize this change may be disruptive for some folks who rely on allowlisting, but there are a few alternative solutions you may wish to consider:

  • DNS lookups
    If you wish to continue allowlisting specific IPs, you may do so by performing DNS lookups to obtain the active IPs our API is advertising at any given time. This can be done by querying the A record for (ie. nslookup) at regular intervals based on the record’s TTL, and using this list of IPs to generate whitelist rules for your outbound traffic.

  • Host header allowlisting
    You may wish to configure your proxy/firewall to allow traffic based on the “Host” header (if it supports this functionality). This is a simple solution that requires very little effort, and is decoupled from IP addresses, although the downside is that the host header is more susceptible to forging than IP addresses (ie. host header injection). In some scenarios this may not be a desirable option.

  • IP range allowlisting
    There is a range of IPs that we can predict for our API, and thus we can provide a CIDR block that would cover this range, however it is a truly massive range (AWS infrastructure covers a huge portion of internet addresses) and it largely defeats the purpose of allowlisting. However, it is an alternative in case you have no other options.

We understand that these solutions aren’t on par with the static IP allowlisting that you might have in place right now, but we hope these approaches provide a helpful starting point for you to implement a solution that meets your requirements. If you have any questions or need any guidance around the specific products you may be using, just let us know. We’re happy to help!