Recipient
Doing email right
Over on the MarketingLand website, Len Shneyder talks about 3 companies (Uber, REI and eBay) that do email right. In there he shows how the companies use email to further their business goals while understanding and meeting the needs of their customers.
Meeting the needs of recipients is the way to get your mail to the inbox. Send email that your users want, and they will tell the ISPs when they don’t get your mail. It’s sometimes hard to convince senders of this. Instead they want to tweak URLs or authentication or IPs or domains. But none of those things are what deliverability is all about. Deliverability is about the recipient. Deliverability is about the relationship between the sender and recipient.
Send to the right people – and the right people are those who have asked for and want your mail – and deliverability problems don’t materialize. Sure, every once in a while something might happen that throws mail into the bulk folder for one reason or another. But fighting to get to the inbox isn’t an every day thing. Instead, senders can focus on knowing their users and sending mail that makes them happy when it shows up in the inbox.
The long tail of domains
I frequently get clients telling me that they have about 15 (20, 30) major domains on their list, and then a long tail of domains with only a couple of recipients. If you sort simply by the left hand side of the @, that’s true.
When you’re sending email, it’s not just the domain in the email address that is important. Of equal importance is the MX. The MX is what actually handles the mail and where many filters are applied. Sorting by MX, instead of simply recipient domain, can identify that most of your small business clients are hosted at a particular provider. The number of subscribers behind that filter may be enough to push that filter into your top 10 or even top 5 recipient domains.
There’s a much smaller tail when grouping recipients by MX domain. It makes it much easier to understand where blocks are happening. I have even seen cases where clients didn’t realize they were blocked at a commercial provider because they only saw the “onesie twosie” domains as undeliverable. They missed a real problem with blocking because they were looking at the wrong data.
I sometimes get the side eye from some ISP folks if I use the term receiver (because, well, they’re senders as much as they are receivers). But I use receiver to help distinguish between the recipient domain and the actual domain handling the email.
When was the last time you looked at your delivery by filter or MX rather than by recipient domain? What did you find?
IP Address reputation primer
There has been a lot of recent discussion and questions about reputation, content and delivery. I started to answer some of them, and then realized there weren’t any basic reference documents I could refer to when explaining the interaction. So I decided to write some.
This first post is about IP address reputation with some background on why IPs are so important and why ISPs focus so heavily on the sending IP.
Denial
I come up against a lot of denial when talking with people about spam and email. It makes sense, nobody likes spam. Nobody wants to send spam. And I do understand the initial denial when they hear “you’re mail looks like spam” or “you spammed me.”
It often takes overwhelming evidence to convince some senders that their mail is spam. I’ve talked before about some of my clients who insist that I just “forgot” I signed up for their mail. But these aren’t the only excuses I hear.
A sender that denies all feedback about their mailing program isn’t a very good sender, though. The best thing any sender can do when faced with information is to think about why a recipient might not want their mail.
I often describe my role as a translator between marketers and IT folks. I can translate technology to marketing and back again. One of my other major roles, though, is translating uncomfortable or unwelcome recipient feedback. Many marketing programs have been significantly improved because the program maintainers took a minute to look at the feedback and use it.