March 2015: The month in email

Happy March! We started the month with some more movement around CASL enforcement from our spam-fighting friends to the north. We noted a $1.1 million fine levied against Compu-Finder for CASL violations, as well as a $48,000 fine to Plentyoffish Media for failing to provide unsubscribe links. We noted a few interesting things: the fines are not being imposed at the maximum limits, violations are not just on B2C marketing, but also on B2B senders, and finally, that it really just makes sense — both from a delivery perspective and a financial perspective — to comply with the very reasonable best practices outlined in CASL.

Here in the US, the Email Experience Council of the Direct Marketing Association hosted a series of webinars this month on delivery and engagement. First up was a MessageSystems webinar with Matt Moleski of Comcast. I’d definitely recommend listening to the webinar if you have a moment. I recapped it here and briefly noted the ensuing controversy over different interpretations of various ISP policies that came out of that discussion. We wrote up some thoughts and predictions before the second webinar, and followed that up with a recap of what was actually said, as well as  a summary of tweets related to the discussion. All in all, it was fascinating to get a look behind the scenes at the various ISPs. Though we knew they each handled mail a bit differently, it was good to get more of a sense of how that works. And our takeaway, as always, is that engagement matters in delivery decisions.

Coming out of the webinar, we looked at filtering at Hotmail, which seems to be doing things a bit differently than other ISPs. We also wrote about Gmail filtering, where we noted just how quickly sender changes — both positive and negative — get reflected in delivery to the inbox. Finally, we looked at what happens when spam filters fail.

Speaking of getting a peek behind the scenes, Steve’s recent post about bad SPF records will give you a glimpse of some of how we figure things out at WttW when we come across things that just don’t make sense. Also, if you missed Josh’s post on Senders Best Practices from MAAWG, it’s worth a look.

Old Lists and RadioShack
Best practices … what are they?

Related Posts

June 2014: The month in email

Each month, we like to focus on a core email feature or function and present an overview for people looking to learn more. This month, we addressed authentication with SPF.
We also talked about feedback mechanisms, and the importance for senders to participate in FBL processes.
In our ongoing discussions about spam filters, we took a look at the state of our own inboxes and lamented the challenge spam we get from Spamarrest. We also pointed out a post from Cloudmark where they reiterate much of what we’ve been saying about filters: there’s no secret sauce, just a continuing series of efforts to make sure recipients get only the mail they want and expect to receive. We also looked at a grey area in the realm of wanted and expected mail: role accounts (such as “marketing@companyname.com”) and how ESPs handle them.
As always, getting into the Gmail inbox is a big priority for our clients and other senders. We talked a bit about this here, and a bit more about the ever-changing world of filters here.
On the subject of list management, we wrote about the state of affiliate mailers and the heightened delivery challenges they face getting in the inbox. We got our usual quota of spam, and a call from a marketer who had purchased our names on a list. You can imagine how effective that was for them.
And in a not-at-all-surprising development, spammers have started to employ DMARC workarounds. We highlighted some of the Yahoo-specific issues in a post that raises more questions.
We also saw some things we quite liked in June. In the Best Practices Hall of Fame, we gave props to this privacy policy change notification and to our bank’s ATM receipts.
We also reviewed some interesting new and updated technology in the commercial MTA space, and were happy to share those findings.

Read More

July 2014: The month in email

