Auto-incrementing Bounce IDs will exceed signed 32-bit integers in the next 2-3 months. If you store these IDs in a database, or process them using your own code, please ensure you update your DB/application to use int64 values. As an even better solution, instead of using Bounce IDs for your application needs, consider switching to using our new Suppressions API, which avoids the need for this ID altogether. Please let us know if you have any questions.
To help increase the capacity of our API we plan to add new public endpoints in a few weeks. If your application restricts access to public IPs, please ensure that the following IPs are whitelisted:
We intend to start moving API traffic to these new IPs on March 16, 2020, so please make sure these IPs are allowed by any firewall or routing rules you may be using.
We wanted to give you an update to let you know of an upcoming change in our data retention policy for bounce events. These changes will go into effect on April 1st (yes, really).
As mentioned in our current data retention policy, after 45 days we remove all original message content and metadata from our system. For bounce reports, however, even though we remove the original message content after 45 days, metadata and the content of the actual bounce message have historically been retained for up to 1 year to enable troubleshooting.
In order to simplify our data retention policies, and also make sure that we do not keep data for longer than necessary, we are planning to make a change to this policy. As of today, new bounces will be deleted from our system 45 days after they are received. In short, our updated data retention policy has been simplified so that after 45 days we remove all original message content and metadata from our system, with no exceptions.
With this change, you will no longer see bounces older than 45 days when searching in your Activity feed, but you will always be able to see a searchable, full list of suppressed addresses within the Suppressions tab. Since bounces reactivation has historically been tied to BounceIDs, it has been necessary for customers to query for bounces, get a special BounceID, and then use the `/reactivate` endpoint with that ID. Depending on your workflow, reactivating bounces after 45 days using this process will no longer work. But, we’ve got you covered:
With the recent release of our Suppression UI and API you can easily search for inactive addresses, see the reason the address is inactive (block, hard bounce, etc.), and reactivate the address if possible. We recommend using this new API for all address reactivations, because it only requires one API call, rather than two, and will ensure addresses are reactivated, regardless of the suppression reason.
As always, if you have any questions or concerns about any of these changes, please let us know.
Back in March 2018 we released modular webhooks, allowing you to choose which events you’d like to send to each specified hook URL. Up to now this has only been possible through the UI. We’re happy to announce that we just released a brand new
/webhooks API endpoint, which brings support for the setup and maintenance of modular webhooks, as well as some of the Message Stream functionality we’ve been working on.
The new endpoint lets you list all existing webhook configurations; retrieve a specific configuration; and of course create, update, and delete modular webhook configurations.
Note that at this point we haven’t made any changes to how our
/servers endpoints work with regard to webhooks. Setting/updating webhooks via that endpoint will continue to set a single hook for your default transactional stream. We plan to update this in the future, but we’ll give you plenty of advance notice when that happens.
Updated December 3, 2019 with new key dates.
We wanted to let you know about a few changes we’re making to SMTP sending in the coming weeks to make this endpoint more secure. These changes will only affect sending via SMTP. If you use only the Postmark REST API to send, no further action is required on your part.
The following changes will be made to our supported SMTP TLS configuration:
We understand that this type of change can be disruptive, so we want to provide you with ample time to test and verify that your application will be able to continue sending mail using the updated security settings.
These are the key dates for these changes:
The most significant change, which might affect you, is that we are disabling TLSv1.0 on February 1, 2020. This protocol is old and vulnerable, so we will be rejecting connection requests that use TLSv1.0.
Before the cutover date on February 1, 2020, we recommend that you perform some tests against the following temporary testing endpoint:
future-smtp.postmarkapp.com. This endpoint matches the changes we’ll be making, so if everything works as expected, you’re good to go. Just switch back to using
smtp.postmarkapp.com and no further action will be needed.
If you run into any issues using the temporary endpoint (i.e., your SMTP client is unable to connect), please change your SMTP client configuration to use TLSv1.1 or higher, or upgrade your SMTP client to a version that supports TLSv1.1 or higher. Documentation for SMTP clients will typically provide configuration options, where you can see how to set the connection to use TLSv1.1 or higher. If there is not a version of your SMTP client that supports TLSv1.1, you will need to select a new SMTP client that does support TLSv1.1 or higher in order to continue using Postmark.
If you are unable to get an SMTP client that is compatible with TLSv1.1 or higher working with the new SMTP endpoint, please contact our support team and let us know the following details:
We may be able to provide specific instructions for opting into using newer TLS configurations.
Once again, we are going to disable TLSv1.0 on February 1, 2020. Please perform all testing and make any necessary code changes before this date.
Please let us know if you have any questions about these changes.
We have added the following IPs to our SMTP endpoint service. If you send email using SMTP and explicitly whitelist our SMTP endpoint IPs, these will need to be added:
On Monday, May 20th we made a change to the way we process SMTP headers for emails that are sent with SMTP. Please note that this change does not affect sending via the API.
Historically, when Postmark accepted messages over SMTP, we have constructed the
Bcc headers for messages sent to show only the subset of recipients you specify during sending. In some uncommon cases, this behavior meant that not all recipients would be visible in the message that is delivered to your recipients.
With this update, we will ensure that the recipients that are visible in your messages’
Cc headers are the same as what will be shown to the final recipients of your messages. We will no longer reconstruct them based on our older behavior, which, in some uncommon cases, could have prevented some recipients from being displayed in the final email that we deliver.
Read the blog post for full details.
We will disable support for SSL v3 on March 7th, and going forward our servers will only support encrypted SMTP connections using TLS (1.0 - 1.3). Most customers will not be affected by this change. However, you can double check that your SMTP client is compatible by temporarily sending mail through
future-smtp.postmarkapp.com instead of
future-smtp.postmarkapp.com points to the new servers (and new IPs) and it does not allow SSL v3 connections. If you use connection to test and everything works well, no further action is needed and sending should continue through our current endpoint:
If you are having trouble connecting over
future-smtp.postmarkapp.com you will need to update your SMTP client. Please can let us know if you are not able to resolve or update your SMTP client before the switchover date.
This release includes support for our new metadata feature. You may now include metadata with your outbound messages, and Postmark will include that data in webhook payloads, message details, and message searches. See the full release announcement here.
This release also enables you to specify the BaseURL for each API request, making testing with Guzzle a lot easier.
Finally, you can now enable, or disable SMTP API Error Webhooks for Servers using the Admin Client.
As always, we hope this release helps you get even more value from Postmark, and please feel free to contact us if you have any questions or requests!
Our Swiftmailer Transport for Postmark has been updated with some minor enhancements, and it also now works with SwiftMailer 6.
This release of the official .net client for Postmark includes the addition of the Domains APIs, support for our new custom metadata feature, as well as the “EnableSMTPErrorHook” property to the the Create and Edit Server endpoint methods.
You can now add custom metadata to your emails, and we'll pass that same data back to your system through our webhooks.
You can now add multiple webhook URLs for a server and choose which events you’d like to send to each specified URL.
Postmark can now notify your application of delivery events via webhooks so you can do a variety of things like feed delivery events into an internal system, provide delivery even notifications to your customers, or aggregate delivery even data to see patterns and respond accordingly.