Ugh, I hate that goofy stock photo. Needles make me itch. But it's the best way to frame my concerns, I think. And I have concerns. Because domain reputation is a big deal of late. And I'm seeing people stumble into domain reputation issues -- and not necessarily realize it -- all because of domain sharing and shared reputation problems.
Where? Mostly at Gmail. Domain reputation is definitely a big deal for the biggest mailbox provider, and that is Gmail. (If you're a typical US B2C sender, the top three providers you're sending to are going to be Gmail, Yahoo and Microsoft OLC/Outlook.com, in that order. Gmail's going to be 60%+ of your list, probably.)
A Gmail mail rejection (NDR/bounce) like this specifically talks about domain reputation:
smtp;550 5.7.1 [x.xx.xx.xx] Our system has detected that this message is likely suspicious due to the very low reputation of the sending domain. To best protect our users from spam, the message has been blocked. Please visit https://support.google.com/mail/answer/188131 for more information. - gsmtp
smtp;550 5.7.1 [x.xx.xx.xx] Our system has detected that this message is likely unsolicited mail. To reduce the amount of spam sent to Gmail, this message has been blocked. Please visit https://support.google.com/mail/?p=UnsolicitedMessageError for more information. - gsmtp
It's not always clear if if blocking is due to a domain reputation issue, but I think it's almost fair at this point to start assuming that domain reputation is the problem unless proven otherwise. I've dealt with pretty significant "shared domain" blocking issues at Gmail myself. At first, I thought it was IP reputation related, but testing different IPs and domains convinced me otherwise. Don't assume it's an IP rep issue at Gmail, even if your bounce messages reference your sending IP address.
The problem, with any shared reputation or resource, is that even if you follow best practices, doing everything right -- high engagement, low complaints, properly authenticate everything, etc. -- you don't know about and don't have control over who else is using those same shared resources. Who else is using that same return-path/bounce domain or DKIM d= domain? (And reputation can attach to either or both!)
If you're a small sender (i.e. not sending enough volume to warrant a dedicated IP address), you've got no choice but to share sending IP addresses with others. ESPs often implement a "pool" of IP address and strategically assign outbound mail across IPs in the pool based on various criteria, to "balance" the volume of the shared IP pools for reasons of system load or sending reputation. This is fine and common, but it does mean that as far as IP reputation issues go, you're at the mercy of that provider. Do they monitor shared IPs for ISP deliverability issues? And if so, how do they remediate them? Do they notify clients of issues? These are all questions a savvy email marketing manager should be asking of their ESP or CRM email sending platform.
When it comes to domains, it's best handled a bit differently. You don't necessarily need to be sending a bunch of email messages to build up a reasonably good sending reputation. (You do still need to be careful of best practices; bad practices + very low volumes = spam folder placement forever.) It's not like IP reputation -- the volume requirements aren't as hard and fast. My point being that I don't think you should be sharing domains with others. Send with your own email domain. Make sure your DKIM signature is YOUR domain's signature (only, if possible). If your sending platform can customize the return-path (bounce) domain, DO IT! This is really important. For a platform meant for the tiniest of senders, it might not be possible (and that's OK). But for any platform who could have a significant mix of users with different email volume levels (and perhaps different send practices and different complaint rates), you've got a much better chance of success if you don't share that bounce domain with anyone else.
Because if you do share domains, you're sharing needles. Eventually somebody else will dirty that needle (domain) and pass some yucky problem along to you. And email deliverability success, and email marketing success, is already difficult enough to achieve without stumbling into inbox-preventing problems thanks to somebody else's bad act. Avoid it if you can.
Ugh, I hate that goofy stock photo. Needles make me itch. But it's the best way to frame my concerns, I think. And I have concerns. Because domain reputation is a big deal of late. And I'm seeing people stumble into domain reputation issues -- and not necessarily realize it -- all because of domain sharing and shared reputation problems.
Where? Mostly at Gmail. Domain reputation is definitely a big deal for the biggest mailbox provider, and that is Gmail. (If you're a typical US B2C sender, the top three providers you're sending to are going to be Gmail, Yahoo and Microsoft OLC/Outlook.com, in that order. Gmail's going to be 60%+ of your list, probably.)
A Gmail mail rejection (NDR/bounce) like this specifically talks about domain reputation:
But did you know, this different Gmail reject could be referring to domain reputation, too?
It's not always clear if if blocking is due to a domain reputation issue, but I think it's almost fair at this point to start assuming that domain reputation is the problem unless proven otherwise. I've dealt with pretty significant "shared domain" blocking issues at Gmail myself. At first, I thought it was IP reputation related, but testing different IPs and domains convinced me otherwise. Don't assume it's an IP rep issue at Gmail, even if your bounce messages reference your sending IP address.
The problem, with any shared reputation or resource, is that even if you follow best practices, doing everything right -- high engagement, low complaints, properly authenticate everything, etc. -- you don't know about and don't have control over who else is using those same shared resources. Who else is using that same return-path/bounce domain or DKIM d= domain? (And reputation can attach to either or both!)
If you're a small sender (i.e. not sending enough volume to warrant a dedicated IP address), you've got no choice but to share sending IP addresses with others. ESPs often implement a "pool" of IP address and strategically assign outbound mail across IPs in the pool based on various criteria, to "balance" the volume of the shared IP pools for reasons of system load or sending reputation. This is fine and common, but it does mean that as far as IP reputation issues go, you're at the mercy of that provider. Do they monitor shared IPs for ISP deliverability issues? And if so, how do they remediate them? Do they notify clients of issues? These are all questions a savvy email marketing manager should be asking of their ESP or CRM email sending platform.
When it comes to domains, it's best handled a bit differently. You don't necessarily need to be sending a bunch of email messages to build up a reasonably good sending reputation. (You do still need to be careful of best practices; bad practices + very low volumes = spam folder placement forever.) It's not like IP reputation -- the volume requirements aren't as hard and fast. My point being that I don't think you should be sharing domains with others. Send with your own email domain. Make sure your DKIM signature is YOUR domain's signature (only, if possible). If your sending platform can customize the return-path (bounce) domain, DO IT! This is really important. For a platform meant for the tiniest of senders, it might not be possible (and that's OK). But for any platform who could have a significant mix of users with different email volume levels (and perhaps different send practices and different complaint rates), you've got a much better chance of success if you don't share that bounce domain with anyone else.
Because if you do share domains, you're sharing needles. Eventually somebody else will dirty that needle (domain) and pass some yucky problem along to you. And email deliverability success, and email marketing success, is already difficult enough to achieve without stumbling into inbox-preventing problems thanks to somebody else's bad act. Avoid it if you can.
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.