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...
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
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 api.postmarkapp.com (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!
