Recent Posts

The Problem With Affiliates

If I see BarkBox I think Spam.

That’s because, despite their marketing team effort, facebook and banner ad budget, the main place I see them advertised is via spam in my mailbox.

Reading RFCs

We mention RFCs quite a lot, both explicitly (RFC 6376 is the specification for DKIM) and implicitly (the 822.From aka bounce address aka return path).

A few weeks ago we took a drive down I5 to attend a service at Bakersfield National Cemetery. Amid the acres and acres of almond farms there were patches of black from recent grassfires. Typical but boring California landscape. Wildfires are a hugely destructive but continual threat in California. Growing up on the east coast, I never really understood wildfires. How can acres and acres and square miles just burn?
Having lived in California for almost as long as I lived on the east coast, I understand a bit better. In some ways, I have to. Even living right on the bay, there’s still some risk of fire. Like the grass fire a few miles from here across the street from the FB headquarters a few years ago. Further up the hills, there’s an even bigger risk of fire. Every driver can see the signs and precautions. Fields have plowed firebreaks around the edges. CAL FIRE posts signs alerting the public to the current fire risk status.

What do wildfires have to do with deliverability?
I associate wildfires and deliverability together because of a radio show I did a few years ago. It was pitched as a “showdown” between marketers and deliverability. I was the representative of deliverability. During the conversation, one of the marketers mentioned that deliverability people were too focused on the worst case scenario. That we spoke like we expected a fire to break out at any moment. His point was that deliverability spent too much time focused on what could happen and not enough time actually just letting marketers send mail.
His overall point was deliverability people should put out the fires, rather than trying to prevent them in the first place.
I thought about that conversation during the long drive down I5 the other day. I saw the firebreaks plowed into fields at the side of the road. And I saw the patches of blackness from fires reach along the highway where there were no firebreaks.
There are a group of marketers who really hate the entire concept of deliverability. Their point of view is that deliverability is hampering their ability to make money. I’ve even heard some of them assert they don’t care if 70% of their mail goes to the bulk folder. They should be allowed to send blasts of mail and deliverability shouldn’t tell them what they can do. Deliverability, so the complaint goes, is simply out to hurt marketers.
The only good deliverability is that which gets them unblocked when their behavior triggers IP based blocks. When the field is burning down, they’d like us to come spray water on it. And then go away and let them keep throwing lit cigarettes out their car windows.
But that’s not all that firefighting is about. Much of the work is preventing fires in the first place. In the US, a lot of that work is done through building codes. There are mandates like smoke detectors, fuel free spaces around dwellings, and sprinklers for some buildings. Monitoring local conditions and enforcing burn bans are also a large part of what the fire service does.
I like the fire fighter motif a lot. Much of what deliverability does is actually about preventing the block. ESPs have building code like standards for what mail is good and what is bad and what can be sent on their networks. Many of us publicly speak and educate about good practices and preventing blocks in the first place.
Fire prevention is about risk management and understanding how little things add up. Deliverability is similar. All the little things senders do to improve their deliverability adds up to a lower risk of fire. Yes, things like listbombing happen where even the best deliverability advice wouldn’t have prevented it. But, overall, deliverability wants to help senders get their mail in front of the people who can act on it. Some of that advice, though, takes the form of risk management and saying no.

Microsoft using Spamhaus Lists

An on the ball reader sent me a note today showing a bounce message indicating microsoft was rejecting mail due to a Spamhaus Blocklist Listing.
5.7.1 Client host [10.10.10.10] blocked using Spamhaus. To request removal from this list see http://www.spamhaus.org/lookup.lasso (S3130). [VE1EUR03FT043.eop-EUR03.prod.protection.outlook.com]
The IP in question is listed on the CSS, which means at a minimum Microsoft is using the SBL. I expect they’re actually using the ZEN list. ZEN provides a single lookup for 3 different lists: the SBL, XBL and PBL. The XBL is a list of virus infected machines and the PBL is a list of IPs that the IP owners state shouldn’t be sending email. Both of these lists are generally safe to use. If MS is using the SBL, it’s very likely they’re using the other two as well.

Minimal DMARC

