Blogroll: Postmark

I read blogs, as well as write one. The 'blogroll' on this site reproduces some posts from some of the people I enjoy reading. There are currently 8 posts from the blog 'Postmark.'

Disclaimer: Reproducing an article here need not necessarily imply agreement or endorsement!

Subscribe to Postmark feed
Updated: 1 hour 17 min ago

Customer interview: Meet JP Boily, founder of Metrics Watch

Thu, 05/10/2017 - 16:17

We’re excited to introduce you to JP Boily, the founder of Metrics Watch. They deliver email reports and alerts for Google Analytics, AdWords, and Facebook Ads.

Can you tell us a little bit about your experience and the work you do?

Hey folks, I'm JP, founder of Metrics Watch. We do white-label email reports for agencies (Google Analytics, Adwords & Facebook Ads) and we also do real-time alerts for Google Analytics.

We also help businesses with Google Analytics audits, implementation, and training.

Before founding Metrics Watch, I was a full-time software engineer doing most Ruby on Rails development for startups and agencies. I still take some Rails work from time to time.

How are you using Postmark today?

We're using Postmark to send all our password reset emails and similar stuff, as well as sending our reports and alerts to our customers. It's so good to have emails being sent super fast without any delays! Especially for our alerts! :)

What made you decide to deliver Metrics Watch's critical email with Postmark?

Your focus on transactional email and speed. That's the number one reason I left my old provider. I can't afford to send real-time alerts and have them delayed for hours. That happened way too often on my previous provider.

Postmark is simple, and it just works. You focus on transactional email speed and delivery, and I focus on my business.

If you could add one feature to Postmark, what would it be?

One thing maybe. Alerts when Metrics Watch gets more than X% of bounces during a period I can set. I know I can do it with webhooks, but I would love something built-in.

I'll explain the use case briefly: Metrics Watch has two products, reports and alerts. The reports, while important, are not THAT critical for most people. Alerts, on the other hand, those are very critical and need to be sent rapidly. I need to know ASAP if there are bounces on certain accounts.

For example, Greyhound uses Metrics Watch, and they rely on it to tell them if their online presence breaks in any way. They need to know ASAP, or they could lose quite a bit of money. If there are bounces on the Greyhound domain, it's important for me to know.

As I said, I assume it's not a typical use case...but that would be my #1 feature request.

If you could give fellow developers one piece of advice about how to implement and manage their transactional email, what would it be?

I'm a big fan of automated testing, so I would say get the important parts of all your emails, and email flows unit tested. You don't want to break or remove by accident some core pieces of your emails, like a link to your billing page in a failed payment email, for example.

Also, keep things simple. Make email short and to the point.

Finally, monitor your bounces. Make sure not too many email bounces, figure out why they do and fix it.

Want to tell us about your Postmark experience, get some free swag, and get featured in our Newsletter and our blog? Of course you do! Just fill out this form.

Categories: Technology

Separate your promotional and transactional email sending

Thu, 28/09/2017 - 05:00
Illustration of two mailboxes with "promo mail" written on one and "welcome mail" written on the other.

You've probably been told to keep your transactional emails separate from your bulk emails, but what does that mean and why should you listen to this advice?

Transactional emails are emails that your customer triggers—a welcome email after a customer signs up, an alert email a customer has set up in your app, an invoice email and a comment notification all qualify as transactional email. There are others as well, the exact nature of transactional email you send will vary according to the type of app you run. 

A promotional email is an email that is sent to more than one person that contains the exact same content and is not triggered by an event. A promotional email would be anything a customer did not specifically trigger, for example a weekly newsletter, a marketing email or an announcement about your site's recent updates. Currently, Postmark does not send bulk emails like these.

To understand why Postmark doesn't send promotional emails, let's go back to that advice you may have heard—why keep these two types of email separate? In a nutshell: keeping your important transactional emails—the ones your customers are expecting—separate makes them much more likely to land in the customer's inbox.

The reputation of the IP address, domain and email address all play a role in getting your email into your customer's inbox rather than their spam folder, or, in the case of Google, one of the inbox sub-categories like "Promotional". Email providers know that customers want and expect transactional emails, but it's not always easy for them to tell what's transactional and what's better classified as promotional. 

