✉️Need a safe space to test your email integrations? Introducing Sandbox Mode.
x

Introducing Sandbox Mode, a safe environment for email testing

Whether you’re new to Postmark and are still exploring or are working on new ways to integrate Postmark with your products, we know that sometimes you just want to try things out.

We’ve heard from many of you that you’d love to see a safe space to test and experiment with Postmark—without the risk of accidentally sending tests to real customers or damaging your sender reputation. Sandbox Mode, our newest addition to Postmark, lets you do just that.

Learn more →

April, 2021

Scheduled database maintenance: Wednesday, April 21st

On Wednesday, April 21st at 10pm Eastern Time we will be doing some scheduled database maintenance. During this time some non-sending API endpoints, as well as the Web UI, will be unavailable intermittently for up to 30 minutes. While non-sending API endpoints are unavailable, mail will be accepted and queued for sending once the maintenance is complete.

Please note that we don’t expect mail to be queued for the full 30 minutes, but you might see some intermittent API failures and web UI unavailability during this time. If you have any questions about this planned maintenance, please let us know. You can also keep an eye on our status page for real-time updates while the maintenance is ongoing.

February, 2021

Reactivate suppressed subscribers

We’ve added the ability to reactivate suppressions made by unsubscribed recipients. This functionality is available in the UI as well as through the Suppressions API

Show details

Did one of your recipients hit the unsubscribe link by accident? You can now reactivate subscribers so that they can receive your emails again.

To reactivate an unsubscribed recipient, head over to the Suppressions tab, find the recipient’s email address, and click the “Reactivate” button to remove the email address from your suppression list.

You can also reactivate subscribers via the API, using the "Delete a Suppression" endpoint. Here’s how.

🚨 With great power comes great responsibility. Honor unsubscribes and only reactivate email addresses when asked to do so, or when mistakes happen.

If someone marked your email as spam, they’ll be suppressed from future email sends as well. We take spam complaints seriously, so you won’t be able to reactivate that recipient on your own. If someone marked your messages as spam but would like to start receiving email again, reach out to our support team. We’re here to help.

Learn more:

Upcoming TLS configuration changes for API users—action may be required

To ensure the continued security of our systems, we wanted to let you know about some upcoming changes to our TLS (Transport Layer Security) configurations for API access. These changes may affect your application’s ability to continue to send mail through Postmark, so please read through this post in detail. These changes do not affect sending via SMTP.

Show details

What’s changing

On April 13, 2021, we are going to (1) disable TLSv1.0 access, (2) disable all RC4 and low-strength ciphers, and (3) add HSTS headers.

Here’s the full timeline of the changes:

  • February 16, 2021 (today): Announcement of the changes, and testing endpoints are made available.
  • February 23, 2021: All Postmark customers are notified about upcoming changes via email and an in-app notification.
  • March 16, 2021: Dedicated email outreach to all accounts that are still connecting to Postmark via TLSv1.0.
  • March 23, 2021 (11 am ET - 12 pm ET): Perform “blackout” test, where we cut over to the new configuration for one hour in production.
  • March 25, 2021: Dedicated email outreach to all accounts that are still connecting to Postmark via TLSv1.0
  • March 30, 2021 (11 am ET - 11 pm ET): Perform another “blackout” test, where we cut over to the new configuration for 12 hours in production.
  • April 13, 2021: Cut over production to new configuration permanently.
  • April 20, 2021: Decommission temporary testing SSL endpoint.

We’ll discuss each change below, as well as your next steps to make sure sending isn’t interrupted.

Disabling TLSv1.0 access

TLSv1.0 has been deprecated, and we are following suit.

Impact: Connections that only support TLSv1.0 would not be able to connect anymore after this change.

Disabling all RC4 and low-strength ciphers

RC4 ciphers are considered weak and they are deprecated as well. Along with this, we are getting rid of any low-strength ciphers that are vulnerable to breaks as well.

Impact: Connections that only support these old/weak ciphers would not be able to connect anymore after this change.

Adding HSTS headers

HSTS (HTTP Strict Transport Security) headers tell web clients to only ever connect to a URL over HTTPS for a period of time (usually 6 months to 1 year). This prevents something called a “downgrade attack”, where users are tricked into visiting a version of a URL that is not secured or validated with TLS.

Impact: We are adding these headers in accordance with industry standards. There is no API connectivity impact.

What you need to do

If you send with Postmark via our API, please make sure that your sending infrastructure is able to deal with these changes prior to the April 13 cutover date.

We’ve set up a temporary endpoint at api-ssl-temp.postmarkapp.com that has these changes already applied. You can use this as an endpoint to test/validate against. Please be aware that there is no expectation of uptime on this endpoint, and that it will be shut down on April 20, 2021 with no further notice. It should only be used for temporary testing of non-production traffic.

If any of your tests with the temporary endpoint fail, updating your OpenSSL library should resolve the issue. If you are having trouble getting your API integration to work with this temporary endpoint, please contact our support team and let us know the exact error message encountered when attempting to connect, and a log of the connection attempt. We may be able to provide specific instructions for using newer TLS configurations.

Additional details related to specific libraries

September, 2020

New IP for webhooks: action may be required

We plan to start posting webhooks from a new IP in a few weeks. If your application restricts access to public IPs, please ensure that the following IP is allowlisted:

  • 3.134.147.250

We intend to start moving webhook traffic to this new IP on October 1, 2020, so please make sure the IP is allowed by any firewall or routing rules you may be using.

July, 2020