The intent of DMARC is to cause emails to silently vanish.
Ideally deploying DMARC would cause all malicious email that uses your domain in the From address, but which has absolutely nothing to with you to vanish, while still allowing all email you send, including mail that was sent through third parties or forwarded, to be delivered.
For some organizations you can get really close to that ideal. If you control (and know about) all the points from which email is sent, if your recipients are individuals with normal consumer or business mailboxes, their mailbox providers don’t do internal forwarding in a way that breaks DKIM before DMARC is checked and, most importantly, if your recipients are a demographic that doesn’t do anything unusual with their email – no vanity domain forwarding, no automated forwarding to other recipients, no alumni domain forwarding, no forwarding to their “real” mailbox on another provider – then DMARC may work well. As long as you follow all the best practices during the DMARC deployment process it’ll all be fine.
What, though, if you’re not in that situation? What if your recipients have been happily forwarding the mail you send to them to internal mailing lists and alternate accounts and so on for decades? And that forwarding is the sort that’s likely to break DKIM signatures as well as break SPF? And while everyone would advise you not to deploy DMARC p=reject, or at least to roll it out very slowly and carefully with a long monitoring period where you watch what happens with p-none, you have to deploy p=reject real soon now?
What can you do that’s least likely to break things, while still letting you say “We have deployed DMARC with p=reject” with a straight face?

Unsubscribe means unsubscribe

But, unfortunately, some senders don’t actually think unsubscribe means stop sending mail.
Today, for instance, the nice folks at The Container Store sent me an email with an “important update to my POP! account”

Yes, that’s an address I gave them. But I don’t have any record of setting up an account. I was on their mailing list for all of 4 emails back in November 2016 before unsubscribing. But, they’ve decided they can email me despite my unsubscribe request.
They’ve cloaked this as an “Important Account Update” about some account I don’t have. In fact, when I go to their website and try and see what this oh so important account is about they tell me:

I understand legitimate account notifications might be an acceptable excuse to send mail even after the recipient opted out. This, however, was done extremely poorly. There is no record of the account that they are sending me information about. Neither the company nor I have any record of this account of mine.
At a minimum the emails should have only be sent to the folks that actually had an account. But, they weren’t.
I also have some issues with a company requiring recipients to accept email in order to continue using reward points. As a recipient, if I wanted what they were offering I might go ahead and continue receiving emails. But, I might not. It would all depend on how aggressive their email program is and how good the rewards are. As a deliverability consultant, this strikes me as a great way to create a mailing list full of unengaged users. Unengaged users lead to spam foldering and eventual failure of an email marketing program.
Whatever some executives think, and having been in this industry for a decade and I half I’m sure this is coming from the top down, this is not a good way to build an email program. You really can’t force folks to accept your email. ISPs are too protective of their users to make that a viable strategy.

Consent must be informed

In the deliverability space we talk about permission and consent a lot. All too often, though, consent is taken not given. Marketers and senders assume they have permission to send email, while the recipient is left expecting no email.

What is spearphishing?

As I’m writing this, I’m watching Deputy Atty General Rod Rosenstein discuss the indictments of 12 Russian military officers for hacking activities during the 2016 election cycle. One of the methods used to gain access to systems was spearphishing.
I think most of us know what phishing is, sending lots of emails to a wide range of people in an attempt to collect some credentials. These credentials are usually passwords to bank or email accounts, but can also be things like amazon or other accounts.
Spearphishing is an attempt to collect credentials from a specific person. The net isn’t thrown wide, to collect any credentials, rather individuals are targeted and researched. These attacks are planned. The targets are carefully researched and observed. The emails are crafted specifically for that target. If one set of emails doesn’t work, then they try again.
In terms of email marketing and deliverability, phishing is something detectable by many anti-spam filters. They’re sent in bulk, and they all look similar or identical to the filters. Spearphising isn’t as simple to detect with standard tools. What many organizations have done is try and combat this with warnings in the client. Like this one from gmail:

Security is becoming a bigger and bigger part of email filtering. I expect that as filters start addressing security more, we’ll see increased warnings like the above.
What can senders do?

The inbox is a moving target

The more I look at the industry, the more convinced I am that we’re in the middle of a fundamental shift in how email is filtered. This shift will change how we handle email deliverability and what tools we have and what information we can use as senders to address challenges to getting to the inbox.

Who are mimecast?

Mimecast is a filter primarily used by businesses. They’re fairly widely used. In some of the data analysis I’ve done for clients, they’re a top 10 or top 20 filter.
Earlier today someone asked on Facebook if mimecast may be blocking emails based on the TLD. The short answer is it’s unlikely. I’ve not seen huge issues with them blocking based on TLD of the domain. They’re generally more selective than that.

The good news is mimecast is really pretty good about giving you explanations for why they’re blocking. They’ll even tell you if it’s mimecast related or if it’s a specific user / user-company block.
Some example rejection messages from a recent dive into some bounce logs.