Unverifiable email addresses aren’t as easy to navigate as they used to be.
We recently interviewed Rowland O’Connor, CEO of EmailHippo.com. He shared his thoughts on unverifiable email addresses, Microsoft 365, velocity-based email blasts, and more.
This post is based on his insight.
The Difficulty of Verifying B2B Emails
One of the most interesting things that came out of our interview was a major shift Rowland has seen in verifying emails. Traditionally, it’s been difficult to verify B2C. In the last few months, though, B2B has taken over as the far more difficult category.
What does Rowland attribute that to? It’s a very simple answer: Microsoft Office 365.
Office 365 has been aggressively marketed by Microsoft as a B2B solution for hosting your emails and your collaborative tools. Exchange has always been an issue for email verification, and it’s now finding its way into the cloud infrastructure. The adoption has increased and anti-spam has improved as well on Office 365, which makes EmailHippo’s job harder.
"The reality of the email system does not match the theory." - Rowland O'Connor
What’s the actual problem?
So Office 365 has made filters harder to get through. But does it make delivery responses harder to interpret, or do they just not respond?
The answer ties in well with our topic of unverifiable emails. Office 365 behaves in one of two ways:
1) It gives an absolute, definite answer on whether an email address is OK or not.
2) It comes back and says “unverifiable” as a catchall.
Yet, the catchall disposition that comes back is not actually catchall. With a traditional catchall address, if you send an email to it you can expect it to be received. With Office 365, in the last 18 months or so, dispositions reported as catchalls actually come back as hard bounces. But it’s not consistent across the Office 365 domain.
This is a big issue for a lot of industries, particularly for lead gen. If you’re selling lead gen data, and you’re advising a client that this is a catchall address, the client goes ahead and sends it and they’re going to be rightly surprised to get a hard bounce.
Let’s flip this catchall risk on its ahead a little.
A lead gen customer says, “I don’t want bounces.” They also don’t want traps, right? So if it’s a real catchall, the mail is routed somewhere, maybe to someone managing firewall filters or a blacklist they could put you on, and all those kinds of things.
How do we balance this? Throwing away a tremendous amount of perfectly good data at domains that are really configured at catchalls? We can’t root them out with actual mailing in a big environment. Do those records have to stay in “maybe”s forever?
Rowland has been doing this a number of years, and picked up on two things:
1. The email system, in theory, should be a closed-loop system. By that I mean when you send an email, there’s a transaction. It’s either going to be delivered or not delivered. If it’s not delivered, you should expect some sort of notification, hard or soft bounce.
In reality, it doesn’t work that way. When you send an email, it’s either going to be delivered or end up in somebody’s spam box or in front of some algorithm or person for review. The reality of the email system does not match the theory.
2. What you can do with that knowledge is adopt some good practices with email campaigns. You can call it “stacking the odds in your favor,” because this is a game of probability and risk. EmailHippo believes in good email practices, which includes looking at the data, looking at which proponents of those are permission-based, and practicing good list hygiene—in other words, the basics.
But there’s another dimension to this. One of the major signals for whether email systems are going to drop your message in the trash is the speed at which you’re doing things. If you’ve got a list of a few hundred thousand emails and you’re looking to blast that out over a short space of time, there’s a high chance a lot of that will end up in junk.
When you’re doing bulk emailing, you want to avoid coming to the party and flagging messages onto a DNS blocklist like Spamhaus. That’s a whole separate proposition. You don’t want to get yourself a bad reputation in terms of IP or domain in Spamhaus. That affects your ability to send emails anywhere.
A lot of that, again, is velocity-based.
How should you categorize groups of email?
At EMM, we’re starting a new program. We’ve got everything in the top of the bucket as either a successful delivery or a “ping pass”: a free and clear pass, no argument about it. This is the closed-loop world.
Down in group B, there are more ambiguous responses. Then in C, unverified. Then in D, suggested deletions. Should there be more?
A lot of Email Hippo customers are in that best group. If you look at one of the fundamental use cases for this type of technology, to be able to use a third-party email service provider, those guys are completely risk-averse to their infrastructure. As a customer, you have to come to these ESPs with a clean list, and not a “maybe clean” list.
“You need an ancillary source of confirming data outside of using a mailbox ping or sending mail.” - Rick Holmes"
What do you do with that gray area? You can subcategorize them, certainly. What you don’t want to do is discard valuable data simply because you can’t do a verification on it.
The universal solution is to figure out some sort of data enrichment. So you’re looking at other signals as well as email addresses to confirm whether that’s a person at the end of the wire.
If you don’t use iTunes, you can listen to every episode here.