Latest updates

JS library updates

We released a new major version (4.0.0) of our Node JS library. This version now relies on newer libraries for improved security. With this release, we no longer support Node versions that have reached end of life, so you’ll need to use Node version v14.0.0 or later. If you use older Node versions for which active and security support ended, you will need to use older library versions (3.x.x).

Check out the Postmark JS library and view all the changes we’ve made.

PHP library updates

We have a new engineer on the Postmark team (Welcome Eli! 🙌) and he has given our PHP library some much needed love. You can check out all details in the release notes but in a nutshell:

• We closed out all open issues and worked through most open PRs from the community (thanks for your contributions, friends!)

• We added Postmark’s new Data Removal API to the library.

• We updated the unit test framework.

Check out the Postmark PHP library and view all the changes we’ve made.

If you have any questions or feedback about the changes, we’d love to hear from you.

Previously, if you needed to delete any recipient data from your Postmark account, you would reach out to our support team who would process the data removal on your behalf.

Earlier this summer, our team started working on a solution for data deletion requests via our ”Help a CS friend out” Experimentation week: a new API endpoint that would make this process easier for customers and Postmark's Customer Support team.

Now, with our new Data Removal API you can automate the whole process, erasing recipient data from your Postmark account, and reviewing the status of a Data Removal request.

With this new endpoint, you can:

• Remove blockers in the Data Subject Request (DSR) process

• Remain GDPR and CCPA compliant

• Gain peace of mind for yourself and your clients

Since this endpoint erases data, we have it turned off by default - reach out to us in support and we can enable it for your account. Check out our API documentation to learn more.

More options for putting data removal on auto-pilot

Another option for automating the data removal process (without having to implement a new API) is our Retention Add-On, a handy add-on that lets you control how long Postmark keeps your data.

By default, Postmark stores message content and activity data for 45 days, but with this add-on, you can decrease your data retention and make sure Postmark will purge all customer data after 7 or 28 days. This is a great option for all senders who frequently deal with DSR requests under GDPR.

Timeline

We’ll release the new API infrastructure on November 28th, 2023 but we’ll be running a set of blackout periods before where all traffic is sent over the new Email API infrastructure. Along with greyouts before where some traffic is sent to the new API infrastructure to help surface possible issues. Here’s what to expect:

• Up until November 28th greyouts where a small subset of traffic is sent through the new infrastructure.

• November 15th: First blackout period from 10:00am -12:00pm ET (2 hours)

• November 15th: Second blackout period from 5:00pm - 7:00pm (2 hours)

• November 28th: New API infrastructure is released for Email API.

What’s changing

There are two places where a request made to our Email API could be invalid:

• Content-Type and Accept headers
  If your request headers do not include "Accept: application/json" and "Content-Type: application/json", or these headers are set to different values such as "application/www-x-form-urlencoded", this will result in a 415 error status code.

• JSON request body
  Please make sure your request body is valid JSON and has the correct field types. For example:

  • Array and object fields (such as Headers, Attachments and Metadata) should not be passed as strings. If no value is required, simply leave the field out (or provide an empty array/object.)

  • JSON strings must be wrapped in double quotes. Single quotes are not valid JSON string wrappers and will result in an error

  • Newlines are not valid within JSON, unless they are properly escaped (ie. “\n”). This is particularly relevant for HtmlBody and TextBody fields, which often contains newline characters

  • The above would result in a 422 status code response from our API.

This applies to the following API endpoints:

• https://api.postmarkapp.com/email/
• https://api.postmarkapp.com/email/batch
• https://api.postmarkapp.com/email/withTemplate
• https://api.postmarkapp.com/email/batchwithTemplate

Here are some examples:

Invalid Headers

curl "https://api.postmarkapp.com/email/withTemplate" \
 -X POST \
 -H "Accept: application/json" \
 -H "Content-Type: application/www-x-form-urlencoded" \
 -H "X-Postmark-Server-Token: server token" \

Valid Headers

curl "https://api.postmarkapp.com/email/withTemplate" \
 -X POST \
 -H "Accept: application/json" \
 -H "Content-Type: application/json" \
 -H "X-Postmark-Server-Token: server token" \

Invalid JSON request body

{
…
"Headers":"",
…
}