Using separate domains or emails addresses for each kind of mail makes it much more likely that your important transactional email will to get to your customers.

Shared IP addresses that only send transactional emails like Postmark’s will always have a better reputation than shared IP addresses that also send promotional email.

If you use the same servers and email address to send both bulk and transactional email filtering systems like Gmail's may classify it all as bulk email. That's why Gmail officially suggests that "if you send both promotional mail and transactional mail relating to your organization, we recommend separating mail by purpose as much as possible." This helps Gmail tell the difference between the two, and it ensures the best possible reputation for your transactional email. Given the staggering number of Gmail users out there, adhering to this advice makes good business sense. 

Since lost or even delayed transactional emails will result in support requests, like the familiar, "I tried to reset my password, but I never receive the email response", and more work for your organization. Then there's the potential lost customer trust. Searching through your spam folder for a legitimate email is never fun. Don't send your customers into their spam folders when there's an easy way to avoid it -- keep them separated.

So how to do you separate your mail? And what does “separate” mean? It means making sure your bulk emails comes from one source and your transactional from another, separating IP addresses, domains and possibly email addresses as well. These days reputation is increasingly shifting to domains because IPs are increasingly disposable. It’s much easier for spammers to cycle through new IP addresses than it is to cycle through domains. It also means that with more of your reputation tied to your domain, you can take it with you if you need to change providers.

For example you might send your bulk email from and your transactional email from You could even use entirely different domains, for instance, and Or you might be able to get by with just using for bulk and However, given Gmail’s recommendation to use separate domains and IP addresses, simply using different email addresses should be a last resort.

For us this isn't just a theory. Postmark sees the best inbox rates and delivery times in the industry because we only send transactional emails. That means our IPs have great reputations that are bogged down by shared IP addresses that are being used to send promotional email and transactional email for a variety of providers. We police them much more strictly than the other providers who are a bit more lax about it since they send bulk mail as well. Shared IP addresses that only send transactional emails like Postmark’s will always have a better reputation than shared IP addresses that also send promotional email.

With most providers, they’ll simply recommend customers purchase dedicated IPs when customers run into delivery issues on shared IPs. We know all this because a significant number of our customers are “refugees” from the other providers. They ran into delivery problems sending both bulk and transactional from a single source and came to us to make sure their transactional emails get where they need to be -- in their customer's inbox. You don’t have to use completely separate providers, but no matter what you do, just make sure that you send your transactional and promotional emails from different domains and IP addresses.

Categories: Technology

Better QA through automated user experience monitoring

Wed, 27/09/2017 - 15:24

As web applications have become more complex over the years, having good tools for monitoring has become mandatory. Tools like New Relic, Pingdom, or Nagios are necessary for all companies that are serious about their web app’s health and performance. The need for web app health monitoring has become especially evident with the release and wide adoption of tools like StatsD.

Back then, Etsy, the creators of StatsD, introduced an interesting approach to monitoring apps by suggesting to teams to measure everything. They measured network, machines, and application performance. Of these three categories, application performance has been the hardest to measure.

I agree completely with their approach, and the way we monitor Postmark is similar. To achieve that, we have various monitoring tools set up by our development team, systems team, and quality assurance team. You might be wondering why QA is involved in setting up monitoring—let me explain.

Monitoring tools and development/systems teams

We have many tools for monitoring our web app setup by the development and systems teams. We have New Relic, Pingdom, Nagios and some other tools setup and tied to Postmark. They measure network speed, cpu/hard drive/memory health, API endpoint speeds, app services and more. These tools are not ideal, though, as they have both good and bad sides.

The good: These tools provide specific details to help developers isolate where the issue could be.

All of these apps do a great job letting our developer/systems team know about any bottlenecks that need to be fixed. They provide details where to look on servers, parts of code, on which hard drive and so on.

The bad: Sometimes these tools don’t provide high level details that customers and the team needs.

Tools setup by our developers and systems team are great for providing back-end information, but most of the time they are not great for providing the type of information that’s useful to customers. Most of the time, these tools are very specific. This is where we see what Etsy was referring to with regards to monitoring the application being the most challenging.