Postmark Scheduled Maintenance — July 11, 2020

On Saturday, July 11, 2020, Postmark will be performing necessary database maintenance starting at 10:00 am Eastern Time. We expect the maintenance to last about 2 hours. The affected services will be:

  • All outbound and inbound messages will be queued for approximately 30-40 minutes during the maintenance. During this time no mail will be processed, but we will accept and queue all messages.
  • The web app will be unavailable during the maintenance.

Throughout the maintenance window, we will post updates on our Status page to keep you updated on the progress, including when exactly messages will be queued. Please get in touch if you have any questions or feedback.

P.S. We recently announced that we are adding new public API endpoints. Please make sure these IPs are allowed by any firewall or routing rules you may be using.

June, 2020

Reminder: New public API endpoints — action may be required

We recently announced that to help increase the capacity of our API we plan to add new public endpoints in the coming weeks. If your application restricts access to public IPs, please ensure that the following IPs are whitelisted:

  • 3.137.63.180
  • 18.216.134.80

We originally intended to start moving API traffic to these new IPs in March, but we now plan to start using these IPs in production on June 22nd. Please make sure these IPs are allowed by any firewall or routing rules you may be using.

March, 2020

Auto-incrementing Bounce IDs will exceed 32-bit integers soon - action may be required

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.

New public API endpoints: action may be required

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:

  • 3.137.63.180
  • 18.216.134.80

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.

February, 2020

Upcoming Changes to Bounce Message Retention

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).

Show details

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.

To Summarize:

  • Our retention policy for new bounce events is now set to 45 days. After 45 days, we will purge bounces. This is consistent with our data retention policy for all other types of message data.
  • Starting today, all new bounces will be stored in our system for 45 days, which means it will be fully rolled out in 45 days, on April 1st. Existing bounces will remain available during this transition.
  • For some very specific edge-cases (activating bounces older than 45 days will result in an error) we recommend you use the new Suppressions API for all your email reactivation needs.

As always, if you have any questions or concerns about any of these changes, please let us know.

November, 2019

API update: deprecating /bounces/tags

The /bounces/tags endpoint is used to return all tags from bounced messages as a string array. This endpoint gets extremely low utilization, so we are deprecating it on December 2nd, 2019. We are reaching out to the few customers who use this endpoint directly to help them transition.

If you do have a need to filter bounces by a specific tag, a better approach is to use the /bounces endpoint with filtering, as outlined in our docs here.

If you have any questions about this, please contact our support team.

API update: Modular Webhook management

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.

Show details

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 /server and /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.

For details on how to use the new /webhooks endpoint, head over to our docs. And if you have any questions, please let us know!

October, 2019

Security upgrades to SMTP sending — action may be required

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.

Show details

What’s changing

The following changes will be made to our supported SMTP TLS configuration:

  • Deprecation and removal of TLSv1.0 support. Going forward we will only support connections via TLSv1.1 or higher.
  • Deprecation and removal of several older and less secure cipher suites.
  • Modification of cipher parameters to require larger key sizes.

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:

  • October 29th, 2019 (today): Deprecation announcement, and testing endpoints are made available.
  • January 27, 2020: “Blackout testing”. We will temporarily move SMTP traffic to the updated configuration for a few hours throughout the day so that customers that have not seen this notice are alerted to issues before the final cutover.
  • February 1, 2020: All production traffic will be moved to the updated security configuration.

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.

What you need to do

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:

  • What OS and SMTP client you’re using to connect, as well as any additional information that might be helpful (e.g., what PHP or OpenSSL version you are using).
  • Exact error message encountered when attempting to connect and log of the connection attempt.

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.

September, 2019

We are ending support for the Tags Triggers API on October 14th, 2019

A small number of customers use our Tags Triggers API to track open events on emails sent with specific tags. We’re working on some more powerful features in our other API endpoints, so we are ending support for this feature, and it will be disabled on October 14th, 2019. We ask that customers who currently use this API to track opens based on tags update their applications to instead enable open tracking on a Message Stream level, or for individual messages.

Please let us know if you have any questions about this, or if we can help in any way to make the transition to stream- or message-level tracking.

Additional SMTP Endpoint IPs Added

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:

Show details
  • 3.208.98.158
  • 3.93.205.235
  • 3.95.122.1
  • 13.209.189.43
  • 15.164.159.110
  • 52.208.94.138
  • 52.210.34.36
  • 54.77.222.65

May, 2019

API Bug Fix May 23, 2019

Important changes to the way we handle headers when sending with SMTP

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.

Show details

Historically, when Postmark accepted messages over SMTP, we have constructed the To, Cc, and 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’ To and 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.

February, 2019

Starting March 7th our SMTP outbound servers will only support encrypted connections using TLS

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 smtp.postmarkapp.com.

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: smtp.postmarkapp.com.

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.

July, 2018

Version 2.6.0 of the official PHP library for Postmark

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!

Updates to the Swiftmailer Transport for Postmark

Our Swiftmailer Transport for Postmark has been updated with some minor enhancements, and it also now works with SwiftMailer 6.

Postmark official .net client updated to v3.3.0

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.

Custom metadata for your emails

You can now add custom metadata to your emails, and we'll pass that same data back to your system through our webhooks.

Show details

For more details on how to implement and use this feature, check out the announcement blog post, help documentation as well as our updated developer documentation.

March, 2018

Modular webhooks

You can now add multiple webhook URLs for a server and choose which events you’d like to send to each specified URL.

December, 2016

Webhook for delivery events

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.