Valid JSON Request Body

{
…
"Headers": [
 {
 "Name": "CUSTOM-HEADER",
 "Value": "value"
 }
 ],
…
}

Invalid HtmlBody with newlines

{
 "HtmlBody": "<html>
 <body>
 <div>This is not valid</div>
 </body>
 </html>"
}

Valid HtmlBody with newlines

{
 "HtmlBody": "<html>\n<body>\n<div>This is valid</div>\n</body>\n</html>"
}

What you need to do

For messages that are failing with a 415 response code, you’ll want to review the Accept and Content-Type request headers to ensure they match our documented headers for the Email API endpoint. If there is a header that is missing, or is not set to application/json, you’ll need to add or update them accordingly.

If you’re receiving a 422 “Invalid request” response, review our Email API endpoint documentation to ensure you’re passing the correct field types as documented.

If you have any questions or need any help troubleshooting issues, please let us know.

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.

Timeline

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 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!

In the past, when you (or your accountant) wanted to grab a PDF copy of your Postmark invoices for record keeping, you had to log into your Postmark account, navigate to the billing section, and generate a PDF copy. That's clearly not a fun process—especially when you have to repeat this process monthly.

Starting today, you'll no longer have to go through that trouble. Your PDF receipt will be attached to your invoice email, so it will automatically land in your inbox whenever we process a payment.

Pro tip: Did you know you can add billing contacts to your Postmark account? You can specify the additional email address(es) that will receive billing notifications (and those handy PDFs, too)—saving yourself that additional task of forwarding the email to the right folks.

Postmark’s WordPress plugin now supports metadata
After adding tag support a few months ago, our WordPress plugin now also supports adding metadata to messages. It works by adding a filter for ‘postmark_metadata’ that hooks into a function that returns the array of metadata you wish to attach to a message.
Check out the full details on the official plugin page.

Improvements to content personalization in the CX App
Until recently, the Postmark CX App in ActiveCampaign used a different syntax for content personalization than the rest of the AC platform. With this fresh update, contact fields and custom contact fields have been aligned with the rest of the AC platform.
This means you can now add personalization to your ActiveCampaign templates using contact fields, using either the %UPPERCASE% or %camelCase% syntax. All the info is available on this support page.

Postmark’s WordPress Plugin now supports tags

Tags are a handy tool to help you categorize your emails in Postmark — and we now added tag support to Postmark’s WordPress plugin! If you’re using the Postmark plugin to send your WordPress emails, you can now apply tags to your messages using one of the following two options:

• Set an X-PM-Tag message header, i.e. array_push( $headers, ‘X-PM-Tag: PostmarkPluginTest’ ); where you are calling wp_mail().

• Add a filter for ‘postmark_tag’ that hooks into a function that returns the tag you desire.

Please note that using the ‘postmark_tag’ filter will override a tag set via message headers.

A big thank you to our friend DorZuberi for requesting this update and working with Patrick from our Engineering team to get this PR out the door.

Get Postmark’s Wordpress Plugin →

Updates to Postmark’s Java library

We have updated our Postmark Java library to provide better support for the Jakarta community and to fully support newer versions of Java JDK. Igor from our QA team took care of these requests with the latest updates. Postmark’s Java library now provides full support for Java versions 16, 17, 18, and 19.

Check out Postmark’s Java client library →

On Friday, February 17, 2023, Postmark will be performing necessary database maintenance starting at 9:00 pm Eastern Time. We expect the maintenance to last about 2 hours.

Here’s what you can expect during this maintenance window:

• Our non-sending API endpoints and Postmark’s Web UI may be unavailable intermittently for up to 20 minutes.

• While non-sending API endpoints are unavailable, we will be accepting mail via the API and SMTP.

• Your messages might get queued for a short period of time during our maintenance window, and they will get processed as soon as our engineers complete their work. This applies to outbound messages sent via the API and SMTP as well as any inbound messages. We will update you when the queueing starts and ends during the maintenance period.

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.

If you visit status.postmarkapp.com now, you’ll see that the page has a new look. But most importantly, Sorry makes it easier for our team to share incident updates with you fast and reliably. Plus, Sorry gives you plenty of options to customize how you’d like to receive incident notifications from Postmark. In addition to email notifications, you can choose to receive alerts on Slack or Microsoft Teams.