What do you tell a customer if CPU usage is high on one server, or if emails are slow to arrive to the inbox, if open tracking status updates are slow, or if the activity page is working? This is where tools managed by our QA team come into play.

Monitoring tools and quality assurance teams

In order to solve the application monitoring problem, we introduced one more level of monitoring: monitoring the app by automated tests written by testers. These aren’t purely functional tests. These are automated and recurring tests to monitor things which are essential to customers, they monitor the end user’s experience.

For example, we’ve built tools to monitor how long it takes email to reach the inbox, how long it takes for a real activity page to load, how long it takes for an email to appear in the activity page, and how long it takes for the status of an open email to be reachable by API or visible in the activity page.

The good: These tools provides quantitative measures of the experience for users.

Monitoring the automated tests gives us insight into the performance pains customers could see while using the web application or API.

The bad: Sometimes these tools don’t provide details that are useful for developers.

These automated tests can discover that some part of the app is slow (time to inbox, open tracking, etc) and alert the team. However it’s often too high level information for developers to pinpoint the issue. The alerts raise an alarm, but they can’t solve the problem. They just let us know that we need to investigate the issue.

Monitoring tools across teams

As you can see, monitoring tools for developers and testers complement each other. They work together to provide context and feedback for both developers and customers. We collect information from both sides and analyze it so we have a complete picture that's usable by the whole team.

An illustration showing how app services checks, network tests, and machine tests fall under our developer monitoring tools while UI tests, scripts, and API tests fall under our tester monitoring tools. Our holistic solution to systems-level monitoring and user-experience level monitoring helps us react quickly to even the smallest degradation in performance—usually before customers even know anything was wrong. How do we do monitoring with automated tests

The actual monitoring with automated tests is simple.  We connect all of our automated tests to Librato, an application for storing and reporting on simple statistics.

A screenshot of a line graph from Librato. Monitoring bounce processing speeds in Librato

Here is a simplified code example of one of our automated tests for monitoring capabilities. To make the example more readable, a couple of different test types were combined in a single test scenario. 

This example test monitors the time it takes for an email to arrive in an inbox as well as the time it takes to search for that same email within the Postmark activity feed. Time is measured in seconds. We need to be confident that the email arrives in the inbox quickly, but we also need to be confident that the email’s status is quickly and accurately reflected in the activity feed as well.

require 'spec_helper_selenium' describe 'Activity Page' do include_context 'email handling' include_context 'email content handling' include_context 'email content building' # configuration data which will be used in the test let(:username) { 'username' } let(:password) { 'password' } let(:api_token) { 'api token' } let(:host) { '' } # simple test scenario, which involves: # sending an email # checking email arrival to inbox # testing activity it 'send email' do email = build_email send_email(email, host, api_token) receiver = check_email(email) # once email arrived to inbox, time needed for email to arrive to inbox is sent to # our statistics server LibratoMetrics.api.gauge('', # visit the web application, using selenium page objects visit_page(Login).sign_in(username, password) on_page(Servers).click_on_server('selenium') on_page(ServerPage::Statistics).click_on_activity on_page(ServerPage::Activity).click_on_outbound on_page ServerPage::ActivityPage::Outbound do |page| # after reaching outbound activity page, measure time from starting # to search up to search result appearing in activity LibratoMetrics.api.gauge_interval('postmark.activity.time_to_appear_sent') { page.search_field = email.subject page.click_search expect(page.wait_for_email_to_be_sent(email.subject)).to be true } end end end

The challenging part of monitoring with these kinds of tests is coverage and run frequency. Having enough automated tests written to cover all of the vital areas for the product monitoring can be an endless process, and running them frequently enough can be resource intensive, especially as the number of tests grows. Finding the right balance of these tests is tricky.

For Postmark, we have written over 1500 automated tests over the years which we run daily. We have plenty of test scenarios for Postmark we can monitor. In order to run automated tests frequently we setup our own test machines and we run our tests with Jenkins. To be able to monitor UI, running the tests frequently is essential. So you either need to be prepared to invest in test machines and their maintenance or use a service like

