HelloInbox – Ultimate email deliverability checklist and toolkit
helloinbox.email
helloinbox.email
If you haven't ensured people have signed up themselves and using dual opt-in then the list is pretty much useless and should not be used. Any serious ESP will suspend accounts of customers sending mails to purchased lists.
However most ESPs won't block you unless it has an impact on them, they're getting paid per email sent, spam or not.
In that, I focus on what you might call ethics. But as for the legality aspect:
Through most of the civilised world (at a minimum, those that I know of definitely: AU, NZ, all EU, UK, CA), sending unsolicited commercial messages at all is illegal, with very little in the way of exception or subtlety. The USA’s CAN-SPAM Act is the outlier, unusually permissive, by being largely opt-out rather than opt-in like everyone else. (And frankly it’s not at all uncommon for the USA to be an outlier in a bad way among first-world countries.)
And taking the legality aspects further, it’s common for people to ignore restrictive laws that aren’t being particularly seriously enforced, and spam legislation is often like that around the globe. Just because lots of people are doing it doesn’t even mean it’s legal.
For example, the ICO (UK) has the following to say:
You must be very careful before using bought-in lists for recorded calls, texts or emails. You can only use them if all the people on the list specifically consented to receive that type of message from you. Generic consent covering any third party will not be enough.[1]
[1] https://ico.org.uk/for-organisations/guide-to-pecr/electroni...
If you use a purchased list and end up getting a bunch of spam complaints, and you tell your ESP you bought the list, then I promise you they won't be very happy.
> The simplest definition of spam is unsolicited email.
It's not just Europe that you'll get called on this.
"Helloinbox" should have an option to specify a DKIM selector.
It is not correct to only check for a "default" DKIM selector, since any other selector is just as valid as "default", which in turn means the guide should also be updated to reflect this.
Frustrated with low open rates, I deep dived into email deliverability and discovered a lot I didn't know (and I'm in tech). Fixed and tested everything and tripled my open rates to 65-80%.
As a side-project I decided to build a free checklist and toolkit for others to follow. My goal is to reduce complexity as much as possible and I think I've done to a degree but there's still a lot work to be done especially for people who aren't as tech savvy.
If you think this can or cannot help you, please let me know, I'd like to know why.
Unless you're willing to out in the work, I wouldn't recommend hosting your own mail server.
Not affiliated at all, just a happy user.
Then there's the fact that a lot of people sign up for a lot of bacon, then get angry about receiving it.
A lot of the tricky stuff is trying to make the email seem unobtrusive and make the opt-out clear so that if people don't want them, they opt-out instead of reporting spam but a lot of marketing teams still think size of audience is all important rather than quality and don't want their list size to go down by offering easy opt-outs.
I was told anything under 500,000+ emails per month and you might actually get worse deliverability from a dedicated IP vs. a shared IP at one of the big ESPs like mailchimp…since inbox providers like gmail/outlook see low volume IPs as suspicious (no idea why).
I’ve also heard your domain reputation is far more important than shared vs. dedicated IP at your ESP of choice.
Anybody know which advice is true?
For me the IP address has been the only significant factor in my email deliverability. I.e., emails sent from my mail server couldn't reach Outlook inboxes or even spam boxes. Straight-up silently rejected every time. If you look at the Outlook.com Smart Network Data Services (SNDS)[0], the terminology used is all about IP. That problem was resolved through a support ticket requesting a kind conditional white-listing.
That's been my experience so far, from the perspective of a low volume, personal email only. YMMV.
That being said if you send from a new or rarely used IP, every inbox provider will greylist you at a minimum, which causes delays.
Why? Because these emails are super important transactional notifications and we constantly saw stuff getting blocked on shared IPs. It would work fine for a while then get RBLd causing major major issues.
Sendgrid, sparkpost etc support all said the only solution was a dedicated IP with them. This does seem to work FWIW, but it's probably working out the same cost per send as sending a physical letter at this point!
I guess mail delivery is just hard regardless of whether you are hosting it yourself or using a commercial relay service.
So while a relay might say you have 99% delivery rate, the actual number might be closer to 90% and you would never know unless your customers complain about missing emails.
Huh are people really getting such numbers? (Let alone 20,000 emails per hour)
I’ve got a cabinet in a data center and an IP block, but I’ve been using gsuite for years because I assumed that >1 email/hour would result in >1% of my sent mail getting incorrectly flagged as spam. Is that not the case?
Other scenario is a business that wants to invite a load of people to something at the same time so they are not sending that many every hour but e.g. tickets for a concert, you want everyone to get the same chance.
Exactly the thing nobody asked for and absolutely deserves to be marked as spam.
At 9am on a Monday we send roughly 100k emails via Sendgrid and have very very low spam report rates. Transactional email for even relatively small SaaS companies can get high very quickly.
As much as us in the dev world rely on Slack and try to avoid notification overload, my experience is most people want things as an email.