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 2 posts from the blog 'Postmark.'
Disclaimer: Reproducing an article here need not necessarily imply agreement or endorsement!
Beginning today, Postmark’s sign up process for new customers will be different. We’ll be manually vetting all new customers to ensure that we continue to provide our customers with the best inbox rates and delivery speeds in the world.
When we started Postmark in 2010, we strongly believed that transactional email was very different from your general email platform. We believed that you need to separate your transactional email from marketing, not only for deliverability, but because the people responsible for it are different in your organization. With transactional email you don’t just look at statistics, you look at logs. Instead of viewing campaigns by the thousands, you troubleshoot delivery problems for an individual user or message. We believed that your application emails are really a piece of your infrastructure, maintained and supported by ops, engineers and product owners, not your marketing team. And we believed that the best delivery will be achieved by pools of shared IPs, where the sender on your left and on your right has high engagement rates and uses good sending practices.
To our great delight, our customers proved us right, and as a result they enjoy the best email delivery in the business. Not only do our emails get to the Inbox, they get there faster than any of the other services out there. This is proven not only in anecdotal stories from folks switching to Postmark, but also with our own internal tooling that tracks delivery across the industry.
And word has been spreading — use Postmark when you care about your emails. Use Postmark for the emails that can’t go missing or come in late. We’re so honored by how many great companies, large and small, have shared in our beliefs and joined us.
This reputation is not easy to uphold, and it is our responsibility to exceed your expectations when it comes to reliability and deliverability of Postmark. As an infrastructure product, you rely on us to be fast and always available. And as an email service provider, we need to make sure that your email neighbors are sending emails of the absolute best quality. ESPs are unique in that they are only as good as the reputation and sending practices of their customers. A single bad actor can take down a good portion of an ESPs reputation, but it takes everyone as a whole to create an exceptional reputation over time. Which brings us to the reasons behind our new sign-up process.
From now on, we’re going to ask new customers a few extra questions. You can test the entire service internally, but we’ll hold off on letting new accounts send a ton of email, while a member of our team manually reviews the account to make sure that we’re all on the same page. We’ll be looking for companies that share the values of our current customers: sending only high-engagement, transactional emails, as a part of the infrastructure of their business. It’ll take us up to 24 hours to review all accounts (a little longer on weekends), but we’ll be completely transparent about it.
This new process will also help us get to know new customers better. We’ll be available by phone or email or chat to help you get set up and make sure your integration is effective. And, if you’re just discovering the value of separating your marketing and your application emails, we’ll be so happy to help you split things out and recommend providers for sending the other stuff.
Existing customers will see no disruption or change in how they use the product. If you’re currently sending with Postmark, we know you value the same things we do. This change will only ensure that we continue to provide the best email infrastructure possible for you.
Postmark is a product by Wildbit, a company that gets to play by its own rules. We’ve always been focused on providing high quality products, even if it meant we would grow slower. We believe it is better to offer an extremely good service for a smaller set of customers than a mediocre product for a large market. If we didn’t, we would have added bulk sending years ago and tripled our revenue. We decided that to really make Postmark exceptional for our customers, we needed to limit the product to customers who take email delivery just as seriously as we do. So we don’t mind growing slower if in return we are able to provide our amazing customers the best possible email infrastructure tool out there. Join us, it’s gonna be a great ride.
We constantly talk about the importance of your transactional emails arriving quickly to your customers. Even a minute late can cause problems or frustration, so we work hard to maintain the best performance possible. Customer facing emails are the obvious messages, but what about the messages that only a select group in your company views? I’m talking about messages that come from your servers such as alerts, cron tasks, error emails, and so on.
What would happen if you didn't get an error email, or your backup script had an error and you didn’t get the email?
This sounds obvious, but emails from your systems and servers are critical. What would happen if you didn't get an error email, or your backup script had an error and you didn’t get the email? The truth is, these emails are easy to neglect. They are only seen when things go wrong and usually only visible to a small group of people. A good example is Gitlab’s recent outage where a single alert for database backups was missed due to a DMARC reject policy, causing disastrous results.
Let’s go through some types of emails and how you can handle them for proper delivery.Application error emails
It’s common in Postmark to see customers tie in error reporting into their email. You already have the Postmark library integrated with your app and it’s easy to push those errors to an email address. For the most part this works, until something breaks. It’s not until you’ve sent 100,000 emails to a single Gmail account that you realize this is incredibly inefficient. Not only will some alerts go off on our side, but Gmail will probably start locking up your mailbox as well. When your app is on fire, this is the last thing you need.
Instead, a better approach is to use one of the purpose built products that handles error reporting. A few products that come to mind are Bugsnag, Honeybadger, Sentry, Raygun, and New Relic. With these products you not only avoid delivery issues and delays, but you get a concise way to parse and combine errors from your app.
It’s not until you’ve sent 100,000 emails to a single Gmail account that you realize this is incredibly inefficient.Servers: Cron, scripts, and user accounts
In most cases your servers will have some tasks or processes running that send emails. This could range from backup scripts, to user accounts, to cron tasks. It’s common for these emails to be sent directly from the localhost. In most cases the localhost mail server has not been configured and lacks the proper infrastructure to get emails to the inbox. Sure, you may receive them, but it’s risky. For example, many EC2 IP addresses are already on black lists, you will lack proper bounce and spam handling, and SPF or DKIM support is usually not considered at all.
Instead, a more effective approach is to relay these through Postmark. This can be done through something like Postfix or Sendmail. By relaying through Postmark you immediately benefit from the same infrastructure that you rely on for your customer facing emails. You will make sure you use proper ‘From’ domains, as well as email authentication.
Ideally, and if possible, the best approach is to use an alternative alerting or check-in system. Services like Pagerduty, OpsGenie, and Dead Man’s Snitch are a great fit. This approach builds on the infrastructure and process they’ve built into their systems to improve your reaction time and ability to get the right person on the task.Using DMARC to identify sources
What if you have an established application and don’t know all the sources where email for your domain originates? As we’ve seen, publishing a DMARC “reject” policy can backfire. On the other hand, DMARC with a “none” (or monitor) policy can go a long way to help you identify email sources. By using a service like our DMARC reporting tool you can slowly identify the servers on your network that are sending emails. In each case you can determine if they are properly authenticated, and if not make sure you relay them through Postmark or hand them off to an external service.Handle system emails with care
Even though system emails may not be high volume, they're absolutely mission critical by every definition of the word. A single missed or undelivered email address can lead to catastrophic failure of key processes that ensure your business runs smoothly and reliably. Make sure you're giving these critical emails the attention they deserve and not relegating them to afterthoughts of implementation.