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 5 posts from the blog 'Postmark.'

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

Subscribe to Postmark feed
Updated: 2 hours 23 min ago

A/B testing email service providers

Tue, 05/12/2017 - 16:18

Can changing your email service provider improve open and click rates? If you've ever spent any time in the dashboard of your email service provider (ESP), you've probably focused on the open or click rate of you email. Why aren't people opening your email? It's tempting to immediately start re-writing your emails, using stronger headlines perhaps, or maybe toning down your copy to sound less aggressive. 

While those certainly may be problems, there is often a much simpler answer. A lot of issues with low open/click rates are really just delivery issues.  Your customers can’t open/click on an email they never receive. If you’re seeing unusually low open/click rates for your industry, it’s very possible that it’s caused by delivery issues.

Instead of spending time and resources A/B testing subject lines or revamping the design of your CTA buttons, you might be better off making sure your emails are actually being received. One customer,, which helps connects parents and childcare providers and tutors, recently migrated from Amazon SES to Postmark. When they switched from Amazon SES to Postmark, they saw their open rates go up 11 percent without changing anything else about their emails. That's a huge win, but it's one you can only make if you're monitoring where your mail ends up. Inbox providers are increasingly leaning on domain reputation for filtering, but IP addresses still matter. If your ESP isn’t closely policing their IP reputations, you could end up sending from an IP whose reputation has been tainted by other senders.

In our last post about Monitoring email delivery, we covered some ways to monitor common issues that might stop your email from being delivered. And here, by delivered we really mean accepted by your customer's mail server (or ISP). That's half the battle. Once it's on your customer's server though there's quite a few ways to monitor how that server delivers that email to the customer. That is, monitoring the so-called last mile—does it get delivered to the inbox, sent to spam or hung up by some filter the customer never gets to see.

Unfortunately, deliverability is hard to measure directly because you can’t login to everyone’s mailbox to see if an email was delivered. Your ESP doesn't know either. When it says an email was "delivered" it only means that the mail server reported back that it accepted the email. It could well mean that it was delivered to the spam folder, or in the case of Gmail, the promotions folder. There are however, some services that can help you get a better idea of where your email is going.

The two big services in this space are 250ok and ReturnPath. Using these services can give you data about your delivery rate to a large list of ISP “seed accounts”. When you send to these seed accounts from your ESP, the services will track if the message went to the inbox, spam folder, or if it was missing entirely. Alternatively, you could use our MailHandler gem to setup your own custom monitoring.

Once you've got a mailbox delivery monitoring system set up, you can start looking at the data. The big question will likely be how much of your email is ending up in the spam folder and why. With seed accounts and services like 250ok, you want to view the data as a trend instead of an absolute delivery rate. In some cases factors like content and broken seed accounts can skew the results, so use it as a starting point in monitoring inbox placement instead of a definitive measure of your success or failure.

Now you know how much is ending up in spam folders—the industry standard is somewhere around 20 percent, depending on who you ask, though we think you should aim for much lower than that—the question becomes, how do you fix it?

Before you start hiring copy writers and running textual analysis on your keywords, consider that it might be something much lower level, like the quality of your ESP. Now that you have the tools to monitor delivery it's well worth your time to start comparing services. Just like you'd A/B test headlines, it's worth the time and effort to A/B test ESPs. We've even put together a thorough guide for things to consider when evaluating transactional email service providers

All delivery and IP address reputations are not created equal. While upgrading to a more expensive dedicated IP address can sometimes help fix problems, unless you’re sending significant volumes of email, you may not be able to keep the IP address “warm,” and more of your emails may end up in spam. Moreover, dedicated IPs can be recycled after a customer leaves a service, and even with a dedicated IP, it's possible that you may suffer from reputation issues as a result of the previous IP address owner's indiscretions. In any case, never assume that great delivery is a given, even with dedicated IP addresses.

Categories: Technology

Monitoring your email delivery and reputation