If you had previously subscribed to email alerts for status updates, you don't have to subscribe again on the new page—we moved that email list over to Sorry.

🚨 Important information for users of our Status API and the Postmark Slack App:

As we migrated our status page, we had to temporarily take down our Status API. We’re working on a new API solution and will keep you posted on our progress.

Plus, since the Postmark Slack app is using our Status API, incident updates via Postmark’s Slack app currently don’t work either. If you’d like to continue to receive Postmark status updates via Slack, head over to our new status page and sign up to receive Slack notifications over there.

Where can I find the Time-to-Inbox (TTI) data?

Our TTI stats now have a new home as well. If you're curious how long it takes us to deliver an email to different inbox providers, you can find our stats here: https://tti.postmarkapp.com/

What's changing

Starting on November 30th (10 am EST), we will no longer be supporting HTTP connections to our API. That's three months away, but we want to give any affected customers—yourself included—a good bit of time to prepare for this change.

What you need to do

To avoid any disruptions with your email processing, please update any HTTP connections to our API to the secure version (HTTPS). For most scenarios, this is as simple as finding any place in your application/service where you call an API URL for Postmark starting with HTTP. Like this…

http://api.postmarkapp.com/server

And change it to this:

https://api.postmarkapp.com/server

That's it. However, if you have any further questions or find a configuration where you aren't sure what to change, reach out to our support team and we'll do everything we can to help out and give you any necessary instructions.

The timeline

We want to make this as easy as possible for all customers, so we'll do the following:

• Sept. 1st, 2022 (today): Communicate the plan to make these changes (via email and here, on our updates page)

• Sept 12, 2022: Reminder announcement

• Sept. 21st, 2022: Reminder announcement

• Oct. 4th, 2022: Reminder announcement

• Oct. 13th, 2022: First blackout period. We'll reject access to API endpoints using HTTP for a 60 minute period

• Oct. 27th, 2022: Second blackout period (8 hour period from 11 am to 7 pm EDT)

• Nov. 16th, 2022: Third and final blackout period (1:00 pm EST Nov. 16th to 12:59 pm EST Nov. 17th)

• Nov. 28th, 2022: Final reminder announcement

• Nov. 30, 2022: Final cutover date (10 am EST)

We understand these kinds of changes can be inconvenient, but it's a step that benefits everyone. And we appreciate your cooperation on this—thanks so much!

What does this mean for me as a Postmark customer?

We know you might have some questions. Like…

• Will Postmark’s pricing change? (No.)

• Will Postmark continue to be available as a standalone product or will you integrate into ActiveCampaign? (Yes and yes.)

• Will Postmark stay yellow? (Oh yes!)

We’re answering these questions and more in our public and ever-evolving FAQ. Do you have a question we didn’t cover? Let us know and we’ll get it added (and give you an answer, obviously.)

Read the FAQ

Two-factor authentication (also lovingly referred to as 2FA) is a simple and highly effective way of improving the security of your Postmark account. Once enabled, Postmark will require a password and a second form of authentication—either via SMS or app authentication—during the login process.

This additional layer of security protects your account from unauthorized access. Should your password ever get compromised or stolen, you can still rest assured that only you can access your Postmark account.

Postmark has supported 2FA for years, but now we’re making it easier for account owners to ensure that everyone on the team is putting this safeguard in place.

New: Enforce account-wide two-factor authentication

If you’re an account owner or admin, you now have the option to require everyone on your team to set up two-factor authentication. Here’s how it works:

Navigate to the Account overview page in your Postmark account. You’ll find the option to enable account-wide 2FA on the top of that page:

Once enabled, all users on your Postmark account who haven’t set up 2FA will receive an email with instructions on how to get set up—and they will no longer be able to log into Postmark until that’s done.

Good to know:

• You can only enable account-wide two-factor authentication if you’ve set up 2FA for yourself first. Here’s how you do that.
  

• We don’t require a phone number for 2FA. Some services only support 2FA via SMS, but we think you shouldn’t be forced to share your phone number if you don’t want to. So at Postmark, you can verify your identity via SMS or an authenticator app of your choice. We support Google Authenticator, Authy, and 1Password.

