Recent Posts

Things you need to read

The email solicitation that made me vow to never work with this company again. When sending unsolicited email, you never know how the recipient is going to respond. Writing a public blog post calling you out can happen.
The 2016 Sparkies. Sparkpost is looking for nominations for their email marketing awards. Win a trip to Insight 2016!
5 CAN SPAM myths. Send Grid’s General Counsel speaks about CAN SPAM myths. Personally, asking for an email to unsubscribe is annoying. I never know if the unsubscribe request worked or not. Give me a link any day.
The most misunderstood statistic in email marketing. A good discussion of why raw complaint rates isn’t the metric the ISPs use, and how it can mislead folks about their email program.
Office 365 is expanding it’s DKIM signing. Terry Zink discusses the upcoming changes to how Office365 handles DKIM signatures. This is exactly the kind of changes I was talking about in my 2016 predictions post – background changes that are going to affect how we authenticate email. He even specifically calls out whether or not a particular signature is DMARC aligned or not.

This message has no content.

This is what my mail client tells me about the latest mail Twitter sent me:
Inbox__110995_messages__27_unread_
Criticism of Twitter’s copywriters?
Not exactly, no. Mail.app is looking for some textual content near the top of the mail to display to me as preview text. It can’t find any in this mail, so it’s telling me the message has no content.
Looking at the mail it’s a standard multipart mime message, with a text/plain part and a text/html part.
The text/plain part is entirely empty. Nothing in there at all.
Don’t do that. If you really can’t come up with a plain text version of your message just send simple text/html mail. (And think about why you’re employing talented copywriters if you’re not making good use of the copy they write).
With some messages the text/html part is also empty of text, containing nothing but images. That’s not the case here, though – the message is mostly text, and renders just fine without loading remote images (there are remotely hosted images, but loading them just enhances the message, they’re not essential).
But … there are nearly three hundred lines of HTML before we get to the first text. The mail client probably just gave up looking for content before it got there.
If you’re the sort of perfectionist who’ll A/B test subject lines to see which ones are most likely to get a recipient to open the message you should be paying just as much attention to the other content that is shown in the inbox – the friendly from and the message preview.
In an ideal world your message would have the most important text at the top, and mailbox previews would work perfectly. If your messages are slathered in so much CSS that the actual content is hidden, or if you rely on images for the headline, or if you put “View this email in web browser” at the top of all your messages then you’re likely not showing the content you’d like to recipients.
Try and craft your mails so the most important information is shown as text, and near the top of the mail. If you can’t do that, consider using explicit mailbox preview content. Litmus explain how to do that, and list the mail clients that support it in their article.

What to expect in 2016