Wed, 29/11/2017 - 14:00

Most folks take email delivery for granted. You hit send and assume the recipient will get it. That's usually a good assumption for personal email, but when you move beyond single emails, delivery gets decidedly less certain. Things like IP reputation, domain reputation, or simple configuration mistakes can completely derail your delivery.

Fortunately you don't have to sit around just wondering whether your business' emails are being delivered. The internet is awash in helpful tools and techniques for monitoring email delivery. One of the keys though is to move beyond depending on your email service provider (ESP). ESPs can monitor delivery to a degree and, in many cases, even tell you what, if anything, is going wrong. However ESPs can't monitor everything about your system and may not always be able to diagnose your delivery problems.

To help you start looking here are a few services you can use to track and measure delivery rates and diagnose potential problems.

The first thing to keep in mind with email problems is Occam's razor -- your delivery problems often have a very simple cause and solution. It often won't be what many people assume, that the largely inscrutable spam filtering processes of ISPs or Google is out to get them. The problem is often much simpler than that. Even if it is an ISP out to get you, make sure you've eliminated the other possibilities first. Always start with the simple.

Regularly Review & Monitor DNS records

DNS records? Yes, DNS. It's so simple and so obvious we often forget how important it is. When you’re working at a company using several services, possibly several dozen domains, redirects and other possibly complicated configurations, it’s possible, even likely that the correct DNS configuration can get screwed up when someone makes an update. If you're not monitoring the SPF, DKIM, and DMARC configuration in your DNS for your delivery system you can end up with emails failing to be delivered. It's a simple problem with a simple fix, but one you won't know about if you aren't actively looking.

If you’re using Postmark, we’ll automatically monitor your DNS on a regular basis to ensure everything is configured. If we notice any issues, we’ll let you know. In addition to the built-in monitoring, here are some other tools for monitoring your DNS records for email configuration issues:

Monitor IP address blacklists and IP/domain reputation

