6 ms·
ICOs and Cryptocurrencies aren't being singled out so much as categorized by the behavior of the topic/community. MC has a long list of product categories that
by michaelbuckbee 9y ago
ICOs and Cryptocurrencies aren't being singled out so much as categorized by the behavior of the topic/community. MC has a long list of product categories that they have empirically found to have deliverability issues so bad that they harm all of their other users.
Escort and dating services
Pharmaceutical products
Work from home, make money online, and lead generation opportunities
Gambling services or products
Multi-level marketing
Affiliate marketing
Credit repair and get out of debt opportunities
List brokers or list rental services
Selling “Likes” or followers for a social media platform
Cryptocurrencies are just the latest. You can read the whole list and more clarifications here (it's very clear and readable for legal documentation): https://mailchimp.com/legal/acceptable_use/ https://mailchimp.com/legal/acceptable_use/
- unclebucknasty 9y ago>deliverability issues so bad that they harm all of their other users. Why does this harms users who follow the guidelines to show origin/identity (SPF, DKIM, dedicated IP, etc.)? We also use SendGrid for transactional emails and it's the same: some hosts (like Office 365) have told us that they weight all messages coming from sendgrid.net to their users as SPAM because they've seen so many issues there. I pointed out that they should be able to distinguish between spammers and those who, like us, are positively identifiable and have not engaged in SPAM. No avail. Are they being lazy, or am I missing something?
- jjoske 9y agoIf the IP addresses get associated with to many spam reports, unsubscribes etc the gmail etc will start to associate these IP addresses as bad, and will be more likely to just block them no matter what the content.
- gsich 9y agoDon't host emails where the IPs used have a high chance that they have been used before. So no AWS/Azure/xyz stuff.
- sudosteph 9y agoThere are actually 3rd party services that mail companies can use to check how trusted an IP is. So a lot of times, they'll provision an EIP on AWS, run a check against that service, use it if it's clean, and release and try again if it's not. It does lock you to using EIPs though, which makes it a bit harder to scale up.
- Scoundreller 9y agoWhat's an EIP?
- jffry 9y agoElastic IP. You can reserve EIPs from among Amazon's pool and allocate them to other AWS resources that need public-facing IPs (like an EC2 machine).
- igammarays 9y agoYou might be interested in a provider-agnostic email API I am building to to avoid EIP/provider lock-in and have the security of multiple dedicated IP providers. Check it out: flutemail.com
- sudosteph 9y agoIf you're using a dedicated IP, then yes, they are being lazy. Or they have some vendetta with sendgrid maybe. There's always the possibility that your dedicated IP isn't as clean as you would hope. You can check here: https://mxtoolbox.com/blacklists.aspx https://mxtoolbox.com/blacklists.aspx
- wl 9y agoI've gotten far more spam from SendGrid than anything legitimate. They deserve every bit of their bad reputation with Microsoft's email folks.
- unclebucknasty 9y agoInteresting. From a legit user's perspective, it's a bit of a hassle to comply with their deliverability hurdles. First, there's a somewhat involved "whitelabeling" and setup process. Then, there's managing suppressions, unsubscribes, etc. You also have to be mindful of service interruptions if your reputation goes too low (i.e. from bounces, spam reports, etc.) So, seems like they are doing everything reasonable to prevent spamming through their service. Not sure what else an ESP can do. But, maybe they've just managed to make it more difficult for legit users than spammers.
- wl 9y agoOne thing they're not doing: Mandating confirmed opt-in. Asking the recipient if they want to receive email is the only way to confirm it's actually requested.
- unclebucknasty 9y agoI don't know about their marketing email policies, but we use it for transactional emails, wherein opt-in consent is generally not explicit. For instance, if you use it for service delivery (payment receipts, invoices, password resets, etc), there is no separate opt-in process beyond the fact that recipients are your users who signed up for your service. I'm not sure how any ESP could enforce the notion of opting in under these circumstances.
- wl 9y ago> there is no separate opt-in process beyond the fact that recipients are your users who signed up for your service. That's not a fact that the recipients are users that signed up for it. As someone with a first letter + last name @ gmail account, I can't tell you how many transactional emails I get for things I never signed up for. Try getting a bank to take your email address off of someone else's account—damn near impossible.
- deleted 9y ago[deleted]