A screenshot of module statuses in Jenkins. A small fraction of Jenkins jobs which represent isolated test groups we run daily. Each group can be executed separately or as a part of the full testing suite. Any degradation in performance would make some of these test jobs fail. How monitoring affects our day-to-day work

Monitoring app health is a crucial part of our everyday work. Knowing there are tools that are regularly monitoring every aspect of Postmark, help us sleep better at night. This also means we experience fewer surprises and have more time to focus on our regular work.

Whether there’s a high CPU usage problem, bounce service isn't working, emails aren't arriving on time, or the activity page is slow, we'll know about it. In any scenario, we’re alerted quickly so we can address problems and provide the best possible service. 

Adding monitoring from the QA side helped us to push the boundaries of monitoring further. It allowed us to get an even better perspective on what can go wrong and how to react to problems more quickly. Our goal is always to be proactive and solve problems before they are even visible. For us, there is no going back, monitoring from both development and QA side is clearly the way to go.

Every app presents a different set of challenges though. They’re like living organisms that have vastly different needs. This approach works well for us. We would love to know what you think and how you solve the monitoring challenge on your side.

Categories: Technology

Feature announcement: New Activity feed

Wed, 20/09/2017 - 16:15

If there’s one thing we know from talking to our customers it’s this: the Activity page in the Postmark app is probably the most important part of the UI for most of you. It’s kind of a weird page too. It’s a page you don’t really need... until you do, and then you really need it. Here are some of the things we know you use the Activity page for:

  • Track down emails when your customers say they can’t find it.
  • Troubleshoot when you notice some weird things going on like lots of bounces or spam complaints.
  • Checking that everything is going fine when a large batch of emails goes out. 

You use it for a very specific purpose each time, and then you leave and go about your business, forgetting about it until the next time. That is how we like it, of course. We don’t want to be an app you think about all the time. We just want to make it easy for you to run your app and not worry about emails.

From our customer feedback and research we also know that the activity page wasn’t perfect. The layout was somewhat cluttered, which impeded data clarity and comprehension. The ability to filter on specific events, emails, and recipients was fairly limited. In short, we realized that the focus of this page should be on clarity and the speed of finding the information you’re looking for. The Activity page has to be easy to understand and act on, and it needs to be possible to find the events you're looking for extremely quickly.

Here's what it looked like until today:

Old activity The old Activity page

So we set about redesigning this page with those goals in mind. Along the way we did usability testing on prototypes to make sure we provide you with the best possible experience. And today we’re excited to unveil the new Activity page to you.

Here are some of the highlights.

Increased information density and clarity

The new Postmark activity feed Brand new Activity page

The Activity page is like a news feed for your email. It shows every event that happens to your messages, but the way it was laid out before made it difficult to scan and get a good sense of what was going on. With the new Activity page we improved that in several ways:

  • We moved to a table layout with each associated message event on the left to make it easy to scan the page and spot any issues or errors.
  • We added a new “Delivered” event to so that you don’t have to go into an individual message page to see when a message was delivered. This was one of the confusing aspects of the previous Activity page, where many of you expected that “Sent” meant “Delivered”.
  • Speaking of “Sent”… we also changed the labeling of the “Sent” status to “Processed”, since that fits in more accurately with the other status labels as an indication of where each email is in the process of getting to your recipients’ inboxes.
  • We added a bunch of information-rich tool tips on hover states so that, in many cases, you don’t have to click through to the detailed message page any more to get the information you need.
Improved filtering experience

Since the main thing you want to do on this page is find a specific email (or group of emails), we made several improvements to search and filtering:

New filters in Postmark
  • We consolidated the filters into a single interface to make it easier to mix, match and combine.
  • You can now combine multiple filters together, for example to see all emails that had either a Hard Bounce or an ISP Block.
  • In the main text box we added a much-requested feature, which is to filter by specific sender email addresses.
Export to CSV 

We heard from many of you that you’d like to be able to export the results of a particular search to CSV directly from the UI, so we now allow you to do that up to a maximum of 500 records. If you’d like to export more than 500 records you can use the Messages API

