Fun with spam filters

I recently had a challenging travel experience in the Netherlands, trying to get from Schipol airport to a conference I was speaking at. As part of my attempt to get out of the airport, I installed UBER on my phone. There were some challenges with getting UBER to authorise my phone number, so I tried linking it to my Gmail account.

I checked Gmail today and noticed there was a message from UBER sitting in my spam folder. Why? Because the language of the email was “a different language than [my] messages usually use.”

Language filters are ones we don’t often talk about. I will sometimes mention them when I’m discussing the scope of what filters look like. But for most senders, they’re never going to send a message that is in a language different than the default language of the user. The confluence of events that caused me to sign up for UBER in a non-English-speaking country was somewhat unique.

At the time I signed up for UBER I was in The Netherlands. So, appropriately, they sent me the terms and conditions that cover riders there. They sent said terms and conditions to me in Dutch, because that’s the default language in the country where I activated my account. I wonder, though, if I had signed up with my Irish (or even US) phone number rather than my Gmail account, if the message would have arrived in English. Of course, being back in an English speaking country, it’s hard to test.

One thing this does tell me is “not in users’ primary language” is a huge negative in Gmail. This is UBER. When it comes to email they do things right.

Authentication is spot on. Gmail KNOWS this message is really from UBER. DKIM checks out, it’s aligned with the From: address, there’s a DMARC record. The content is UBERs terms and conditions, and I’m sure Google knows that, too. As UBERs service continues to grow, I’m sure this content is sent regularly and at a high enough volume to generate a strong positive reputation. Google even knows it was me that signed up for UBER because I used Google’s OAUTH to connect UBER to my gmail address.

Still, none of that was enough to get Google to deliver the mail to my inbox. It’s not my language, so it goes to bulk. I’m sure, though, that all the native Dutch speakers got the exact same message in their inbox.

It’s rare we can see how one single factor can so clearly affect delivery of an otherwise good, high reputation stream. But, as I regularly say: context matters. In this case, a different language matters more than any positive reputation signals, including the fact that I signed up using my Google account.

Filtering at some places is more complex than spam or not spam. It’s about what the user wants and expects in their inbox. Send something the webmail provider thinks is not what the user wants or expects, and mail is likely to end up in the bulk folder.

 

 

Related Posts

July 2017: The month in email

August is here, and as usual, we’re discussing spam, permissions, bots, filters, delivery challenges, and best practices.

One of the things we see over and over again, both with marketers and with companies that send us email, is that permission is rarely binary — companies want a fair amount of wiggle room, or “implied permission” to send. There are plenty of examples of how companies try to dance around clear permissions, such as this opt form from a company we used to do business with. But there are lots of questions here: can you legitimately mail to addresses you haven’t interacted with in 5 years? 10 years? What’s the best way to re-engage, if at all?
We frequently get questions about how to address deliverability challenges, and I wrote up a post about some of the steps we take as we help our clients with this. These are short-term fixes; for long-term success, the most effective strategy is sending email that people want and expect. Engagement is always at the core of a sustainable email program.
We’ve also discussed the rise of B2B spam, and the ways in which marketing technologies contribute to the problem. B2B marketers struggle to use social and email channels appropriately to reach customers and prospects, but still need to be thoughtful about how they do it. I also wrote about some of the ways that marketing automation plugins facilitate spam and how companies should step up to address the problem. Here’s an example of what happens when the automation plugins go awry.
I wrote a few posts about domain management and the implications for security and fraud. The first was about how cousin domain names can set users up for phishing and fraud, and the second was a useful checklist for looking at your company’s domain management. We also looked at abuse across online communities, which is an increasing problem and one we’re very committed to fighting.
I also highlighted a few best practices this month: guidelines for choosing a new ESP and active buttons in the subject line for Gmail.
And finally, we celebrated the 80th birthday of the original SPAM. If you’re a regular reader of this blog, you probably already know why unwanted email is called SPAM, but just in case, here’s a refresher….

Read More

Mail Client Improvements

There’s been extensive and ongoing development of email through the years, but much of it has been behind the scenes. We were focused on the technology and safety and robustness of the channel. We’re not done yet, but things are much better than they were.
The good part of that is there is some space to make improvements to the inbox as well. Over the last few months there have been a number of announcements from different mail client providers about how they’re updating their mail client.

Read More

From the archives: Taking Permission

From February 2010, Taking Permission.

Permission is always a hot topic in email marketing. Permission is key! the experts tell us. Get permission to send email! the ISPs tell us.
Marketers have responded by setting up processes to “get” permission from recipients before adding them to mailing lists. They point to their privacy polices and signup forms and say “Look! the recipient gave us permission.”
In many cases, though, the permission isn’t given to the sender, permission is taken from the recipient.
Yes, permission is being TAKEN by the sender. At the point of address collection many senders set the default to be the recipient gets mail. These processes take any notion of giving permission out of the equation. The recipient doesn’t have to give permission, permission is assumed.
This isn’t real permission. No process that requires the user to take action to stop themselves from being opted in is real permission. A default state of yes takes the actual opt-in step away from the recipient.
Permission just isn’t about saying “well, we told the user if they gave us an email address we’d send them mail and they gave us an email address anyway.” Permission is about giving the recipients a choice in what they want to receive. All too often senders take permission from recipients instead of asking for permission to be given.
Since that post was originally written, some things have changed.
CASL has come into effect. CASL prevents marketers from taking permission as egregiously as what prompted this post. Under CASL, pre-checked opt-in boxes do not count as explicit permission. The law does have a category of implicit permission, which consists of an active consumer / vendor relationship. This implicit permission is limited in scope and senders have to stop mailing 2 years after the last activity.
The other change is in Gmail filters. Whatever they’re doing these days seems to really pick out mail that doesn’t have great permission. Business models that would work a few years ago are now struggling to get to the inbox at Gmail. Many of these are non-relationship emails – one off confirmations, tickets, receipts. There isn’t much of a relationship between the sender and the recipient, so the filters are biased against the mail.
Permission is still key, but these days I’m not sure even informed permission is enough.

Read More