Engagement drives deliverability

Return Path released an white paper today offering the Secrets of Successful Senders. I don’t think any of my readers will be surprised that it boils down to identity, reputation, and engagement. Return Path treats these as separate things and I understand why they do. I think however, that the identity and reputation are supporting players to the overarching issue of engagement.

When I’m dealing with clients and troubleshooting deliverability problems and offering solutions, I focus on the root cause. To me the root cause is almost always a data problem. Either there’s a problem with data collection or there’s a problem with data maintenance. These problems result in mail going to people who don’t really want or care about it.
Yes, identity is important. But, realistically, anyone mailing through a decent ESP has SPF and DKIM in place, at least on some level. There may be better ways to authenticate, but the boxes are checked.
Yes, reputation is important. But here’s the thing, reputation just means that the ISP knows how users are going to react to an email. Reputation isn’t some nebulous concept made up by ISPs. It’s an actual measurement. It quantifies the history of an IP or a domain or a mail stream and says we know that this IP sends wanted mail. We know that this domain sends mail our users ignore. It’s a history. Past performance does indicate future results.
Identity says who a sender is. Reputation tells us that sender’s history of sending. Those are the two factors that enable ISPs to make delivery decisions. Mail comes in and the ISP looks at it. They use identity to determine what reputation to assign to a mail. Reputation drives delivery, whether into the inbox or the bulk folder.
 

Engagement is the key

All of the various metrics we use are proxies for engagement. High levels of complaints tell us users don’t like the mail. Low levels of opens tells us they don’t care enough to read it. Excessive bounce rates tell us that our data collection process is poor.
I see too many deliverability consultants and experts suggest that the fix is to make the numbers look better. Lower overall bounces using a list hygiene company. Remove complainers by using multiple ESPs. Use gimmicky subject lines to get recipients to open. These processes will sometimes fix delivery in the short term. They’re a solution in specific cases, and typically work for companies with high brand recognition and a core of engaged users.
For companies without a core of engaged users, however, all they end up with is a list that has low bounces, low complaints and erratic deliverability. They don’t know how to address the problem because all they’ve done is hide the symptoms.
If I take aspirin for a fever, I haven’t cured the flu. I have just lowered my fever. If I use a list cleaning service to remove bounces, I haven’t suddenly found a list of engaged users. I’ve just lowered my bounce rates.

Why purchased lists don’t work

Lack of engagement is the underlying reason purchased lists don’t work. Companies sending to purchased lists have identity. Sometimes, they even have a decent reputation built on the back of actual opt-in emails. What they don’t have is engagement. The majority of recipients don’t really care about the mail, so they aren’t engaged. Therefore the messages never make it to the inboxes.
The dirty little secret of list sellers is they work very hard to remove negative signals from their product. They’ll remove bouncing addresses, they’ll even try to remove users that will complain about the mail. The measurements say this is a “good” list, but it’s lacking one thing. The recipients on that list don’t necessarily want mail from the final purchaser.

Putting it together

Yes, identity is important. It’s how the filters know what the mail’s reputation is. Good reputation is important, but the only way to build a good reputation is send mail that’s wanted. How do ISPs know what mail is wanted? Their users tell them so.
Engagement is the root of all deliverability. Everything else just makes it easier for filters to see the engagement.
 

Related Posts

Domain Assurance by Return Path

As often happens during MAAWG, email companies are announcing new products. One of the interesting ones is the new Domain Assurance product from Return Path.

Read More

You're kidding me

All the authentication and DMARC in the world can’t save you from stupid.
I just got a survey request from my bank. Or, at least, it claimed to be from my bank.

Read More

Are they using DKIM?

It’s easy to tell if a domain is using SPF – look up the TXT record for the domain and see if any of them begin with “v=spf1”. If one does, they’re using SPF. If none do, they’re not. (If more than one does? They’re publishing invalid SPF.)
AOL are publishing SPF. Geocities aren’t.
For DKIM it’s harder, as a DKIM key isn’t published at a well-known place in DNS. Instead, each signed email includes a “selector” and you look up a record by combining that selector with the fixed string “._domainkey.” and the domain.
If you have DKIM-signed mail from them then you can find the selector (s=) in the DKIM-Signature header and look up the key. For example, Amazon are using a selector of “taugkdi5ljtmsua4uibbmo5mda3r2q3v”, so I can look up TXT records for “taugkdi5ljtmsua4uibbmo5mda3r2q3v._domainkey.amazon.com“, see that there’s a TXT record returned and know there’s a DKIM key.
That’s a particularly obscure selector, probably one they’re using to track DKIM lookups to the user the mail was sent to, but even if a company is using a selector like “jun2016” you’re unlikely to be able to guess it.
But there’s a detail in the DNS spec that says that if a hostname exists, meaning it’s in DNS, then all the hostnames “above” it in the DNS tree also exist (even if there are no DNS records for them). So if anything,_domainkey.example.com exists in DNS, so does _domainkey.example.com. And, conversely, if _domainkey.example.com doesn’t exist, no subdomain of it exists either.
What does it mean for a hostname to exist in DNS? That’s defined by the two most common responses you get to a DNS query.
One is “NOERROR” – it means that the hostname you asked about exists, even if there are no resource records returned for the particular record type you asked about.
The other is “NXDOMAIN” – it means that the hostname you asked about doesn’t exist, for any record type.
So if you look up _domainkey.aol.com you’ll see a “NOERROR” response, and know that AOL have published DKIM public keys and so are probably using DKIM.
(This is where Steve tries to find a domain that isn’t publishing DKIM keys … Ah! Al’s blog!)
If you look up _domainkey.spamresource.com you’ll see an “NXDOMAIN” response, so you know Al isn’t publishing any DKIM public keys, so isn’t sending any DKIM signed mail using that domain.
This isn’t 100% reliable, unfortunately. Some nameservers will (wrongly) return an NXDOMAIN even if there are subdomains, so you might sometimes get an NXDOMAIN even for a domain that is publishing DKIM. shrug
Sometimes you’ll see an actual TXT record in response – e.g. Yahoo or EBay – that’s detritus left over from the days of DomainKeys, a DomainKeys policy record, and it means nothing today.

Read More