We started this project with the goal of making it easier and faster for you find the emails you’re looking for. Our initial feedback on the prototypes were positive, and we’re really excited to hear what you think of the new page now that it’s live. Please let us know at if you have any feedback. Or if you’d like to have a face to face chat with me about it, feel free to set up some time here.

Categories: Technology

What is ARC, or Authenticated Received Chain?

Mon, 11/09/2017 - 21:08

Internally, and through our support channels, the term ARC, or Authenticated Received Chain, has been coming up more recently. While this new standard is not something you need to implement, I’d like to describe what it is, and what it means to you as a sender. 

What is ARC?

ARC, or Authenticated Received Chain, is a standard created in 2016 to help improve how DKIM and SPF results are passed from one mail server to the next during forwarding. When messages are passed to intermediaries like mailing lists or email account forwarding, DKIM and SPF can break. ARC aims to fix this. The arc-spec site sums it up well:

When an email sender or Internet domain owner uses email authentication to make it easier to detect fraudsters sending messages that impersonate their domain, some services like mailing lists or account forwarding may cause legitimate messages to not pass those mechanisms, and such messages might not be delivered. These services may be referred to as intermediaries because they receive a message, potentially make some changes to it, and then send it on to one or more other destinations. This kind of email traffic may be referred to as an indirect mailflow. ARC preserves email authentication results across subsequent intermediaries (“hops”) that may modify the message, and thus would cause email authentication measures to fail to verify when that message reaches its final destination. But if an ARC chain were present and validated, a receiver who would otherwise discard the messages might choose to evaluate the ARC results and make an exception, allowing legitimate messages from these indirect mailflows to be delivered.

Let’s look at this using an example message sent from Postmark to Gmail. You have a custom Return-Path setup along with DKIM, and you have a DMARC policy in DNS (If you don’t, go take care of that!). Any emails sent from Postmark will be authenticated and “fully aligned” when they land at ISPs like Gmail or Outlook. Here is a an example of what the headers might look like for this message:

Authentication-Results:; dkim=pass header.b=SaTOwM7u; dkim=pass header.s=pm header.b=uUBEpN9j; spf=pass ( domain of designates as permitted sender)

Now, let’s assume that your customer automatically forwards their emails to a Yahoo account. When it lands on Yahoo’s servers, this message will now fail DMARC SPF alignment because the Return-Path headers have changed. In addition, it is likely DKIM will fail as well since the message content has changed. This happens because the new sender is Gmail, not Postmark, who you verified as an approved sender in SPF.

How does ARC help?

If you use our DMARC tool, you probably already know that forwarding causes a lot of DMARC failures. We get quite a bit of support and confusion around forwarding for this reason. 

With ARC, the authentication results are now passed down on each hop between mail servers. For instance, when it lands on Gmail, they insert an Authentication-Results header that defines the results of SPF and DKIM. This header is then used when the message is forwarded on to the next mail server, who can use this information to validate the authentication results.

ARC-Authentication-Results: i=1;; dkim=pass header.b=SaTOwM7u; dkim=pass header.s=pm header.b=uUBEpN9j; spf=pass ( domain of designates as permitted sender); dmarc=pass (p=NONE sp=NONE dis=NONE)

The header above looks exactly like the Authentication-Results header, except it has “ARC-” in front of it. Let’s assume this message was then forward to Yahoo. Gmail will pass along this ARC-Authentication-Results header to Yahoo, who can then use this information to assume the message is safe. When the message lands on Yahoo’s servers, it includes these headers:

ARC-Authentication-Results: i=1;; dkim=pass header.b=SaTOwM7u; dkim=pass header.s=pm header.b=uUBEpN9j; spf=pass ( domain of designates as permitted sender); dmarc=pass (p=NONE sp=NONE dis=NONE)

What you can see is Yahoo trusted the results that Gmail provided, and therefore used the previous Auth Results for DKIM, SPF, and DMARC results below.

Authentication-Results:; dkim=pass header.b=SaTOwM7u; dkim=pass header.s=pm header.b=uUBEpN9j; spf=pass ( domain of designates as permitted sender); dmarc=pass (p=NONE sp=NONE dis=NONE)

Since ARC was used, forwarding has not impacted the results of DKIM or SPF. If you used a reject policy for DMARC, this would now pass. 

