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.

Related Posts

CASL is more privacy law than anti-spam law

Michael Geist, a law professor in Canada, writes about the new CASL law, why it’s necessary and why it’s more about privacy and consumer protection than just about spam.

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

October 2014 – The Month in Email

October was action-packed at WttW. We wrapped up some big and interesting client projects (look for some case studies soon!), attended another great M³AAWG conference, and made an exciting announcement that we’re hiring a deliverability specialist. The combination of these frees up some more of my time for blogging, which I’ve really missed. Look for more from me in November and December.

Read More