According to the UK DMA, marketers report improvements in deliverability after GDPR went into effect.
I mean, thank you UK DMA for doing the research. Of course deliverability is going to improve when you send mail to those people who have expressly opted into your mail.
76% report an increase in open rates in the past 12 months; 75% say click- throughs are higher; 51% say ROI has risen. Opt-out rates have decreased according to 41%, and 55% say spam complaints are also down — further evidence of the GDPR effect. DMA UK Marketer Email Tracker 2019
We often gloss over the most important best practice: send mail to people who ask for it. Many of the data hygiene recommendations are all about making sure that the recipients still want your mail.
Recipients, and ISPs, expect senders to have permission before they start blasting out emails. Most best practices are a way to confirm permission. The others, things like authentication and the like, they’re ways for ISPs to identify your mail streams so they can assign reputation and effectively deliver mail.
Would you trust an address verification company that used twitter spam to advertise their product?
Would you trust an address verification company that sent email spam to advertise their product?
Would you trust an address verification company that sent email advertising their product to made up addresses?
Would you trust an address verification company that sent email advertising their product to spamtraps?
Would you trust an address verification company that sent email advertising their product to role accounts?
Would you trust an address verification company that uses a botnet as part of their business?
Would you trust an address verification company that sends spam to verify addresses?
Would you trust an address verification company that resells customer address data to other customers?
Would you trust an address verification company that lies about their relationship with blocklists like Spamhaus?
If you’re using an email address verification company, chances are they’re doing at least one of the above.
What is Address Verification?
Address verification is primarily a way to identify which addresses are deliverable. The simple way to verify an address is to start a normal mail transaction, tell the MX you are sending mail to a particular address and then wait for the MX to tell you if that email address is active or not. Once the MX has said the address exists or not, you can quit the email transaction and go on to the next MX.
This technique was pioneered by spammers back in the early 2000s. Known as dictionary attacks they were a way for spammers to identify which addresses might exist on a domain without having to spend any effort sending mail to non existent ones. This technique was also used by companies who sold addresses to ensure ‘high deliverability’ for their lists.
Dictionary attacks caused a number of problems for the ISPs, including tying up SMTP resources for hours or days at a time. ISPs quickly developed automated defences against these types of attacks. In fact, I suspect some of these defences are why spammers pivoted to selling address verification services.
But address verification isn’t a dictionary attack!
I can hear the protests now, just because they use the same underlying technology and intend to do the same thing, address verification isn’t the same as a dictionary attack. It’s not a problem! People aren’t doing it for the same reason. Well, except they are. The fundamental idea behind both processes is the same: to remove a non-existent address before sending mail to it. There is not even a real difference in intention here.
If ISPs wanted senders to verify addresses before sending to them, they would have never turned off VRFY. That’s right, there’s verification built right into the SMTP protocol. This was quickly abused and disabled at most ISPs. It’s not a far stretch to say ISPs don’t support this activity since they disabled VRFY and they implemented active measures to stop 3rd parties from probing their MX looking for active addresses.
Some ISPs, like Yahoo, have gone a step further. They moved all of their rejections, even ones for non-existent addresses, until after the entire email has been sent to them. It’s impossible for dictionary attacks to identify deliverable addresses at domains they manage.
So what’s the problem?
My biggest issue, though, is not that address verification is what spammers do, or that the ISPs don’t like it or that it’s borderline abusive when done in bulk. The reason I hate address verification is that is erases one of the most valuable pieces of data we have about how accurate our address collection process is.
Bounce rates give us an indication of how inaccurate our address collection process is. We know that every bounced address is an address that doesn’t belong to the person who entered it into the form. Whether it was a typo or a deliberately faked address it is a fact someone gave us an address that didn’t belong to them. Bad addresses are a way of monitoring data accuracy.
This doesn’t mean that every deliverable address is accurate. We have to assume that some of the deliverable addresses also don’t belong to the person who submitted it. Senders who use address verification are lulled into a false sense of security. They assume that a deliverable address is a correct address. This simply isn’t true.
To address the Yahoo problem and the deliverable problem, many address verification companies have moved on to new techniques. One of the things they’re doing now is collecting PII on recipients for resale. I’m not sure how honest they’re being with their customers about this. The words proprietary technology hide a multitude of sins and business practices.
Let’s be honest, though, no company actually has permission from the address owner to collect this data. Senders typically don’t have permission to share email addresses with 3rd parties for commercial gain. The third parties don’t have permission to collect data about the address. We all kind of hand wave around the issue, but the reality is, if consumers knew their activity was being tracked in this manner, many would object.
Data accuracy is vital
There’s a woman in Florida who thinks the gmail address I acquired in 2004 belongs to her. I get lots of things on her behalf: event tickets, forwards from her church groups, invites for Sunday brunch. A couple years ago an insurance company sent me all her documents. Do you know how much PII is in insurance documents? Address, date of birth, social security number, home value, next of kin… the list goes on and on.
The only thing typical address verification does is identify if an address is deliverable or not. It cannot say an address belongs to the person the sender thinks it does. If the insurance company did true data verification rather than simply identifying an address was deliverable, then K.S. who lives on the Loxahatchee River in Jupiter, Florida would have her insurance documents and I wouldn’t know anything about her.
Address verification doesn’t actually fix the real problem, it hides it. The real problem is data accuracy. With verification we can pretend our data is accurate, simply by removing the very visibly non-accurate data. But the much bigger issue is sending mail to addresses that don’t belong to our customers. The most problematic of those is where the email address belongs to a completely different person. Address verification does nothing to affect that, other than hide that our address collection process is broken.
Address verification has been aggressively sold as a way to make data more accurate, but it doesn’t. All standard verification does is hide very obvious data errors. So what can we do?
I know my anti-spammer friends are jumping to tell me that confirmed opt-in is the solution. They can just sit back down because COI has it’s own problems. As senders we can’t always trust that just because a link is clicked that we are connecting with the right person. One ESP tracked thousands of clicks on a confirmation link sent to a spamtrap. Various security appliances and filters follow links in emails. Even some spamtraps will follow links in messages, including confirmation links. COI is not the solution.
At some point, the email industry has conflated the issues of deliverability and data accuracy. They’ve assumed if their delivery is good their data must also be good. It’s never been true, though,
The first step of solving a problem is admitting there is one. Address verification lets senders of all sizes pretend there is no problem with their data collection. It hides the most visible examples of bad data, and lets companies ignore the true scope of the problem.
We need to measure data accuracy by the metric of data being accurate not by the metric of being deliverable. How we do that depends on how important or vital the data is. Banks, health care and insurance providers should incorporate much more verification into the data processes. But even receipts and tickets and ‘low value’ email gets misdirected all the time.
I wish I had a pre-packaged, easily saleable product that I could tell you would fix the issue. But there isn’t going to be one solution, nor is it going to apply to every situation. I certainly can’t sell it as a fix to deliverability problems. Let’s be honest, even perfectly accurate data is going to have delivery problems.
The challenge I pose to email marketers is to incorporate real data validation into your collection processes. Start paying attention to the accuracy of your data instead of focusing on deliverability. Stop designing address acquisition processes that focus on how to collect the most email addresses with the least amount of friction. Design processes starting with the question: how can we link the email address to the person associated with this transaction, account or inquiry? What are the ways to close the circle so we know our data is accurate?
The Only Influencers list hosts a discussion about the value and use of open rates.
A potential client contacts me asking if I can get their open rates to a certain percentage.
A client shows me evidence of 100% inboxing but wants to improve their open rate.
An industry group runs sessions at multiple meetings discussing how inaccurate open rates are.
The industry needs to stop obsessing over open rates.
As measured by senders, an open means a particular image was loaded. This sometimes corresponds with an email being opened and read by a user.
There are a number of ways open rates can be wrong, though.
I mean, I get it, I use opens are easy to measure and easy to use. They’re a start for looking at a number of things. But we have to remember the data is, at best, an approximation. There are lots of folks opening and reading messages that never load a pixel (hi! is me!). There are also some people who show as opening the mail but have never looked at it.
At Gmail someone can open a mail, and then immediately mark it as spam. As I said recently, in some cases an open can hurt your reputation. “If they opened it they’re engaged with the mail” has always been an assumption. It’s become part of the delivery
They’re a data point. They’re not the be all and the end all of data points. In order to effectively use them you need to understand what they mean and what they don’t mean. They’re inaccurate at best and can be very misleading if you’re not paying attention.
We need to stop spending so much time obsessing about open rates and more time worrying about how accurate our data collection processes are.
In the 1970s, while the early drafts of the Internet were being developed, a competing model for networking was being put together by the ISO (International Organization for Standardization).
The OSI (Open Systems Interconnection) Model broke the work needed to implement a distributed network service into seven separate layers of abstraction, from the physical infrastructure at layer one all the way up to the application at layer seven. That was much more elegant and academically satisfying than the Internet’s TCP/IP, which was considered a bit ad-hoc in comparison.
It turns out that implementing a network often requires crossing the layers, so the seven layer model wasn’t a great basis for actually building a network on and the simpler TCP/IP four layer model won out.
Why do we care about an old, theoretical network model? Because even though it’s not really used in implementations it’s still an important part of the language engineers use to discuss networks. You need to be aware of it to understand references to “level 3” and “level 8” problems.
I’ve included rough mappings from bits of the email world onto each layer in this handy table:
That’s ten layers, not seven, you say. Yes, yes it is.
There’s always more to networking than just getting data in front of a user. There’ve been joking (not-joking) references to the “political” and even “religious” layers at the top of the stack. This shirt is one of the more notorious ones.
The three extra layers I gave above – individual, organization, government – are often useful abstractions, and are particularly relevant to email deliverability.
A “full stack” email expert needs to be intimately familiar with levels five through nine, and some situation will require more than a passing understanding of levels three, four and ten.
Right at the end of January, Microsoft appears to have made couple of changes to how they’re handling authentication. The interesting piece of this is that, in both cases, Microsoft is taking authentication protocols and using them in ways that are slightly outside the spec, but are logical extensions of the spec.
The first is an extension of DMARC. They’re rolling out inbox flags for Office365 users that identify some emails as Unverified Sender. It appears they’re basically doing DMARC verification whether or not the sender is publishing a DMARC record. They’re comparing the SPF and d= domains with the 5322.from to identify those senders that are unverified. Mail that doesn’t pass gets a mark in the inbox. Initial reports indicated that some messages were failing even if the authentication was in alignment as well as some increase in bulk foldering.
This is a very logical use of the concept of alignment. If the SPF domain or the d= domain are the same as the domain in the visible from, then it’s a clear sign the mail is actually from that company. And this isn’t new, companies were mentioning looking at the authentication and alignment for years. But it’s interesting that Microsoft is pushing that marker out to the user.
The other thing Microsoft is doing is around ARC. ARC is “authenticated received chain” and is one of the ways folks are trying to fix the breakage in forwarding introduced by DMARC. Essentially, when a company receives a message, they note whether or not the authentication passed, then sign the message with a ARC header (similar to a DKIM header). It’s a programatic way for a forwarder to say “hey, we received this and verified that it was authenticated and here’s our authenticating that fact.”
You may have seen ARC headers on some mail, Gmail’s been adding them for a while. At the end of January, I noticed that Microsoft was signing them fas well. But there was a bit of weirdness in it with regards to DKIM. Microsoft was asserting that they’d seen a DKIM signature that wasn’t available in the headers and a DNS lookup didn’t show any visible public key.
For Office365 tenants that have not implemented custom DKIM signing Microsoft is faking a DKIM signature and then wrapping that up in an ARC header and saying “yeah, this won’t authenticate for you, but we’re saying we authenticated it before sending it on.” The really clever bit about this is that there is no DKIM signature involved. Microsoft is using their login and customer authentication process to assign a d= to the message without forcing their customer to publish a DKIM key.
It does make for some messy headers (but ARC does that anyway). But it’s Microsoft saying “we authenticated that this person is legitimately using this domain to send mail even though they don’t have DKIM set up.” It’s outside the scope of the ARC protocol, but actually makes sense. Microsoft knows the user is legit and can just sidestep the work needed to publish custom DKIM.
It’s that time of year again where nearly all my client calls involve the question, “are you going to be at M3AAWG SF?” Up until last year, the answer was always yes. But now it’s not a brief drive up the peninsula and a BART ride into the city, it’s a transatlantic plane flight.
The clients I was talking with today said this was their first MAAWG and what did I recommend they should do or talk to. So here’s my list of things you should do if you’re new to MAAWG.
Attend the open round tables. These are where a lot of the documents and work starts so go and participate.
If you get into town on Monday attend the training sessions. Of particular note is the facilitation training that occurs on that day. MAAWG facilitation is a great way to get comfortable standing up in front of people, running a meeting and speaking out.
Go and meet folks at the member breakfast. It’s a great way to get to know folks who are there.
The working sessions are just that – sessions where folks get into a room to work on a document or some processes or a work product. Even if you just go and listen, it’s valuable to see how the group arrives at a consensus.
Introduce yourself and network. If there’s a group talking in the hallway, join them. Particularly if they’re in PacMan formation. And all of you who have been there before remember to be the PacMan.
Go to some of the non email sessions. A lot of the senders who go often focus on the sender sessions. But there’s a wealth of interesting information in the technical sessions as well. Join one and learn.
The vast majority of folks at MAAWG are awesome and welcoming and are more than happy to chat when they’re not running to another session or meeting. The best advice I can give is be there and jump right in.
Oh! And the hotel is back up on Nob Hill this year. You know those hills that San Francisco is famous for and the car chases? Yeah, one of them is Nob Hill. It’s a hike up and I do recommend a car up. You can BART from the airport, but grab an UBER or a cab for that last few blocks. Your leg muscles will thank you.
Have a great time! I’m definitely feeling the FOMO as I look at everyone making plans for the trip. But we’ll see everyone in London this summer (and, well, Dublin 2021 which is a short walk from our neighbourhood).
Podia has scraped the Word to the Wise blog and I’m currently receiving an ongoing drip campaign from them absolutely begging me to mention them in my blog post on cold emails.
I get maybe a dozen of this style of email a week. It’s pretty annoying but whatever. I delete them, blog about them or, very occasionally, share them with some folks who might have a big bigger of a stick to wave at them.
I have to admit, this time I spent about 30 seconds considering adding a note onto that article. A brilliant example of cold email that should go to the spam folder is from PodiaHQ, aka podia.com. My only hesitation is that gives them what they want, and antisocial behaviour should never be encouraged. Plus, then I’d have to actually think about something else to blog about today and it’s 4:30 already. Then I realised this is exactly the thing to illustrate how opens can hurt your delivery.
Wait. What? Opens don’t hurt delivery! An open is a positive signal, isn’t it? The user opened and read the mail this is good. Except…. when a user opens an email, gets half way through it and then immediately marks it as spam.
Using opens as a metric for who to continue mailing without also having FBLs to identify which of those opens resulted in a this is spam hit, leads to an increase in mail to folks who don’t want it and/or are receiving the message in their spamfolder because they marked the sender as spam. Longer term it can lead to reputation problems.
In the consumer context opens are a way for us to tell who is reading our mail. FBL messages are a way for us to remove anyone who doesn’t like that mail. By processing FBL complaints, folks who open the mail and then complain about it are removed from future mailings. We don’t end up with a build up of ‘engaged’ users who are not engaged at all.
The obvious exception to this is being Gmail as they don’t have an ARF style FBL. But even then, if you have a decent enough reputation Gmail will show the user a “do you want to unsubscribe, too” message. We can sorta wiggle around the lack of FBL data by treating unsubscribes through the List-Unsubscribe header as spam complaints.
That’s not how it works for B2B. There are no FBLs for business mail. Many business users do have a this-is-spam button, though. That this-is-spam button ties directly into their filtering system. What you end up with is an audience that opens a message and reports it as spam. That open is now a negative signal, not a positive one.
I think our spammer friends at Podia haven’t made the connection that their advice causes delivery problems. Or, maybe they have which is why they’re using podiahq.com in their emails instead of podia.com. Ironically, they’re not putting much effort into the subject line here. A few months ago I was toying with the idea of sharing all of the stupid B2B spam I get. I collected over 2 dozen cold outreach emails just by searching for the subject line ‘Quick Question’.
The broader picture here is that we can’t just look at metrics in isolation, particularly when we’re troubleshooting delivery. Only mailing engaged users, when you’re not also getting back complaint data, means some of the folks you’re mailing aren’t users who want your mail. At best they’re getting the mail in the spam folder due to ISP metrics. At worst the spam foldering isn’t working and they end up repeatedly reporting your mail as spam.
We make assumptions about what signals to measure and what they mean. In order to correctly model what’s happening with delivery we need to question those assumptions regularly.
As I continue to think about how people troubleshoot email delivery I keep finding other things to talk about. Today we’re going to talk about the question most folks start with when troubleshooting delivery. “Did ISP change something?”
At least once a week I check some delivery or email fora and some form of the question is sitting there.
“Did X change something? We haven’t done anything different and our delivery went way down overnight.”
Did Y change their filters? Our delivery is tanking and all our authentication is fine.”
Anyone hear of a change at Z? We have been having increasing difficulty reaching the inbox and we don’t understand why. Looking for suggestions.
In reality, the answer to this question Does Not Matter and asking it is only going to delay actually resolving your delivery issue.
When filters change
The reality is, filters are continually changing. ISPs and filtering companies are always tuning filters. These changes are roughly in 3 categories.
Ongoing tweaking and improvement to provide a better experience for their users
Specific changes to catch a type of spam they had previously been unable to effectively identify and filter.
Filters are not static. They are continually adjusting based on a number of things. We can always assume the answer to the question is yes. Something changed. Now what?
There are basically 3 situations here.
The filters did something unexpected and caught mail it wasn’t intended to catch, causing recipients to complain to the ISP.
The filter change was intentional but caught more mail than was intended, causing recipients to complain to the ISP.
The filter change was intentional and caught exactly the mail that was intended and the recipients didn’t care enough to notice that mail was missing.
In the first two cases, the ISP is going to fix things. They’re going to listen to their users and adjust the filters. In the first case, I expect to see changes and rollback within 24 – 48 hours. In the second, I expect to see changes in 24 – 96 hours.
The third case is the interesting one. Does anyone care about mail they don’t care about going to the bulk folder? Folks sending mail, even opt-in mail, that the users don’t complain about when it’s missing is the definition of grey mail. Filter maintainers listen to their users. If users complain they’ll change things, if users don’t complain they’ll assume the filters are working as intended.
The answer to the question did the filters changed tells you nothing. Of course the filters changed. Either they’re doing something that the maintainers don’t intend, which means they’ll be fixed or they’re catching mail they’re intended to catch.
Instead of asking if the filters changed, flip the question. Why are my users not interested enough in my mail to notice it when it’s gone? Start your troubleshooting from that perspective.
There are a lot of folks in the email industry that take issue with my stance that DMARC is not a viable solution to phishing. DMARC, at it’s absolute best, addresses one tiny, TINY piece of phishing.
Look at this message I received today. My mail client presents this as from Quickbooks and hides the actual from email address from me. Most mail clients do that by default. It is possible to change this in some clients, like desktop mail.app. But a lot of clients simply take the choice away from the user.
Mail clients are the biggest barrier to stopping phishing. As long as they hide the actual email address, users will be unable to tell when a message is actually phishing.