In addition to the ARC-Authentication-Results headers, you might also discover two new headers: ARC-Seal and ARC-Message-Signature. They look something like this:

ARC-Seal: i=1; a=rsa-sha256; t=1504715872; cv=none;; s=arc-20160816; b=Nz9pPmKDifg+wmSdwCnUjXvG9jG9WFoF6fghYY1QdGolnG/TZoGeuJHkzDl8KQyVtt xsTqAtv0sJQcqtGONMLw6K/lPRurwu2PTZLRnPafig2TOAXI+0/qFic8pmRnPrWP+0r4 N838/B8VMHu1S8Q+2twlVux74yPUwLvjjm9bP5fdKoek0n9yc5Eqr03OPYKxp7g6mgrQ 0dC5MMklg0nuorbN9dqa34NHtCORGqOGhHdEhbYSQ7UBrljWB2p3E3RZCOXLt6pdEDcu jMMc4G2FLySqP5WjG2Ru4OiST6buvygpGOVFJusIEOr+al0Iv610kx10pxUimQrZtSRL 8HPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arc-20160816; h=content-transfer-encoding:subject:date:to:from:mime-version :feedback-id:message-id:dkim-signature:dkim-signature :arc-authentication-results; bh=F3xWEof0wbMYYQQTcMCgWyziErnPAP8h+MmTpoMWTmw=; b=drx3lVSLNBLsydWX+t91fFq4LLi7Vf17nU8uxQT0h5P1hbruNRGp+GPTUClVG77wL2 aShoNrhMV/wDCZEDu6YUN9EC23WAfOfQk6ltZQ0UiUb47tgxAJNrDf+0PR7FWcveZt6X CJNqAnOMd8y2asOg/ljIdhjG8TGZt5egORiRE1Nad3JKgXrNiBy3Oi/Epe8GKhQTMulw cnS4pp381LHCccsBAJOxVjqIs7D+3EeNTYp4myl5DC8A8kEN3z/gS9S0PpVV0Pyr0s9n klXHbKc+hGDjiFXyYIgmqz7GlSfY0sOwQ2xP3b3PkMtIUuWcqBPHjuLK/u51qDIr/2Kf pOKA==

During each hop, there is a bit of trust (or assumed trust) that providers must have in the ARC results that are passed along. These two headers allow the ARC chain to be validated as it is passed along.

What can you do about it?

For you, our customer, there is not much you can do. ARC is implemented by email receivers and ISPs. In most cases providers like Gmail, AOL, etc will implement ARC over time. 

Once enough ISPs support ARC your DMARC reports will start to look much better, with less failures resulting from forwarding. At the moment, both AOL and Gmail support ARC, and we are expecting many more to follow. If you manage an email server, have a look at the ARC Resources page for implementation.

Categories: Technology

Ideas to improve bounce handling so lost messages don’t cost you revenue

Wed, 06/09/2017 - 15:34

We’ve talked recently about how bounces can make a difference in deliverability for your domain, and briefly mentioned a few ways you could help your customers with some proactive interface decisions. Bounce handling has been around for a long time and it basically means “there was a problem delivering your message.” Applications can improve bounce handling by taking this idea a step further to “if an email bounces, don’t just ignore it, here's something to do about it!” 

In the early days of email the only choice was to offload monitoring to senders. For applications, this could leave customers with a dilemma when a message bounced. They had to decide if a message is just being slow or will never be delivered. As email use grew Email Service Providers started building rules for how to handle bounces on their system. For example, Postmark will stop sending email to addresses with a hard bounce unless you specifically reactivate it. Today ESPs have tools to make it simpler for applications to build in more advanced bounce handling, and it’s worth exploring some real world examples of how this can work.

To find examples of in-app bounce handling I added a typo to my email address to see how apps I use every day would handle this error. A simple typo or aggressive policy on the receiving mail server can bounce and create unanswered questions for your customers. After a bounce they could be left waiting for an email that will never show up, but it doesn’t have to be that way. Here are examples to show how some apps use handle bounces to help their customers.

Bounce notifications from Inbox by Google

