MailChimp vs. Amazon SES – How I Reduced My Monthly Bill
coursetro.com
coursetro.com
I have built the tech for an ecommerce startup (https://www.article.com) from scratch. Using different services for transactional and marketing emails is probably one the best decision i made early on.
Pro Tip #1:
"Use a different domain name for the from address while sending out marketing emails"
For example if your primary domain is example.com. Use support@example.com as your from address in transactional emails. Use support@example-mail.com as your from address in your marketing emails. Off course forward all emails received by support@example-mail.com to support@example.com (Why? see Pro Tip #2).
Pro Tip #2:
"Never use fake emails like do-not-reply@example.com for the from address for any email you sent. Yes not even for marketing emails"
You will be surprised how many time customer just reply to emails they have received even if it is an unrelated marketing email. You will regularly see customers receiving a monthly newsletter and they will hit reply asking "Can you change the shipping address on my order?"
Is this really beneficial? With all the domain-spoofing going on I would not click a single link in an email from a domain I have never visited.
Mailchimp isn't spam-free but it stops the spammer hitting you straight away and has human follow-up for problem cases. If that increases the price of sending mail, so be it.
(Apparently notifying someone they are in debt counts as spam to some)
I would love to understand better how to deal with it - and if there's a fellow HN user who understand the debt collector business, I would like to talk to them :)
>code4tee: The bit about calmly but methodically collecting a paper trail and then reading it back to them is excellent advice
http://www.kalzumeus.com/2017/09/09/identity-theft-credit-re...
Usually it's because one of our client's payment gateways is terrible and doesn't record all payments.
Really? My attempts to get unsubscribed from a mailchip spam list were largely unsuccessful until I spammed as many mailchimp employees as I could find on LinkedIn. Mailchip offers zero support for those on the receiving end of their garbage.
Honestly, the most absurd part is that mailchimp is opt-out by default. I never once got any sort of "verify you'd like to receive messages from this sender" sort of e-mail address. Obviously mailchimp has no incentive to make their delivery opt-in because it would cut down on the number of messages delivered.
And, yes, you're right most of the alternatives are just as bad (e.g. Google, Sendgrid) from an end user point-of-view. I've had no regrets about blocking sendgrid and mailchimp.
Self-hosting my mail stuff means I'd see if I were bouncing legit email pretty easily.
I normally use the link in the X-Report-Abuse header. I invariably get an automated reply immediately (so if this isn't happening for you something must be going wrong; this seems to have been introduced about a year ago).
This is followed by what appears to be a semi-automated response (it varies depending on outcome but the text is usually made up of mostly the same content). I've had human responses from replying to that. (Though there is rarely the need—the initial complaint seems consistently to remove the complaining address from the mailing list, so that campaign stops unless the spammer manually adds the address back. Why doesn't everyone do this? It seems pretty obvious.)
I've also blocked Sendgrid as, despite the occasional response from their abuse contacts, the campaign doesn't stop coming. (I can't get away with blocking Mailchimp in any case as I have users relying on legit mailing lists that use it.)
> the most absurd part is that mailchimp is opt-out by default
I think this is understandable in terms of customers wanting to move mailing lists from one ESP to another without having to re-opt-in every subscriber. I wish there were a better way to manage permissions for mail receipt, but the SMTP infrastructure is made largely of despair and tears.
I'm not saying a company is better just because they are more expensive, but I will argue you get what you pay for in this industry.
There was an entire team called "ISP relations" whose sole job was to work with big ISPs when one of our IPs get blacklisted.
There was another team that would interview customers after their sending passed a certain threshold to see if they were following best practices. They would ask questions like
* How did you collect your e-mail list? * Did your users give explicit approval to receive list e-mails? * Did you acquire this list indirectly, from another company/campaign? (big no-no).
Usually everything was fine, or the customer didn't know they were doing something wrong, and they corrected it. But not infrequently a customer (who pays a decent chunk of money/month) would be told they can no longer use the product. Besides it being the "right thing" to do, having recipients block or report spammy senders worsens the reputation of IP addresses.
An interesting exercise would be to calculate the number of man-hours put into maintaining the reputation of each IP address.
If you are comfortable setting up your own templates it does a great job sending and handling unsubscribes/statistics. It isn't simply hooked into the SES SMTP , it fully utilizes the AWS API. Sendy iteself has a simple api to add users to lists and do other common things. I've used it for years.
>jmhobbs: The Sendy codebase is horrifying.
We use Sendy at work, 40k+ sends weekly. It saves us boat loads of money since moving from Mailchimp.
We've forked it, patched it, and use it internally, but only because it's cheaper than writing our own, for now.
I'm not telling you not to buy it, I'm telling you that the guts are shitty and you should know that before you fork over cash
There have been a couple of bugs that caused me to have to dig into the source code - which as others have stated, is a mess. Though I suspect its been purposely obfuscated to prevent pirating.
If you ever wonder what's going on in functions.php, I've unwound it a bit - you can see its making a phone home:
https://gist.github.com/anonymous/cb21dfc35e1d4b74e136ebc694...
Shameless plug: I run https://mailblast.io, a hosted email marketing solution powered by Amazon SES.
Years ago we started with AWS SES. The pricing was amazing but there was no useful customer service outlet. If you were sending via a blacklisted IP it could be weeks before you we're seeing inboxes reliability again. It wasn't uncommon for us to devote 20+ man hours per week in dealing with email issues while using AWS.
Next we moved to MailGun. This was a HUGE improvement, however we were having to request to be moved to 'non-blacklisted' ip's on a regular basis. The pricing was great, but we were still having to invest too many hours dealing with email problems. Mostly fielding 'here is why your emails went to the spam filter, or why they never showed up' questions from our customers. You shouldn't need a template explaining to your customers why emails are showing up in spam boxes!
To be fair, MailGun was fairly new at this point but they were VERY responsive. IP's that had been blacklisted did not stay that way for long.
Lastly we moved to PostmarkApp. They were by far the most expensive ($1.50 per 1000 emails) but I only now even think of emails maybe once or twice per month. Emails just get through, no spam lists, no outages, no carrier blocks, it's amazing. Also, if you do send with enough volume you can drastically reduce the price. I believe we pay about $0.25 per thousand emails now that we purchase 5 million at a time.
They could triple their price and I would eat the costs.
I'm not affiliated with anyone above.
It is the most expensive service if you don't buy in bulk, but is well worth if you want to stop worrying on blacklists and other delivery problems.
With that volume, wouldn't a dedicated Mailgun IP have been worthwhile? You've got enough mail to gain reputation on it, and the flat fee + lower per-email charges could match or be cheaper than Postmark.
Long-time Mailgun user here, but not affiliated with anyone either.
For now though we couldn't possibly be happier and would gladly continue using Postmark even if they dropped the bulk discount rates.
That's for sure. SES only has 1 feature in common with Mailchimp and that is the sending of an email. Mailchimp's primary function is managing distribution lists, email templates and receiver activity analytics.
So, a more accurate title would have been, MailChimp vs. SES + Mailwizz. ;)
But it looks like it doesn't, and it is worth paying $240/mo (or whatever my MailChimp bill is) just for that functionality.
Paying for Mailchimp a small fortune is like paying for bottled water where all you need is $15/year Brita filter and just drink tap water.
Nowadays all major email providers are really good at catching spam. If you are NOT spamming then you are good to go; the key is to start small and grow from there. Do not switch overnight and send 10,000 genuine emails letting your audience know your terms of service have changed; since they don't know your IP, they will consider spam. But if you are getting your newly subscribed audience into getting emails (confirm double opt-in) from your new IP, it will take you 2 months and approx +10% daily raise in sendout to get to $1MM emails per week from your OWN IP at $5/month rate and delivery rate will be similar to those big guys that claim they have the best delivery rate (noone can guarantee you that)! Tested and confirmed!
Don't forget to setup DKIM, SPF, PTR Records, etc!
We want to offload, at the very least, the sending onto a third party service where our delivery rates won't be so bad. The trick here is that we send the newsletters on behalf of clients that we have built sites for since we launched our newsletter service and they currently send with a FROM and a REPLY-TO of the domain we are sending for. Obviously, this does not mesh well with current spam practices. Third party services usually require you to verify the domain, but the vast majority of our clients do not have access to anything related to their domain or DNS and it's not realistic to move to SES, MailChimp, SendGrid, etc for that reason.
Does anyone have any suggestions for how to approach fixing this? I've already asked about sending out from client-name@ourdomain.com and having a reply-to of the client's email address, but was shot down for apparent contractual reasons.
>Third party services usually require you to verify the domain, but the vast majority of our clients do not have access to anything related to their domain or DNS
Do you see the contradiction here?
If you are sending it from your domain there is no issue migrating to mailchimp.
10 years ago, that passed. Nowadays, it's unacceptable. I'm wondering if anyone has a solution that doesn't involve any DNS changes for the clients we are spoofing, because it just won't happen, unfortunately. Our entire newsletter is built upon email spoofing, which is a terrible practice but I cannot get management to allocate any more resources to fixing it than "just make it work again". I'm going to try to push sending out from our (verified) domain again using SMTP (so we keep our system other than the sending part), but I'm doubtful I will get the approval for that.
I see the contradiction and realize that the verification process is in place for an extremely good reason, but actually implementing a fix is not as simple as you would hope. I was just hoping for someone to have an idea that I had not already thought of.
How could they not have access to a service that they pay for?
It sounds like you have a human problem on your hands, not a technical one. I would think about how to get an updated SPF into their DNS. If the boss said "just make it work" then to me that means to call the clients and hand hold them through figuring out who hosts their DNS records and how to open a support ticket or reset their self-service web portal login password, or whatever else the client needs to do to get those records in there.
SPF is very easy to configure and will improve your deliverability significantly. After you configure SPF, mail servers will acknowledge your servers as a valid sender for your client domain. It will no longer be spoofing. The only difference between spoofing and not spoofing is domain validation.
DKIM is not tied to an IP address but the 2 extra steps of complexity involved with DKIM have allowed for SPF to be the dominant domain verification method for sending email.
Exactly my point
Generally, they are on autopay and haven't had to sign in for several years. We often run into an issue where the person who set it up is no longer with the company and they no longer have the associated email address set up, so they can't do a password reset (without setting up the email, at least, which means hunting down how to do that; we're talking <5 person companies that haven't had a new employee in years)
> It sounds like you have a human problem on your hands, not a technical one.
This is definitely the problem. :/
The world changes, and adaptation requires maintenance. 10 years ago is almost half the age of the web ago. This is more a business decision - do you let those accounts rot - than it is a technical decision. Because the business decision needs to include support time for user interaction.
Not always easy to fix the human side.
Can you even get emails to Yahoo addresses?
However, you can still pass SPF and DKIM checks by using your own domain, which involves taking advantage of SMTP's envelope sender address. This can get you acceptable deliverability, assuming good IP, non-spammy content, low volume sending, bounce management etc.
There's a pretty good StackExchange answer here that explains the differences between SMTP envelope and message aspects in more detail: https://security.stackexchange.com/questions/30732/why-is-it....
There's also a good MSDN blog post series on the various email authentication techniques and how to get them working: https://blogs.msdn.microsoft.com/tzink/2013/04/24/how-to-set...
The gist: set up an address, and SPF and DKIM on a domain you control, and use that address as the SMTP envelope sender. Then "spoof" the FROM header.
The caveats: this technique is still used by some spammers; some clients will display "From: (your domain email) on behalf of (actual sender)"; some MTAs use SenderID which applies SPF to the FROM header's domain; some (but not most) providers almost need DMARC to get bulk email to the inbox nowadays.
If it is indeed his own machine, I wonder if he has factored in the data transfer costs to/from AWS. If he had an EC2 instance fired up, then the data transfer is free, however there is the monthly cost of the instance to consider.
Also, what about the stack that Mailwizz runs on? It it available as a simple turn key virtual or docker setup, or do we need to install a LAMP stack etc. to get it running? Time to get the stack running (and maintaining it to keep running) should also be factored into the $54 licence cost of the software.
Furthermore, only transfer out of AWS is billed; there's no cost to upload, which is what I imagine would be the bulk of the work.
Or perhaps he already has his own web infrastructure not on AWS that contains the list.
Amazon say SORBS is worthless but unfortunately someone is still using them https://docs.aws.amazon.com/ses/latest/DeveloperGuide/blackl...
http://docs.aws.amazon.com/ses/latest/DeveloperGuide/dedicat...
I've had zero problems with Sendy and SES on my platform over the past 2 years.
I'm not affiliated with them, but might be their biggest fan.
[1]: http://sendy.co/
https://www.reddit.com/r/startups/comments/3jnxep/good_ridda...
https://aws.amazon.com/about-aws/whats-new/2017/10/amazon-se...
https://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-p...
Side story: At the former job, we used to create transactional emails with a marketing swing to them in Mailchimp. Marketing loved it! Then we'd copy and paste the HTML to our ratty Salesforce backend and replace some tags and BOOM: super nice transactional emails from SalesHorse!
I use https://foundation.zurb.com/emails/email-templates.html for templates, and they've worked well.
meaning that each issue of the newsletter can include a set of like content items (e.g., articles) but the bundle of content is specific to each user (user 1 gets content items 1, 2, and 3, while user 2 gets content items 1, 3 and 5). this is one level deeper than just simple personalization like "Hi Joe, thanks for signing up with us on Saturday, Mar 4...".
i've yet to see a marketing email provider offer this functionality very well, if at all. for example, sendgrid (which i'm using now) supports it via a convoluted combination of section and substitution tags that is not very well documented. but most systems (including mailchimp, constant contact, etc.) don't even contemplate this use case.
<!-- tmpl_if subscriber.state eq 'CO' -->
Here's what's happening in Colorado!
<!-- /tmpl_if -->
It's been a feature for at least a decade, I believe. Sending via Amazon SES is also supported.Is there a use case that doesn't involve writing code to do the personalization? I've been picking articles with some machine learning stuff but I'm not convinced that would work for many people.
it would combine essentially a CMS with marketing automation, where content can be fed into the system (either created or curated) and the newsletter template would slot the selected content into the available spaces based on the rules (and/or via machine learning).
but yes, machine-selected content would be a logical next step after what i'm describing.
https://aws.amazon.com/about-aws/whats-new/2017/10/amazon-se...
https://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-p...
Not sure if any of the 3rd party scripts offer it though.
In the end we just fire it from our web application like a transaction email, this has a few disadvantages though:
- Sending to our list of 100k users takes a good portion of the day, although this could be fixed if we used the bulk send APIs our transnational email provider has.
- Our marketing team can't easily edit the rest of the content in the newsletter so it generally remains pretty static or needs developer time just to send a newsletter.
I'm not really sure how such a service would work though, would the email provider make a webhook call back to your servers with the user id and you server return the content for that section?
In order to take full advantage of it you need to be a developer though.
It's got great pricing too, esp. if you get their perpetual license and then run it on your own dedicated server (they set it up.)
If you involve that package in the render step before you send, it should be able to do what you need to.
Beyond newsletters you can add transactional and segment-specific campaigns.
I DO work there, so take my recommendation with that in mind...And I am not trolling ycombinator for every email conversation.
but that recipe illustrates the exact issue i run into (and maybe you have a better solution): i don't want to have to define branches for each segment ("role" in the recipe) in your campaign manager. i want to pass in a collection of recipients (each having the role attribute set) and hashes of attributes with each tied to a role, and have the template select the appropriate hash of attributes to display (e.g., [title, date, author, body, image] for articles) based on that attribute rather than creating whole new templates and branches for each segment.
this let's me programmatically add more "versions" of the newsletter without going through the clunky process of branching and duplicating templates (it's DRY'ing out the templating process).
so with articles for example, west coasters get article A and east coasters get article B, each having their own hash of [title, date, author, body, image] slotted into the right places based on the location attribute on the recipient (in this example).
liquid could be the answer, but does your API make it easy to pass in a hash of hashes to make it all work? many products seem to be missing this particular feature and as a result, don't work for my use case.
Source: Tried the free plan a few times.
So would't rely on it for anything business critical to be delivered - choose a company who only asends mail (Sendgrid, Mailgun of Mandrill (know they are owned by Mailchimp).
The most annoying part that i's not deterministic, sometimes it works sometime gmail blocks it or puts into spam ..
So it's cheaper for me to go on the monthly plan for one month, even if I know I'll only send out one newsletter during that time. If there's any chance at all that I might send more than one email in that month (rare but it has happened), then it's less than half the cost.
It just strikes me as weird.
I should really switch to a cheaper provider, but given that I only send a handful of emails per year, I haven't found the time yet.
We verify the domains of each of our customers and thoroughly review their sending practices to ensure their email sending reputation stays high. Futhermore, you can talk to a real person if you have any issues with sending / deliverability. If you are interested in a comparison of Kevy and Mailchimp, check out this blog post [1].
[0]: http://kevy.co/
[1]: http://kevy.co/2017/03/31/kevy-comparison-mailchimp-klaviyo/
You also need to code a lot of the stuff Mailchimp has out of the box (like templates and delivery reports) yourself. But the capabilities are there.
Another great thing SES has is the ability to receive emails not just send.
But overall I like both products. Mailchimp is easy for non-tech people to use, SES is bare bones, pay as you go, and highly scriptable once you add in Lambda.
[0] https://sendgrid.com/blog/5-ways-check-sending-reputation/
Don't see any difference in bounce rate.
I started with Mandrill inbound emails. Friendly UI, easy to understand, works as advertised.
Then I moved to AWS SES for inbound emails. I wrote a small Lambda function which dissects the email and forwards it to my HTTP endpoint.
With usage growing, SES was getting expensive as well. So I wrote a SMTP server in Go using this: https://github.com/mhale/smtpd It's very basic, doesn't support SSL, but seems to work OK in practice. My inbound email handling is now basically free.
It ended up saving me $600/year back then and would - at this point - be saving me roughly $2.000/year.
Here's my write-up from back then; https://ma.ttias.be/mailchimp-sendy-saved-600-year/
Once every few months you get on a blacklist but an email or quick phone call gets you removed.
You can import zipped templates into MailChimp manually. But if you made a typo, it's painful to export and reimport each time.
Automates most of the painful tasks of putting an email together. You could also add a task that sends the templates to Mailchimp once built.
There are supposed to be issues with deliverability from SES that many can't accept and so they use other services (of which, the main one, I'm blanking on) that handle sending mail better.
I don't know about this. At my previous employer we used SES to send service emails to our users on two domains (Office 365 hosted) and we didn't notice any delivery issues. Our volume wasn't huge though, above 10k but under 20k emails per month.
That being said, Amazon will really quickly suspend your SES account if your bounce rate is too high. They also don't keep hugely detailed logs, so restoring service generally relies on you keeping good logs from your app/MTA and figuring out which email addresses are bouncing.
Check it at https://formget.com/mailget-app/
They aren't ending up in a spam folder, just delayed.
Note that the email address domain is the same between these two.
Sendgrid exhibited the same behavior, last I heard, sendgrid is also using SES.
But sending from a gapps email was instant.