I don’t always do predictions posts, even though they’re popular. Most years I skip them because I don’t see major changes in the email space. And, I’m not the type to just write a prediction post just to post a prediction.
This year, though, I do see changes for everyone in the email space. Most of them center on finally having to deal with the technical debt that’s been accumulating over the past few years. I see ISPs and ESPs spending a lot of development effort to cope with the ongoing evolution authentication requirements.
When people started seriously looking at how to authenticate email, the first goal was getting organizations to implement the protocols. This was a practical concession; in order for a new protocol to be used it needs to be widely implemented. Phase one of authenticating email was simply about publishing protocols and getting organizations to use them.
During phase one, the organization that authenticated a mail hasn’t been important. In fact, the SPF spec almost guarantees that the ESP domain is the authenticated domain. In DKIM, the spec says any domain could sign as long as they could publish a public key in that domain’s domainkeys record.
ESPs took full advantage of this and lowered their own development overhead by taking most of the authentication responsibility on themselves. Their domains were in the 5321.from and they published the SPF records. Domains they control were in the d= and they generated and published the DKIM keys. Mail was authenticated without ESP customers having to do much.
We’ve hit the end of phase one. Most of the major players in the email space are authenticating outbound email. Many of the major players are checking authentication on the inbound. Phase one was a success.
We’re now entering phase two, and that changes thing. In phase two, SPF and DKIM are used as the foundation for user visible authentication. Neither SPF nor DKIM were designed to be user visible protocols. To understand what they’re authenticating you have to understand SMTP and email. Even now there are days when I begin talking about one of them and have to take a step back and think hard about what is being authenticated. And I use these things every day!
DMARC is the first of these end user visible protocols built on SPF and DKIM. It uses the established and widespread authentication to validate the user visible from address. This authentication requires that the d= value or the 5321.from address belong belong to the same domain in the visible from address. While you can pick whether the alignment between the visible from and the authentication is “strict” or “relaxed” you have no choice about the alignment.
Prior to DMARC no one really paid much attention to the domain doing the authentication. Authentication was a yes or a no question. If the answer was yes, then receivers could use the authenticated domain to build a reputation. But they weren’t really checking much in the way of who was doing the authentication.
In the push to deploy authentication, ESPs assumed the responsibility for authentication deployed ESPs took the responsibility and did most of the work. For many or most customers, authentication was as simple as clicking a checkbox during deployment. Some ESPs do currently let customers authenticate the mail themselves, but there’s enough overhead in getting that deployed that they often charged extra to cover the costs.
DMARC is rapidly becoming an expectation or even a full on requirement for inbox delivery. In order to authenticate with DMARC, the authenticating domain must be in the same domain space as the visible from. If senders want to use their own domain in the visible from, DNS records have to be present in that domain space. Whether it’s a SPF TXT record or a domainkeys record the email sender customer needs to publish the correct information in DNS. Even now, if you try to authenticate with DKIM through google apps, they require you to publish DNS records.
ESPs aren’t in a situation where they can effectively manage authentication alignment for all their customers. Hosting companies are in even worse shape when it comes to letting customers authenticate email. Developers are facing the fact they need to go back and rework their authentication code. Businesses are facing the fact they need to change their processes so customers can authenticate with DMARC.
It’s not just the infrastructure providers that are facing challenges with authentication. Senders are going to discover they can no longer hand authentication off to their ESPs and not worry about it. They’re going to have to get DNS records published by their own staff.
Getting DNS updates through some big companies is sometimes more difficult than it should be. I had one client a few years ago where getting rDNS changed to something non-generic took over a month. From an IT standpoint, changing DNS should require approvals and proper channels. Marketers may find this new process challenging.
And, if organizations want to publish reject policies for their domains, then they will have to publish records for every outside provider they use. Some of those providers can’t support DMARC alignment right now.
In 2016 a lot of companies will discover their current infrastructure can’t cope with modern authentication requirements. A lot of effort, both in terms of product development and software development, will need to be spent to meet current needs. This means a lot of user visible features will be displaced while the technical debt is paid.
These changes will improve the security and safety of email for everyone. It won’t be very user visible, which will give the impression this was a slow year for email development. Don’t let that fool you, this will be a pivotal year in email.

CBL issues

I started seeing some folks complain about false CBL listings a few hours ago. I’m now seeing the same folks saying the listings are being removed.
The symptoms look similar to what happened in November (mentioned here), but it appears the CBL team are on top of things and are working to rectify things quickly.

Hands off address books

Germany’s highest court has ruled that Facebook’s practice of harvesting email addresses from their users contact lists in order to send invitations to them constitutes “advertising harassment” and violates German law on data protection and unfair trade practices. This in response to a suit filed by the Federation of German Consumer Organisations (VZBV)

Email Innovations Summit in May 2016

I’ve been accepted as a speaker for the Email Innovations Summit in Las Vegas in May. This is a conference hosted by the folks behind the Only Influencers group and should be a great way to meet some of the leading minds in email marketing.
I’ll be speaking on some of the things I see changing in the email space and how that will affect email marketing as a whole. I think it will be great fun and look forward to meeting many of my OI colleagues.

Port25 blocking

A number of hosting providers are blocking outgoing port25. This has implications for a lot of smaller senders who either want to run their own mail server or who use SMTP to send mail to their ESP.

Security vendors and trust.