If you’ve used email you’ve seen bounced messages return to your inbox. Your email server will generate a message to try and explain why they weren’t able to deliver your message. Most people who send email would wonder exactly what a message like `550: 5.1.1 unknown or illegal alias:` means.

Google has done some great work to help Gmail users cut through email jargon and understand what happened to their messages. This starts with their SMTP responses as they reply with specifics and a link to a help article.

Sorry, we were unable to deliver your message to the following address. `` ``<>: ``550: 5.1.1 The email account that you tried to reach does not exist. Please try ``5.1.1 double-checking the recipient's email address for typos or ``5.1.1 unnecessary spaces. Learn more at ``5.1.1 k123si3698974itk.63 - gsmtp

This SMTP response is really helpful for folks who bounce a message to a Gmail address. Google builds on this friendly bounce reply and improves it when you’re using Inbox by Google. A clear bounce explanation is front and center and is followed by plain language similar to the raw bounce response.

Inbox by Google friendly bounce message Inbox by Google bounce notification

This message makes it crystal clear why a message wasn’t delivered and gives the user tips on how to correct the error, along with a link to a help article for more information.

Lesson for your app: Try to make smart assumptions about what might have caused a bounce and share that with your customers. Even if your audience is technically sophisticated, they might not want to parse a SMTP error code and response.


Email addresses are a common user ID and it can be a big problem if your customers sign up with an email address where you can’t reach them. It’s a great idea to verify email addresses with a validation workflow, but that doesn’t solve the problem when someone signs up with an invalid email address.

Netflix shows their customers when their email bounces right away in their app. In researching this post, I changed my email address to one with a typo. As soon as I refreshed the page this message popped up across the top of the window:

Netflix invalid email address notification Netflix shows you when an email bounces right away

I love this immediate check. Going back to the email validation workflows, if I mistype my email address I have to switch to my inbox to wait for a message that won’t arrive. Then I have to go back to the app to see if I can request another email, and I might or might not notice my typo. Telling people their updated email address bounced right away saves you and them time.

Lesson for your app: Look for bounces as people are logged in to your app. There’s no reason to send them to their inbox looking for an email that won’t arrive. It’s still a good idea to keep your email validation workflow to make sure your customers are making any changes to their email address on file.


In December we released updated permissions for Postmark accounts. It lets our customers add users with different levels of access and relies on email to take care of the sign up process. This is what the user area looks like for your active accounts.

Postmark user dashboard Postmark's user dashboard makes it simple to visually check user permissions.

Bounces don’t just show up as pending invitations here. When an email bounces you can see that at a glance on this page.

Bounce notice in the Postmark permission dashboard You'll see bounced invites on the Postmark user dashboard

If you click through on an account with a bounced message you’ll get more detailed information about what happened with the invitation email. You can resend the invite here too.

Detailed bounce message from a user's bounced invitation When you click through you'll find the SMTP response for the bounced message

Lesson for your app: In addition to noting pending invitations, keep your customers updated on the status of invitations that have bounced. Providing this info at the account level, along with notifications for individual accounts, will make sure your customers are able to get up and running with out account-related hassles.

Churn Buster

When you send email on behalf of your customers you have to be aware of bounces. If you’re sending email from your own domain and enough of it bounces, your domain’s reputation could take a hit and delivery for all of your customers could suffer. Keeping an eye on bounces can help you identify customers who might not be a fit, or potentially abusing your application.

In the case of Churn Buster, bounces tell you when their customers are in danger of losing revenue. Churn Buster show their customers message stats on their dashboard so they can identify customers with bounced messages and create workflows to keep them from churning.

Image of Churn Buster's email dashboard Email delivery data from Churn Buster's email dashboard.

This gives their customers a way to quickly glance and keep track how their email is performing overall through Churn Buster, and how many bounces they’ve generated in particular.

Lesson for your app: If you send email on behalf of your customers, give them a way to keep track their bounces. The best way to surface this info will vary depending on your use case, but focusing on getting bounce info to your customers is a great way to improve their experience.

Put bounce data to work in your app

Bounces will happen when you send email. Using your ESPs bounce data to your advantage can help your customers and improve their experience with your app. Here’s an example of the data you can get from Postmark bounce webhook. 