Especially Postmark customers who’re sending on behalf of others will find this helpful. Let’s look at an example:

Sweeet is a (totally fictional) platform that helps bakeries handle pre-orders and promote special offers via newsletters, and they’re using Postmark to send all those emails. When a new bakery, let’s call them Donut Heaven, signs up, they’ll need to confirm that Sweeet can send newsletters using Donut Heaven’s domain. That confirmation email is sent via Postmark—and that’s been causing some confusion in the past. Donut Heaven signed up with Sweeet, so why are they getting an email from Postmark? We get it. It really is a bit confusing.

To provide additional context and to make the Sender Signature confirmation process smoother for you and your customers, we now let you add a personal note to the confirmation email.

If you’re creating a new Sender Signature via the Postmark UI, you’ll see a new text field to add your personal note:

If you’re creating new Sender Signatures via the API, you can use the new "ConfirmationPersonalNote" field to add your personal message.

We hope this will make it easier for those of you who use Postmark to empower your customers to send email.

Let us know what you think! And as always, please reach out if you have any questions.

Learn more:

• Check out the Sender Signature API
• Read our best practices for using Postmark to send on behalf of others

We do not use Java or Log4j in our products, including Postmark. We did, however, identify an internal system that was vulnerable. A component of our logging system uses Log4j to ingest logs and transfer them to a searchable database that is used internally by our staff. We immediately shut down this system and rebuilt it with a version of Log4j that is not vulnerable.

This logging system does not have access to customer credentials (including passwords and payment information), API keys, or templates, although some log messages do include headers from emails sent by Postmark. That said, we conducted a deep review of the affected system over the past few days and there is no evidence that suggests unauthorized access of any kind.

We will continue to remain vigilant and investigate this incident further, and will update this post if we find any additional information or evidence of unauthorized access. If you have any questions, please reach out at any time. We’re here to help.

When sending mail with Postmark via SMTP, there used to be only one option for you to specify a Message Stream: You’d authenticate with a Server Token and specify the Message Stream you’d like to use with the `X-PM-Message-Stream` header (that’s the Message Stream header). If you have the ability to set custom headers, this works great. But we’ve heard from some of you that your SMTP clients don’t let you set custom headers, making it impossible to define a Message Stream for sending. That’s not cool, so we set out on a mission to fix that!

Say hello to our brand new Message Stream SMTP Tokens! 🎉

In-app guidance to help you navigate Servers and Message Streams

What’s a Message Stream? Why are there different ones? And what in the world is a Postmark Server? Great questions, friends! Those should not stay unanswered. That’s why we’ve added a bunch of contextual help throughout the Server and Message Streams pages in the Postmark app to help you get started on the right track.

Is this message a broadcast or a transactional email? We help you decide

We know that the lines between transactional and bulk email aren’t always very clear, so we’ve created this handy quiz that helps you decide whether your email is a better fit for our broadcast or transactional streams. If you pick the right one, we can guarantee the best deliverability for all types of emails.

Just answer a few simple questions about the message you’re planning to send and we’ll tell you what stream is the best fit for your email.

Take the quiz →

Creating sender signatures by default

Before you can send emails with Postmark, you’ll need to verify your FROM address. We learned that most Postmark customers use the email address they signed up with to send their first email, so we’re now automatically setting up the sender signature for that email address. If you’re new to Postmark, that’s one less manual step between you and your first email. ✉️ 🚀

Design updates

If you’ve been with Postmark for a while you might notice that some areas of Postmark look a little different. We made a handful of design changes to improve contrast and legibility throughout the app.

As always, if you have any feedback, please let us know. We'd love to hear from you.

What’s changing

There are two places where an attachment could be invalid:

• content-type will need to be a valid MIME type (for example application/pdf or image/png).
• content-id will need to contain only ASCII characters, no spaces or non-ASCII characters are allowed. This follows RFC2392.

In the majority of cases the invalid data stems from using the filename as the content-type and/or content-id. Instead, the correct MIME type should be specified in the ContentType field, and an appropriate unique ContentID should be generated for each attachment, For example:

Invalid

{
 "Name": "readme (1).txt",
 "Content": "dGVzdCBjb250ZW50",
 "ContentType": "readme (1).txt",
 "ContentID": "readme (1).txt"
}