Starting with the very simple, make sure that your domains and IPs (or your ESP's IPs) haven't ended up on a spam blacklist. If you’re using a service that has you on shared IPs, your delivery can be blacklisted simply because one of your neighbors on the IP address sent spam. 

You’ll also want to keep an eye on your IP and domain reputation which is an increasingly important signal to ISPs. IPs are easy to change, but if your domain gets a bad reputation, that’s going to be an uphill climb.

There are dozens of services out there that can perform some combination of checking and monitoring this for you. With hundreds of blacklists out there to keep track of you'll probably want to pay for a decent service that regular scans all public lists for any mention of your IPs and domains. 

Some great tools for monitoring IP address blacklists as well as keeping an eye on your domain reputation:

Track Real Delivery Times with MailHandler

Once you know your DNS is set up correctly and that you're not on any blacklists the next place to look is delivery speed. How long does it take from the time you hit send to the time that email ends up in your customer's mailbox? You're probably familiar with this problem from the other side -- nothing is more frustrating than that password reset form that claims it just emailed you but you know there's nothing in your inbox. That's a problem with delivery speed.

To help you track and monitor delivery speed, we built MailHandler, a tool you can use to send and retrieve emails and at the same time get details on how long these operations took. MailHandler is available as a Ruby gem and can send email through the Postmark API or by standard SMTP protocol. More importantly it also allows checking email delivery by IMAP protocol.

To get the most out of MailHandler, you’ll want to set up several accounts with the key services you want to monitor delivery for. In most cases, that’s likely to be Gmail, Yahoo, Hotmail/Outlook, AOL, and Apple. After you set up these accounts, you can then set up a cron job to use MailHandler to regularly send emails to these accounts and then login to see how long it takes the email to reach the inbox. This may sound like overkill, but it’s a key strategy for getting a good estimate of the real time that it takes for an email to be delivered. 

Then you can either save snapshots of the times to a database for charting and monitoring. And you can set up alerts to notify you if delivery takes more longer than a pre-specified threshold.

Success! Delivered. Or Not.

Once you've got a good system set up for monitoring your sending system and you know your emails are being sent in a timely manner it's time to move on to the last mile so to speak -- the customer's inbox. When we say an email is "delivered" what we really mean is that was accepted by your customer's mail server (or service). Whether or not it was then placed in your customer's inbox is an entirely different problem that we'll tackle in the next installment.

Categories: Technology

Why we no longer ask for SPF records

Tue, 14/11/2017 - 15:34

Last month we released a big update to the email authentication workflow for domains. The main goal of the update was to encourage more people to set up email authentication (like custom Return-Paths and DKIM) by making the process easier. Overall it was a huge success (more on that in another post). 

As part of this update, we made a change that, while not obvious, contradicts a pattern for most ESPs: We removed the requirement to add an SPF record for your domain. 

Wait, what? Is SPF dead? It’s not. SPF is alive and well and an important part of email delivery. However, the way ESPs ask you to implement SPF is not technically correct. 

To explain this, we need to look at some email headers first. When you send an email, there are two types of From addresses. Laura Atkins explains this well, but I will briefly summarize it:

  • Mail From” Address: The address used for bounces or delivery reports, displayed as Return-Path in the headers.
  • Display From” Address: The address that you usually see in the email client, and the email address of the user in most cases.

If you use a mailbox provider like Gmail, Outlook, or Fastmail for your personal email these two headers will usually look the same and any bounces will return directly to your address. However, if you use an ESP, the Mail From will be an address at the ESP so they can collect bounces. For instance, here is what the relevant headers look like for a general email account:

Return-Path: <> From: User Name <>

And here is what those same headers look like by default for emails coming from Postmark:

Return-Path: <> From: User Name <>

The domain is what we use to collect bounces. And this is where the confusion starts. Inbox providers check SPF against the Return-Path address, not the From address. Back in the day when SPF came out, Microsoft decided to come out with their own standard called SenderID. The difference was that SenderID was based on the “From” address, where SPF was based on the “Return-Path” address.

In other words, SPF looks up the DNS record (and approved IPs) at the Return-Path domain (the ESP’s domain) whereas SenderID looks up the DNS record of the From domain (customer’s domain). 

So when it came to ESPs like Postmark recommending DNS entries, we naturally told everyone to add an SPF record to their own domain, and we made sure we had one on our Return-Path domain. This happily covered both cases. And we just kept doing that - for many years.

The trouble is that SenderID is a dead standard now. SPF is still alive, so the DNS record lookup only happens on the Return-Path domain. So the question is: 

Why are we all asking our customers to support an obsolete standard?

When it came to revisiting our Email Authentication process, and how we could make it easier, we asked ourselves this question. The result was to get rid of the SPF DNS requirement for customer domains, making it one less DNS record you have to insert into your DNS.

Instead, we place much more emphasis on DMARC by asking customers to add a custom Return-Path using your own domain. Since the purpose of DMARC is to align DKIM and SPF to your brand’s domain, both of these help support the effort toward domain reputation. With a custom Return-Path, you can set your own domain in place of ours using a CNAME, providing full SPF support at the Return-Path domain.

Return-Path: <> From: User Name <>

By using a CNAME, the domain will point to our domain, inheriting both the SPF record and MX records to handle SPF and bounces at the same time. The end result is one less DNS record to insert and removing an obsolete practice. 

Email is hard. As a service provider we put a ton of effort into finding a balance between removing confusion and educating our customers. By making this small change we simplified the set up process and removed an obsolete practice. And hopefully this makes the process of authenticating your email make that much more sense. 

Oh, btw, what about SPF at my own domain for G Suite, Fastmail, Outlook, etc?

I want to clarify one important aspect. For your main mailbox provider, and any provider who uses your domain for the Return-Path, you still very much need an SPF record. A good example is G Suite email. Since the Return-Path and From addresses are the same (your domain) you should still keep Google’s SPF include in there. Here is an example:

"v=spf1 a mx ~all”
Categories: Technology

Syntax highlighting code samples in HTML emails

Tue, 07/11/2017 - 16:32

Many modern web apps require the end user to install some bit of code. Even small snippets of code are much easier to read and understand when they're properly syntax-highlighted. Most existing libraries for syntax highlighting are huge combinations of CSS and JavaScript and don't work at all in most mail clients. Or, the tools are manual and require copying and pasting into a web page to get highlighting. 

If your application needs dynamically generated code samples with syntax highlighting, things become more difficult. That's why we created MailBrush. MailBrush lets you add syntax highlighting to code snippets so they can be used in your email templates. And since it's a node.js package, you can automate any email workflow and reduce the manual overhead. 

Then, instead of plain snippets in your email templates that look like this:

A screenshot of a JSON code sample without syntax highlighting. For maximum compatibility, most code samples in email look pretty plain and don't include syntax highlighting.

Your snippets will now look like this:

A screenshot of a JSON code sample with syntax highlighting. With MailBrush, it's easy to generate a snippet of code with Syntax highlighting.

MailBrush has syntax highlighting support for HTML, CSS and JavaScript snippets, as well as JSON, PHP, HTTP and Bash. It allows for full customization of highlighting colors and styles so you can customize your highlighting to fit with the rest of your mail templates. Once you run MailBrush on your code the resulting HTML snippet will work in all major email clients:

  • Desktop
    • Apple Mail 8, 9, 10
    • Outlook 2003, 2007, 2010, 2011, 2013, 2016
    • Windows 10 Mail
  • Mobile
    • Gmail App (Android)
    • iPhones
    • iPads
  • Web
    • AOL
    • Gmail
    • Yahoo

Convinced? Okay, let's set up MailBrush and start generating some HTML. The first step is to install Node.js. The easiest way to get Node is to grab the installer from the Node.js site. That will work for both OS X and Windows. If you're on Linux you can also install via the Node download page, though you may be better off using your distro's package repository to install Node.

Once you've got Node installed, installing MailBrush is simple. Just open up your terminal application and enter this command:

npm install mailbrush --save

That's it, you've got MailBrush installed. Now let's run it on some code.  There's some basic Node boilerplate code we need to write to make everything work, so here's a snippet you can use to get started:

const mailbrush = require('mailbrush'); // Specify options const options = { language: 'json', cssOptions: { backgroundColor: 'pink' } }; // The code snippet you want to beautify const snippet = `{ "key": "value", "key2": "value 2" }` mailbrush.convert(snippet, options, (html) => { // Returns HTML with inlined CSS for email client compatibility console.log(html); });

Save that snippet in a file named app.js (or whatever you'd like to call it) and then you can run it with this command:

node app.js

In this case that would output this code:

<table cellpadding="0" cellspacing="0" style="background: pink;"><tr><td style="background: pink; color: #000; font-family: Consolas, Monaco, 'Andale Mono', 'Ubuntu Mono', monospace; font-size: 13px; padding: 10px 15px;"><pre style="-moz-tab-size: 2; -ms-hyphens: none; -o-tab-size: 2; -webkit-hyphens: none; color: #000; font-family: Consolas, Monaco, 'Andale Mono', 'Ubuntu Mono', monospace; font-size: 13px; hyphens: none; line-height: 1.5; overflow: auto; tab-size: 2; text-align: left; white-space: pre; word-break: break-all; word-spacing: normal; word-wrap: normal;"><span style="color: #999; font-family: Consolas, Monaco, 'Andale Mono', 'Ubuntu Mono', monospace; font-size: 13px;">{</span> <span style="color: #905; font-family: Consolas, Monaco, 'Andale Mono', 'Ubuntu Mono', monospace; font-size: 13px;">"key"</span><span style="color: #a67f59; font-family: Consolas, Monaco, 'Andale Mono', 'Ubuntu Mono', monospace; font-size: 13px;">:</span> <span style="color: #690; font-family: Consolas, Monaco, 'Andale Mono', 'Ubuntu Mono', monospace; font-size: 13px;">"value"</span><span style="color: #999; font-family: Consolas, Monaco, 'Andale Mono', 'Ubuntu Mono', monospace; font-size: 13px;">,</span> <span style="color: #905; font-family: Consolas, Monaco, 'Andale Mono', 'Ubuntu Mono', monospace; font-size: 13px;">"key2"</span><span style="color: #a67f59; font-family: Consolas, Monaco, 'Andale Mono', 'Ubuntu Mono', monospace; font-size: 13px;">:</span> <span style="color: #690; font-family: Consolas, Monaco, 'Andale Mono', 'Ubuntu Mono', monospace; font-size: 13px;">"value 2"</span> <span style="color: #999; font-family: Consolas, Monaco, 'Andale Mono', 'Ubuntu Mono', monospace; font-size: 13px;">}</span></pre></td></tr></table>

That's all the HTML (and inline CSS) you need to put that snippet into your mail template. This code will be highlighted and will look good in all the supported mail clients listed above. 

Now, to actually generate markup for your code you can change the script above. The options constant is where you can change colors, fonts and highlighting. See the MailBrush Github page for a full list of options. 

The other two things you'll want to change is the language variable, which can be markup, php, javascript, css, http, or bash. Finally you'll want to change the snippet constant to the actual code you want highlighted.

And that's all there is to it. Happy highlighting!

Categories: Technology

Feature announcement: A better DNS Settings page

Wed, 18/10/2017 - 17:16

Our DNS Settings page is, in many ways, at the core of what we do at Postmark. When you authenticate your domain with us it allows you to send from any email address on that domain, and it also ensure great delivery rates. It’s also a page that you’re likely to use only once, and then never again. So it’s important for it to be simple and easy to understand. The previous version of this page needed some improvement. It had a lot of text, and not enough assistance if something goes wrong. Here’s what it used to look like:

Today we’re excited to release a simplified DNS Settings page to make it easier to ensure great delivery for your email. But we didn’t stop there — we also made some backend changes to streamline how we authenticate domains for email sending. Let’s go through some of those changes.

Simplified DNS Settings

The first thing you’ll see is that we now have a much cleaner and easier-to-understand layout for the records you need to add to DNS to authenticate your domains for sending.

The email nerds among you will immediately notice that something is missing… “Where did SPF go?” you ask. The TL;DR version is that it’s not required to set up an SPF record on your domain for good delivery through Postmark. We take care of that on our side. Here’s a slightly longer explanation…

Years ago when email standards were being formed, email providers used the SPF records of the From/Sender address domain to check for alignment. This meant that it was necessary for Postmark users to add a custom SPF record to their DNS in order to pass SPF alignment. This has since changed, and email providers no longer check the From field’s domain when evaluating SPF and determining the results. 

The Return-Path domain is now used by receiving email domains to check for SPF alignment. This means your emails sent through Postmark will always pass SPF by default, without any action on your end, since the Return-Path of all emails sent through Postmark already includes our outbound sending IPs and SPF record. 

Better error handling

Working with DNS records is never simple. One of the things we wanted to do with this release is help users fix common issues when they set up their records. Instead of showing inscrutable error codes, we now show actionable recommendations on how to fix problems, whenever possible.

Recommendations for authentication and monitoring

At the bottom of the page you’ll now see some additional options and recommendations to make sure you’re getting the most out of authentication and monitoring through Postmark. We're also making it more seamless to sign up for our free DMARC reports.

Send instructions to a teammate

We know that in many cases, the person who sets up an app’s Postmark account is not the person who has access to DNS Settings. So with this release we’re also making it easy to send detailed instructions to a teammate about the records that need to be added.

I know I say this every time, but I really mean it: we want to hear what you think of the new page now that it’s live. We’re always listening and making improvements based on your comments. 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
Additional Terms