A big part of my predictions for 2016, that I’ll publish shortly, is that security is going to be a huge issue. I think we’re really going to see receivers expecting senders to have their houses in order when it comes to sending mail.
Of course, some filter companies need to get their houses in order to. Yesterday, a security researcher went public with problems in the TrendMicro anti-virus appliance. These vulnerabilities would let any email sender remotely execute code on the recipients machine with no interaction of the user. They also exposed all the passwords on the machine to the outside world.
Even worse, Trend doesn’t seem to understand the urgency to fix this. They have started releasing patches for the exploits, but there are significant problems with the patched versions as well.
If you’re a Trend user, you may want to consider other vendors for desktop security. I know that no security is perfect and that other vendors have problems, too. But shipping a password manager that exposes all passwords is just incompetence. It seems like a corporate lack of understanding of what their business is and how to actually create security software.
Even worse is that lack of urgency from the Trend folks as the security researchers are explaining the problem. I don’t care if the person receiving the report was the janitor, anything that says security exploit should be escalated to someone who can determine if the report is valid.
Compare Trend’s reaction to this to Juniper’s reaction to discovering a backdoor in their code in December. First off, Juniper found the exploit during a routine code review. That alone tells you Juiper is continually monitoring their code security. Second, Juniper was reasonably open about the issue, with executives posting blogs and security posting advisories talking about the issue. More importantly, they shared how they were going to fix it and prevent it from happening again.
Security is such a large issue right now. We have to be able to trust our vendors to do what they’re selling us. Every vendor is going to make mistakes and have vulnerabilities. No code and no developer is perfect. I do expect, though, that vendors will take exploits seriously and act fast in order to correct the problem. I’m not seeing that sense of urgency with Trend.

Spamhaus reports Verizon routing hijacked IPs

Late last week Spamhaus published a blog post detailing their investigation into Verizon routing millions of IP addresses hijacked by spammers.
The Spamhaus blog post goes into some detail about what hijacked routing is.

Triggered and transactional emails

Earlier this week I was talking on IRC with some colleagues. There was some kvetching about senders that think transactional emails are the same as triggered emails. This led to discussion about whether transactional and triggered emails are the same. I don’t think they are, but it took a while for me to come up with why I don’t think they’re the same. It took even longer to come up with definitions I liked.
Transactional Emails: Emails sent in response to direct request by the recipient. Transactional emails are usually one-off emails. Transactional emails probably don’t need an unsubscribe link, although it may be a good idea to include one just to make people feel comfortable receiving them. Examples: password reset emails, receipts, tickets.
Triggered Emails: Emails sent in response to an action by a recipient. Triggered emails can be one-off, but can also be series of emails. Triggered emails should have an unsubscribe link, so people can stop the emails if needed. Examples: cart abandonment emails, after purchase surveys, followups to software installation.
The key difference is that in a transactional email, the recipient has asked for that particular email. In a triggered email, the recipient may very well want and respond to the email, but they didn’t ask for it.
There are, as always, some grey areas here. Is a welcome message transactional or triggered? Probably transactional, but they should always have an unsubscribe link.
What about software installation followups? We’ve been looking at some alternatives to our current time tracking software which involved me setting up accounts at multiple different SaaS providers. A couple of them had triggered welcome series. These emails let me know things I could do with the software, things I still needed to set up, and led me through the process of trying out their system.
This was mostly good, but not completely. One of the series didn’t have an opt-out link, though. That was somewhat annoying because I’d already decided the tracker didn’t do what we needed. I couldn’t make the mail stop. I think if there is one thing I’d say about mail is that senders should never force someone to receive their mail.
It’s tempting for senders to define all triggered emails as transactional. Since it’s a user action that caused the mail to be sent, it must be a transactional email. But a lot of triggered emails are triggered by actions the user doesn’t know will trigger an email. Cart abandonment emails are a good example of this, not every retailer has them and so users aren’t yet expecting to get an email if they drop stuff in their carts and then leave the site.
Overall, both transactional and triggered emails have their place in a healthy email program. But they shouldn’t be confused for one another and should be treated as separate mail streams.