Valid

{
 "Name": "readme(1).txt",
 "Content": "dGVzdCBjb250ZW50",
 "ContentType": "text/plain",
 "ContentID": "c7d-2q41-zfw"
}

What you need to do

For messages you send with attachments, you can check the “Raw Source” of the message in Postmark to make sure you have your attachment formatted in a valid way. If you have access to review the logging for how you’re sending messages to Postmark for your server, you can also review how the attachment is formatted there. A vast majority of senders will find their attachments are valid, and no action will be needed.

We’re contacting senders who we’ve detected who have sent a high volume of messages that will be affected by this change.

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

At Postmark your data is secure and redundant, but keeping your account information secure is a team effort! Setting up 2FA is one of the most important things you can do to protect your account from unauthorized access—and to keep your data secure.

How can I set up 2FA?

Set up 2FA by logging into your Postmark account, select your name in the top right, and then choose “Profile” to access your user settings. You can turn on two-factor authentication in the “Security” section on that page.

Select your preferred authentication method. You can choose between SMS or app authentication. Postmark supports Google Authenticator, Authy, and 1Password.

Nobody likes being locked out of their account, so we also made it mandatory to download your backup codes when setting up 2FA. They are your key to get back into your account should you ever change your phone number or lose access to your device.

Learn more about setting up 2FA →

Can I see if other users have 2FA enabled?

As the account owner, you can! Head over to the Users section in your account and you’ll see who has enabled 2FA (and who might need a friendly reminder to get it set up).

I previously used SMS authentication. How can I switch to another authentication method?

That’s easy! Head to the 2FA settings in your account and turn off 2FA. Then, just start the setup process again. You’ll no longer be required to use SMS to enable 2FA.

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:

• An address has been marked as inactive. How can I reactivate it?

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

• Postmark.js library
• Postmark gem
• Postmark .Net Library
• Wordpress plugin
• Postmark PHP library
• Postmark Rails gem

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.

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!

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.

• 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

• You can now push templates and layouts up to Postmark using the postmark-cli tool
• MailMason’s layouts are now compatible with Postmark layouts
• General codebase improvements to build structure and package upgrades

• 3 generic layout options to help you get up and running
• Each template now uses Nunito Sans as the main typeface. Fallback fonts for older versions of Outlook have also been considered.
• Dark mode support in all layouts. Works with email clients that support the prefers-color-scheme:dark media query.

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.

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.

Repeat config option

To continuously check an email address, add the repeat option to the config object. repeat accepts any number above 5000 milliseconds. We recommend using it sparingly for workflows crucial to email such as account activation or password reset pages.

window.Rebound.check(config)

This method accepts the standard config object as the first argument. This is ideal for letting your customers know about delivery issues based on an action they took in your app. Take a look at our CodePen example and learn how to check an email address when a form is submitted using Javascript.

Check out Rebound’s API docs for more details.

Here's a brief overview of all the bug fixes and small changes we completed in April and May of this year:

• We now enforce Do Not Track headers! See our announcement post.
• If you follow a deep link to a part of our UI (for example, in an email you receive), you will now be taken directly to that URL once you've logged in, instead of the Servers page.
• When you send an email to a distribution list, and one of the recipients in that list results in a hard bounce, we will no longer deactivate the whole distribution list. Instead, we now mark this is a soft bounce so that you can investigate which email bounced, without the entire list being affected.
• We added "Processed" as an alias for "Sent" in the Messages API, to match our recent UI changes.
• Our login, password recovery, and 2-factor authentication pages are now mobile-friendly.
• We improved some button labels in the UI to make initial setup clearer.
• Other bug fixes:
  • If your address is inactive and you try to trigger a password rest, nothing happened and no error was shown to you. We now show an appropriate error message.
  • We fixed an incorrect error message that was shown if you didn't specify a template model when sending email.
  • In some cases the plain text preview of your emails ran off the page on the Message Details page in the Postmark UI.
  • Our pricing calculator broke when commas were used as thousands separators.
  • We fixed an issue where Webhook URLs sometimes failed validation tests when they weren't supposed to.
  • The password strength indicator on our sign-up page wasn't working.