We continue to be busy with really interesting client work. Look for some new posts and white papers to come out of this research over the next few months, but for now blogging has been a bit light while we’re working hard. In parallel with our busy times, we have also been pondering the ways in which the email world illustrates the classic bon mot  “plus ça change, plus c’est la même chose”, and we’ve been revisiting some posts from a few years ago to examine this.
We started July with a nod to a good subscription experience just as CASL, the Canadian Anti-Spam Legislation went into effect on Canada Day. While companies have another 17 months to put these provisions into practice, it’s a good reminder that periodic re-engagement with customers can be very effective in helping you maintain high-quality subscriber lists. We talked a bit more about CASL here and what protections the law intends.
In stark contrast, we posted about an organization that is doing a less-than-stellar job making sure they’re only sending wanted email. The Direct Marketing Association is a terrific resource and member organization for marketers across industries and channels, but their email marketing practices don’t always live up to their mission of “Advancing and Protecting Responsible Data-Driven Marketing”, and we explored some ways in which they might improve this.
Those of you who have been reading this blog for any time at all know that we tend to talk about wanted mail and unwanted mail rather than the more general category of spam. Marketers tend to think their mail can’t possibly be spam if it’s not offering Viagra or phishing for credit card information, but that’s not really the point — if a customer doesn’t want to read your email about new mountain bikes, even if they bought a mountain bike from you three years ago, that’s unwanted email. Here’s a post we revisited about why customers might not want your mail, and a new post about engagement.
One risk of sending unwanted email, of course, is that customers complain, and that will affect your delivery going forward. We revisited a post about feedback loops, and also talked a bit about addressing delivery problems as they come up rather than waiting for them to resolve on their own (mostly, they won’t!)
I also proposed a bit of a thought experiment around monetizing the complaint stream, and followed up with a second post. There are some good points in the comments of those posts, but mostly I think it’s an interesting solution to addressing risk and abuse at ESPs.
Finally, Steve wrote a short post about our new mail servers and how quickly spammers descended as we set those up. It’s a constant battle!

Read More

Bad SPF can hurt your reputation

Can a bad SPF record ruin your delivery, even though all your mail still passes SPF?
Yes, it can.
One of our clients had issues with poor delivery rates to the inbox at gmail and came to us with the theory that it was due to other people using their domain to send spam to gmail. This theory was based on ReturnPath instrumentation showing mail “from” their domain coming from other IP addresses, and a plausible looking correlation between that mail being sent and their problems at gmail.
Checking their bounce handler, we see a lot of bounces coming in suggesting that someone is sending poor quality mail using their bounce domain from quite a few IP addresses, including a suspicious number scattered in small blocks across 69.64.0.0/8.
Their question they had was whether they should publish DMARC records to fix the problem, and whether they should use a DMARC policy of p=reject or p=none. They’re a good candidate for DMARC – their domains are used purely for bulk or transactional mail, they have a tightly controlled mail infrastructure for their marketing domains, and they’re already publishing SPF records and signing all the mail they send with DKIM.
I was half way through writing up my normal answer about DMARC deployment for customers with this sort of mail infrastructure – “It won’t help with delivery problems directly, but publishing with p=none and analyzing the reports you get back will give you insight into your mail flows, and provide the data you need to decide whether using DMARC p=reject is appropriate for your business model and mail flows.” – when I realized that something just didn’t make sense.
Gmail, perhaps more than most other mailbox providers, base their delivery decisions on data they gather mechanically from all their mailboxes. And they really understand domain-based reputation and the difference between authenticated and non-authenticated email. Why on earth would non-authenticated email from an unrelated IP address be damaging the domain reputation, and hence the delivery of authenticated legitimate email? That makes no sense.
Meanwhile, over in our slack channel, Josh was double-checking their infrastructure…
 
slack
Oops. They have a small block of 8 IP addresses from which they send most of their email. When setting up their SPF records they inadvertently used ip4:69.20.20.48/8 instead of ip4:69.20.20.48/29 for that block of addresses. A /8 isn’t eight IP addresses – it’s every one of the 16,777,216 IP addresses that begins with “69.”.
Suddenly everything makes sense.
The SPF thinko means that all mail claiming to be from the client domain that’s sent from any IP address beginning with “69.” passes SPF – including the deluge of spam coming from the snowshoe spammers in 69.64.*.
Gmail (and other ISPs) don’t see a difference between the legitimate email and the SPF authenticated spam – they’re just seeing a high volume of authenticated email from the client domain, a large fraction of which is spam. That’s damaged the reputation of the client domain, causing their legitimate email to end up in the spam folder.
(The reality of filtering is more than just domain reputation, of course, but a terrible domain reputation is definitely going to cause you problems.)
The immediate action to take is simple – fix the SPF record so only legitimate mail will be authenticated. That’ll take effect within a couple of hours, as the old SPF record has a short TTL, and ISPs will start seeing the correct SPF record and begin rejigging their reputation.
We’ll keep monitoring delivery rates, check how long ISPs take to notice reputation changes, potentially reach out to some ISPs to see if it’s appropriate for them to do a one-time reputation reset for the affected domains, but we’re hoping things will begin to improve in the next few days.
What can you do to avoid or mitigate this sort of problem?

Read More