Creating emails

laura
Industry
June 6, 2016

Email is, still, primarily a written medium. This means that good copywriting is crucial. Today I opened up an email and the pre-header says:
Laura, should have get your Naturals Sample Bag.*Web Version

Wait. What?
Maybe they mean “should have got”? But that’s implying they’re sending out free sample bags to everyone. That can’t be right. But I can’t tell because with images off that’s the only text in the mail, except the footer and legal information.
When you load images you get a little more clarity. Apparently, making a big enough purchase trigger a bunch of samples to be included in your delivery. So the line possibly should be “Laura, get your natural samples bag.”
Maybe it was intentional. After all it did get me to load images to see what the email was about.

How did this get past them?

I know that a lot of departments are working flat out trying to create content. I know many are understaffed and have significant demands on their time. I’m sure the company in question is very unhappy this error went out at the top of their email. Nothing I say here is intended to shame or embarrass the company or the writer.
Let’s be honest, I’m not one to talk. I’m the queen of distracted writing where I stop writing a sentence in the middle and go to edit somewhere else in the document. I find errors like that in my drafts all the time. Once or twice I’ve had the same type of thing go out to a client ?. Most of my blog posts are generally OK, but I’ve had some folks point out some significant typos (and thinkos) over the years.

The big problem

OK, there are two major issues that don’t make the email writer’s job any easier. One is inherent to email as a protocol and we’re going to have to just deal with it. The other is more manageable.
The first is the complexity of email clients. Think about it, we’re trying to write a single message that can be displayed on everything from a watch face to a multi-monitor setup. Not only that, we’re sending the message over a protocol (SMTP) that is limited to 7-bit ASCII. That’s complicated!
The other part is the lack of good tools. Sure, every ESP has created their own email creation tool. Most of the time it runs in a web browser and lets senders create pretty standard HTML messages. Many companies have created their own ad hoc tools internally that help the messages get built. But this cobbled together tool chain is usually fragile and can be frustrating to work with.

Better tools can help

There aren’t many free or low cost creation tools out there but there are a few.
MJML from Mailjet. This is a markup language that makes it easier to create layouts so marketers can spend more time on content than coding. The language is designed to make creation easier, and is then compiled into compliant HTML.
Earlier this year we wrote about Foundation for Emails from Zurb and their framework.

Foundation: A toolkit for designing responsive emails

Zurb announced today version 2 of “Foundation for Email”, a full stack for designing content for responsive email.
inky
It looks rather nice, with features a modern web developer might look for when working on email content. It has many of the things you’d expect a web design stack to have. It support SASS for styling, includes browser sync for previewing content as it’s edited, both on a local browser and on a device, and uses gulp to tie the workflow together.
But it also has some features useful for email that you’d be unlikely to find in a web design stack. It has an inliner, to convert separate SASS/CSS and HTML content into a single HTML document suitable for sending by mail. And it supports a slightly extended HTML format called “Inky”, which lets you use simple tags like <row> and <column> to develop grid-based content, then compile those into old-school HTML tables which mail clients will happily render.
And it comes with ten starter templates for different types of email.
You can find documentation, downloads and examples here.

SWAKS: the SMTP Swiss Army Knife

flash_m_laser_1200_900
SWAKS is a general purpose testing tool for SMTP. For basic SMTP testing it’s a more convenient, scriptable alternative to running a transaction by hand, but it also lets you test things that are difficult to do manually, such as authentication or TLS encryption.
It’s a perl script that installs fairly easily on OS X or any Linux/unix system (and can be installed on Windows, if you have perl installed there).
It’s pretty well documented, but it can be a bit overwhelming to start with. Here are some simple recipes:
Send a test email:

Who's publishing DMARC?

DMARC is a way for a domain owner to say “If you see this domain in a From: header and it’s not been sent straight from us, please don’t deliver the mail”. If a domain is only used for bulk and transactional mail, it can mitigate a subset of phishing attacks without causing too many problems for legitimate email.
In other cases, it can cause significant problems. Some of those problems impact discussion lists, but others cause problems for ESPs servicing small companies and individuals. ESP customers use their email addresses in the From: field; if they’re a small customer using the email address provided by their ISP, and that ISP publishes a DMARC record with p=reject, a large chunk of the mail they’re sending will bounce. When that happens recipients will stop getting their email, they’ll be removed from the mailing list due to bounces, and there’s some risk of blocks being raised against the sending IP address.
Because of that, it’s good to be able to see what consumer ISPs are doing with DMARC.
I’ve created a tool at dmarc.wordtothewise.com that regularly checks a list of large consumer ISPs and webmail providers and sees what DMARC records they’re publishing.
There are two main variants of DMARC records.
One is policy “reject” – meaning that mail that isn’t authenticated (or for which authentication has been broken in transit) will likely be rejected.
The other is policy “none” – meaning that the ISP publishing the record doesn’t want recipients to change their delivery decisions, but are asking for feedback about their mailstream, and how much of it fails authentication. That can mean that the ISP is evaluating whether or not to publish p=REJECT, or is in the process of deploying p=REJECT. Or it can just mean that they’re using DMARC to monitor where mail using their domain in the From: address is being sent from. There’s no way to tell which is the case unless they’ve made an announcement about their plans.
Hopefully this will be a useful tool to monitor DMARC deployment by consumer ISPs, and to help diagnose delivery problems that may be caused by DMARC.