You can now erase recipient data from your Postmark account with the help of our new Data Removal endpoint.
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.
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.
We're making some improvements to our API infrastructure and as a result, we're changing how we handle the validation of your API requests.
In the past, Postmark's email API has been pretty forgiving to requests that are passed incorrectly. In some cases, we've accepted invalid request headers and incorrectly passed JSON body key/value pairs—even if they didn't match our API documentation. Going forward, we'll start to reject invalid requests and return an error message instead.
So if you see Postmark return error messages to API requests that were previously accepted without issues, please double-check if your request is actually valid. We recommend using a tool such as JSONLint to check your request payloads for any obvious validation errors, and if that shows no issues then refer to our API documentation pages and make sure your request matches the schema(s) we are expecting.
Here are some common reasons why your request might be invalid.
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.
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.
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/batchhttps://api.postmarkapp.com/email/withTemplatehttps://api.postmarkapp.com/email/batchwithTemplateHere 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>"
}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.
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!
Postmark stores message content and activity data for 45 days by default. But what if 45 days is too short? Or too long? With our new Retention Add-on you can adjust retention from 7-365 days.
We're so excited to share that you now have full control over how long you'd like to keep message content and activity data in your Postmark account. With our Retention Add-on you can:
Increase your data retention to up to a year. Maybe you're delivering digital goods via email and need to keep proof that you actually sent those emails. Or your support team would love deeper visibility into past email activity. Whatever your use case, setting longer retention time will help with troubleshooting, record-keeping, and compliance.
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.
Curious to learn more? Read all about this update on the Postmark blog →
Our friends at Sorry™ (that’s the service we use to run Postmark’s status page) introduced a new API that makes it easy to build Postmark’s status information into your workflow. Here’s how you can put it to work.
As a Postmark customer, you deserve to feel that your emails are in good hands, with a service and team you can count on—including when things don’t go as planned. That’s why we’ve teamed up with the good folks at Sorry™ to bring you a status page that helps you stay on top of any incidents or planned maintenance. Until now, our Status page was already giving you the option to receive status notifications via email, Slack, or Microsoft teams — and with this newest addition, the Postmark Status API, it’s even easier to stay on top of Postmark’s current status.
With the new Status API, you can integrate Postmark’s status directly into your processes and workflows, without having to go and manually check our status page (or your emails) for updates. Whether you’re looking to get a quick overview of our overall system status, build your own notification system, or get details of an incident so you can add them to your own status page or internal tools, with the new Status API, you can do all of that.
Check out the API documentation →
The Postmark team (and our friends over at Sorry App) would love to hear what you think about the new API. So if you have any thoughts or feedback, please let us know.
_____________________________
Our old Status API has been unavailable since we migrated our status page to Sorry, and we’re excited that we can now offer this functionality to you again. But please note that the API endpoint URLs as well as the JSON responses for Sorry’s new API are different from the one we used to provide, so you’ll have to make some changes to your existing integrations to get them up and running again.
Here are a few things you should know:
The main API endpoint URLs have changed from https://status.postmarkapp.com/api/1.0/… (OLD) to https://status.postmarkapp.com/api/v1/… (NEW)
Sorry App uses a different nomenclature to describe the elements of our status page. For example, what we used to call ‘incidents’ in our old API are ‘notices’ in Sorry. If you’d like to get a list of all incidents, things have changed from
GET https://status.postmarkapp.com/api/1.0/incidents (OLD) to
GET https://status.postmarkapp.com/api/v1/notices (NEW)
Please be aware that the keys and values in the JSON responses follow different formats than what you’ve seen in Postmark’s old status API.
Check out Sorry’s API docs for a detailed overview of all available endpoints and JSON responses.
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.
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.
For many years, we’ve worked with our own, home-built status page to keep customers posted about any incidents. We learned the hard way that this solution wasn't as reliable as we needed it to be (ouch!) so we decided to quickly move to a new provider (it’s our friends at Sorry) to handle our status page going forward.
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.
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.
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/
To ensure the continued security of our systems, we wanted to let you know about an upcoming change to our API access. In short, we want to ensure Postmark—and your account—is as secure as possible, and we've found that there is a small portion of our traffic that is using HTTP rather than HTTPS.
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!
When you’re setting up a new Sender Signature—that’s the email address we’ll use as the FROM email when sending your messages—the owner of that email address has to confirm that Postmark is allowed to send email using their address. You can now add a personal note to that confirmation email to provide additional context.
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.
With our new stream-specific SMTP Tokens, you can specify what Message Stream you’d like to use to send email—without having to add custom headers.
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!
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.
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.
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
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:
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.
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:
We’ll discuss each change below, as well as your next steps to make sure sending isn’t interrupted.
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.
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.
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.
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.
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:
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.
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:
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.
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:
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.
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.
To Summarize:
As always, if you have any questions or concerns about any of these changes, please let us know.
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.
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 /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!
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.
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.
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 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.
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.
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.
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.
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.