[hemancuso]

Projects like this seem like a great idea, but deliverability seems like a big concern that is hard to measure unless you have a reasonable amount of experience.

What are best practices for using/selecting an ESP if you were to use a project like this and want to ensure reasonable deliverability?

[knadh]

Author here. We've been using listmonk in production at our company (regulated financial business) to deliver e-mail updates including regulatory ones for over 6 months. We host our own SMTP instances using Postal[1] on EC2 instances and have never had any issues with deliverability. If it's legitimate e-mail, I don't think it's much of an issue.

PS: Postal SMTP is awesome.

[1] https://github.com/atech/postal

[rolltiide]

> If it's legitimate e-mail, I don't think it's much of an issue.

starting to sound hopelessly naive

you deliver email updates to fund LPs that aren't unilaterally marking you as spam for no reason

[0xffff2]

>that aren't unilaterally marking you as spam for no reason

This sounds hopelessly naive to me. If the receiver marks it as spam, it's spam. By definition. Work harder to only send emails to people who want them.

[rolltiide]

> If the receiver marks it as spam, it's spam. By definition.

but that shouldn't effect the deliverability to everyone else, but thats a reality which has its own problem and has its own countermeasures.

when people asked OP if they had a solution to this, they hand waived it away. all closed sourced mailing list clients have solutions for this.

but anyway since somehow it is 2019 and people want to act like its 2009 on this matter I'll just skip ahead to echo the productive answer someone else left:

this could probably be run through Amazon SES with their DKIM settings

[cat199]

Really?

Spam is unsolicited commercial email.

if I sign up on a site, click the 'yes email me' button, and then mark the email as spam when I get it, I am the one acting incorrectly, not the sender who is literally doing what I instructed them to do..

[MisterBastahrd]

Sure, but the end user is going to do whatever is most convenient for them.

Unsubscribing from email lists can be cumbersome and non-uniform, which is usually why people just hit that spam button instead. It always provides them a uniform interface and largely achieves the same goal from their perspective.

[webbie917]

Actually, cold emails (without permission) aren't spam. What makes an email spam is: 1) misleading subject line 2) misleading message 3) lack of simple (not requiring login or extra steps) unsubscribe link, and a couple other factors.

People forget subscribing and hit "Spam", which has an impact on the sender reputation and affects future deliverability for that sender.

[thedufer]

That's a very narrow definition of spam that you're only going to hear from spammers (your profile is utterly unsurprising after reading this comment). Unfortunately for you, end-users are going to mark as spam based on their own much more reasonable definition.

[massaman_yams]

The other comments here don't quite tell the whole story; "I never had any problems" is anecdotal - there are plenty of legitimate senders who do run into deliverability issues.

Using an ESP will generally simplify the amount of work necessary to achieve good delivery, but due to the complexities of domain reputation and fingerprinting, very occasionally they can also be the cause of delivery problems.

General guidelines:

- It's a bit harder to predict how deliverability will turn out at smaller ESPs, vs. well-established ones like Sendgrid, SES, Mailgun, and perhaps Mailchimp.

- DKIM, SPF, DMARC (p=none is fine to start; gmail has a guide for deploying dmarc https://support.google.com/a/answer/2466563)

- Use the same root domain everywhere within your email: From, Return-Path, DKIM signature headers; URLs for links and images in the message body. (Separate subdomains are fine, e.g., img.example.com, bounce.example.com)

- Having your sending domain show up in third party email can cause problems. Try to avoid it if possible; use a separate domain as a last resort.

- Send consistently. Some variation in sending patterns will be tolerated, but you'll probably have trouble if you send 500 messages a day most of the time, then once a month you send 100,000 messages.

- Consider a dedicated IP if you're sending over 50,000-ish messages a month.

- You may want to split up transactional email from marketing, sending these from separate IPs and/or subdomains.

- Finally, make sure you're sending email your recipients find valuable and are interested in receiving. Too much disinterest/disengagement can cause delivery issues.

[webbie917]

I agree with all your suggestions, but want to expand on a couple points: 1) The shared IP pool at cheaper providers like Sendgrid, SES, and MailGun will have lower reputation versus a platform with a guarded (via cost, but also on-boarding mechanisms) platforms like MailChimp, simply due to customer pool and quality of emails sent. I have been hearing from my (BigMailer.io) customers about having deliverability issues with platforms like SendInBlue and MailGun frequently in the last year or so. 2) If the bulk sending practices are healthy and engagement is good, then it's better to use the same sender/domain for both bulk and transactional email.

I would recommend to NOT send different email types from different providers, like use SendGrid or SES for transactional emails and then some other platform for marketing emails, especially using the same sender domain. That's because email header signature and tracking links will be different and email box providers like Gmail can find it suspicious and send emails to Spam. And then there is the issue of processing and syncing bounces/unsubscribes/complaints data.

Keeping all email campaign types in a single platform allows for centralized processing of bounces/unsubscribes/complaints date and protects future campaign engagement + sender reputation.

[massaman_yams]

Right. Split up by IP/subdomain if possible, preferably within one provider.

That said, you may be surprised by the number of large organizations that have a dozen or more services that send mail on their behalf, for various different purposes... it's not optimal, from a deliverability perspective, but it's also not usually going to cause deliverability issues by itself as long as everything else is in order.

[webbie917]

Yes, agreed. Lotsa factors in play when it comes to deliverability, like a puzzle. What a well established brand (with high quality emails) can get away with isn't something that businesses with less resources should try to copy though IMO.

Just saw an email from Starbucks in the spam folder - all because of a few words that no doubt triggered the spam filter.

[PatrolX]

Deliverability is a non-issue if you hook tools like this and Sendy up to Amazon SES with DKIM and verified MAIL FROM settings. I've been doing it for years and never once had a deliverability issue. I've also sent directly from EC2 instances without issues but SES is so cheap and reliable I've stuck with it.

[webbie917]

Sounds like you have a good and established sender reputation, which is a big factor. When people start fresh (new sender identity) they tend to run into deliverability issues.

Also, the quality and size of the starting list matters too because a large list (like the OPs) or unengaged list can have a high bounce and low engagement rate, which factors into future deliverability.

[dvtrn]

I wonder if orgs using gApps can use it as an SMTP relay as a possible solution. My team did this (except we used our Office365 as a relay) when one of our clients brought in a new firewall and found that password reset emails were being blocked coming out of AWS.

Now before you mention how this should be a solveable problem inn AWS, we’re already well underway testing with the client. The problem presented itself as a manifestation of inheriting the last guy’s infrastructure and working to...unfuck a lot of his questionable design choices.