{ "ID": 42, "Type": "HardBounce", "TypeCode": 1, "Name": "Hard bounce", "Tag": "Test", "MessageID": "883953f4-6105-42a2-a16a-77a8eac79483", "ServerId": 23, "Description": "The server was unable to deliver your message (ex: unknown user, mailbox not found).", "Details": "Test bounce details", "Email": "", "From": "", "BouncedAt": "2014-08-01T13:28:10.2735393-04:00", "DumpAvailable": true, "Inactive": true, "CanActivate": true, "Subject": "Test subject", "Content": "<Full dump of bounce>", }

You can find more details in the documentation for our bounce webhook and API endpoint for bounces. Hopefully, these examples have spurred a thought or two for how you can improve bounce handling for your application. Hit us up on Twitter to share your favorite advanced bounce handling examples.

Categories: Technology

Don't send unsubscribe confirmation emails

Mon, 28/08/2017 - 14:12

Following best practices when it comes to email can be tricky sometimes. There are a lot of rules to follow. Do this, don’t do that, but you should always do this for sure! There are also a lot of differences between sending transactional emails and sending newsletters for marketing.

Without going into all the details on the CAN-SPAM ACT, there is one golden rule you should always follow. When a user opts out or unsubscribes from your emails, you should never follow up with a confirmation email letting them know you will not email them again. It just doesn’t make sense. Remember email is about two way communication and when one side says stop, you stop. What ultimately happens is the user will be completely turned off and mark your “Unsubscribe Confirmation Email” as spam.

We see it happen all the time when customers use Postmark to send these unsubscribe confirmations, and over time it will affect your reputation and deliverability.

When it comes to Postmark we take a different approach. Once a user clicks the Unsubscribe button we take them to a nice friendly page bidding them farewell. Of course we are sorry to see them go but we would never abuse their trust by sending them one more (unnecessary) email. 

Be sure to always part ways with your subscribers on a high note. Sometimes less is really more.

A screenshot of the Postmark unsubscribe confirmation page with options to follow on social media instead. Give people a simple unsubscribe confirmation page and let that be the end of it.
Categories: Technology

Get answers faster and easier than ever

Tue, 22/08/2017 - 18:36

Over the last couple of years, we’ve really expanded our documentation. More guides, help docs, blog posts, open source projects, and developer docs. Unfortunately, that proliferation led to fragmentation. So we set aside time to unify all of our documentation into a single home. Now you can browse topics specific to your needs, search across all of our documentation, and even get in touch with a human easier than ever. Welcome to our new support center.

A screenshot of the new help center home page organized by topic and offering search and multiple contact methods. We've organized our most popular topics and resources for easy browsing from a central place so you don't have to check multiple sources to find the most relevant information.

Now, every word of every help doc, labs project, API doc, blog post, guide, and every other page on the Postmark site is available under a single search. You provide the topic, and we’ll give you organized and weighted results. You can even filter if you know you're looking for a specific type of resource.

A screenshot of search results for 'dmarc' showing our guide, blog posts, and relevant help docs. Search across all of our documentation and filter for select resources all from one place.

Of course, no matter how much documentation we provide or how extensive the search functionality is, sometimes, nothing beats talking to a real human. Whether that’s via email, live chat, or even on the phone, we’ve worked to make it easier than ever to reach out and ask. We’ve even worked to make it a little more clear about how quickly to expect a response as well as introducing you to the folks that you’ll hear from.

A screenshot of introductions to Dana, Marek, and Patrick from our customer success team. We're big fans of personal service, so we want you to be able to put a face (and a voice) with the names.

Whether email, Twitter, live chat, or even the phone, we want to help. We don't want you to jump through hoops to be able to talk to us. If you want to skip all of that, there’s no need to login or do a search first. You don't even have to be a paying customer. Just get in touch when and how you want to. We’re here for you. 

A screenshot of our slightly updated contact form. With Postmark, you're not firing off an email into a vacuum. We're here to help, and we do our best to be completely transparent about our response times.

We really hope these updates make developer easier and get you up and running as quickly as possible. If you have any questions or feedback, you know where to reach us.

Categories: Technology
Additional Terms