My Mailchimp blocks sending the e-mails after I imported a larger number of e-mails.
I still have enough space of e-mails left but when I try sending the mail I get the following error:
List
MailChimp's artificial intelligence system, Omnivore, automatically scanned your recent import. Omnivore detected that abuse rates for the campaign will exceed industry thresholds. This needs to be resolved before we can support sending to this list.
To resolve this, we must ask that the list data be removed and reconfirmed through a verifiable process. Once this is done, the campaign can be replicated and resent.
But I can not resend to all my clients a subscriber link!
How can I solve this error so I can finally send e-mails again?
Maybe you've alrady solved this, but if not, or anyone struggling with this...
I had the same problem. My solution (after contact with MailChimp support):
Delete all imported emails from the list.
Your Campaign probably still won't send, with same error, so:
Replicate the campaign. The new one will now be able to send.
This worked for me. If not for you, maybe the contact I had with the Compliance Team of Mailchimp was the solution and they confirmed my deleting of the emails. So email and stalk them.
The main issue for the blocking by Omnivore, was probably the amount of info# and ofice# addresses in the import list. At least delete ALL of those before import.
Cheers,
Richard
I tried to import a larget list of subscribers. I eventually figured out that I had to split the CSV file into multiple CSV files with a maximum of 200 entries (subscriber rows) in each for Omnivore to stop complaining.
CSV Splitter (free Windows program) did the trick of splitting my large CSV into smaller chunks.
Before importing, I verified the email addreses in the subscriber list using Free Email Verifier (free online tool), as Omnivore might be cheching for non-existing email adresses.
It might also be unhappy of role based email addresses like postmaster#example.com, but then you will get a notification with a link to display the problematic email address(es).
MailChimp's Omnivore spam filter throws lots of false positives. Unfortunately, they don't check their compliance questionnaires in a timely manner.
Sending an email to Compliance#mailchimp.com is your best bet.
Related
We have a newsletter where people opt-in (everything is on the up and up here). As people leave jobs (fired, layoffs, etc.), we still send to those emails and now after a few years, we have a considerable amount of emails that need to be purged.
The inbox that is receiving the bounces/invalid emails is a gmail account. We can filter (via a search) and find the emails that need to be removed but how can we export those emails to a list so that we can clean up our distribution list? Are there any tools that would help simply this?
We are looking into mailgun and sendgrid for future send outs but we need to clean up the list before we migrate. Any help or suggestions would be appreciated.
Our tech stack is apache/coldfusion 11 (not that it matters but in case it helps).
You could use CF to log into gmail and pull all the messages. Then loop through them all to find the bounce messages. Appending those bounced email addressed to a simple flat file. If you want to get fancy you can use a database, but I think a simple text file would do in this case. One email address per line.
I just read that you are deleting those bounced email addresses from a database. IF you're confident of your coding the above idea, you could directly delete from your database rather than saving a file.
I've been trying to send transactional emails to Gmail, Hotmail and Yahoo inboxes but most of the time they are going to spam folder.
I already tried using SPF, DKIM filter, multi-part message and still couldn't get the "magic solution" that always work.
If someone has experience on that, please share some tips and links about this.
I appreciate any help.
Thank you!
Each provider will have it's own rules for creating emails that are not to be treated as spam and these will vary. I don't a simple one size fits all solution will exist.
mhere is no dependable way to circumvent span filters. Spam evolves, counter measures evolve.
If you supply an email-based registration system the user will have an interaction with you as part of their email record. I would imagine the fact that they responded to an email from your domain may get you over the "spammy" threshold. Context is starting to count.
I am working on generating emails using Java. I would love to use some sort of system where I can send out mass emails and ensure that the emails were received by the intended recipient (A. My code to send the emails worked and B.The emails were not marked as spam). How can I do this without setting up (and keeping track of) a couple hundred email addresses and then checking each one individually?
Thanks!
Jeff Atwood's latest blog post talks about several things you need to do when sending email to users:
So You'd Like to Send Some Email (Through Code)
Whenever I've needed to test a system like this, I simply use an override property in the code that substitutes my own email address, creating a loopback test.
I don't know how you're going to test the "not marked as spam" thing, without having at least a handful of test accounts at various providers. Every email provider uses different bayesian filters to filter out spam.
I'm working on an application that will allow management to send registered users (opt-in) broadcast emails at regular intervals, or based on various other criteria. In any case, I'm curious as to whether I should send a separate email to each recipient or bcc all of them on a single message. Currently the email list would be about 1500 recipients, but it should scale all the way up to at least 25k without problems.
Thoughts? Am I getting into a range that I need to worry about being put on spam lists?
Yes, I've had spam list problem with mailing lists of that size, managing email lists for non-profits.
One wants to take extra precautions: make sure your email has SPF records, write a script to send the emails in batches, paced out over time. Definitely send them one one at a time, not as bcc, as direct mail has a better chance of arriving. Make it very easy to unsubscribe. Include people's subscribed email in the message sent -- often people have email forwarded to another account and then try to unsubscribe that account and get frustrated.
Even so, don't be surprised if you have to change your IP at some point.
You are getting into that range. This is the point where I would look to get a third party to send the email on my behalf. Let them worry about being marked as spammers, supply the bandwidth, etc.
I recently built an application with those same criteria. We do the emailing in-house, and send one email to each recipient.
Do use domain keys signing or be sure to use SPF records for your domain. We didn't do that at first, and were blacklisted by a number of different ISPs. Fortunately, it is fairly easy to get them to unblock you. Most will include an online form you can fill out or an email address you can use in the server bounce message.
Don't try to implement the actual email sending yourself. That's a huge waste of time. Either outsource the entire process to one of the many reputable vendors out there (Many organizations I deal with use Constant Contact, and it works well), or run a garden-variety mailing list server (e.g. Mailman) in-house.
Either way, take efforts to make it very easy to unsubscribe (good vendors have that covered), to authenticate that messages are from your company, and to show that your company is not spamming. Real mailing list server software supports all of these goals, by adding proper headers that identify the source very clearly and making unsubscription easy. For instance, Gmail will now offer to send unsubscribe requests in response to mailing list messages marked as 'spam', as has AOL for a long time.
Definitely set up SPF and DKIM if you can manage it.
Finally, whatever you do, make sure you keep logs of your subscriptions, so that if someone does accuse you of spamming, you can defend yourself.
The task is mostly uninteresting on a strictly technical level. You should worry about what happens when a recipient thinks that your list's content is spam and starts (a) complaining or (b) flagging the message as spam with one or more anti-spam service providers. Something like this is bound to happen with a list of the size you describe.
If you are prepared and have the time handle such cases, go for it, at least for a start. (Changing your mail server's IP address as Devin Ceartas suggests won't be of much use by the way.)
If you want to build your own thing, I have two pieces of advice:
Unsubscribing has to be easy, no more than one or two clicks. Using Mailman or any other mailing list manager that was intended for discussion mailing lists is asking for trouble.
BCCing the same message to 1500 (or 25k) recipients may take some load off your mail server, but it has one serious disadvantage: You won't be able to use VERP in order to determine if all addresses that have once been subscribed to your list are still valid. (Large mail providers tend to classify messages as spam if there are delivery attempts to many invalid addresses.)
Our clients sometimes don't get the emails that we send out. It's a BIG loss. How do I assure that they receive the emails so that if it's not received in the other end, the program can resend it or do something about it.
None of the suggestions above will work 100% of the time. Many email clients will (rightly so) refuse to load foreign images, negating the usefulness of "web bugs". They will also refuse (or be unable to) return Outlook-style "receipts". And many mail servers either deliberately (to curb spam) or mistakenly (due to misconfiguration) won't return bounce messages. Or possibly an over-aggressive spam filter ate your message, so it arrived but was never seen by the end user. Plus there is the little matter of mail taking hours or days to reach the end user or bounce, and how do you correlate these late notifications or bounces with the mail you sent 4 days ago?
So basically, you can catch some but not all, no matter what you do. I'd say that any design that relies on being able to know with certainty whether the end user got your mail is fatally flawed.
One thing that you can do is set up a bounceback address that receives any mail that is undeliverable. Use the bounceback address as the From address -- you may want a different one for Reply-To so that replies get directed properly.
Check the bounceback mailbox daily and contact customers to get updated email addresses for the ones that fail. You may be able to automate a couple of retries to failed addresses before resorting to the manual contact in case the failure is only intermittent.
This would take some code outside your application that scans the mailbox and keeps some state information about the number of contacts, etc. and attempts the resend.
Depending on how you generate the mails, you might be able to make this process easier: generate a unique bounce address for every single email you send out. You could use bounces+1234#example.com, for example.
Many SMTP servers will allow you to use the part after the + as a parameter to an external script, etc.
The problem is that many (broken) SMTP servers don't return enough info with a bounce to identify the original message -- sometimes, when there are forwardings involved, you don't even get back the original addressee...
With the above trick you can reliably correlate outgoing messages with incoming bounces.
There is no standard way to know whether the email reached the destination. Many email clients support different types of receipts though. You can use any of those if you want.
There are some ways to know when the user actually read the email.
There are many techniques like adding an image to your email that is to be fetched from your web server. When the user reads the email, the request for the image comes to your server and you can capture the event.
The problem is that there is no way to know that the mail did not reach the destination.
I worked on a bulk email system in a previous life. Deliverability was one of our major issues. The most common cause of undelivered emails is a spam filter.
Here are the steps we took to ensure the highest delivery rates:
We used Return Path to test emails for that spam-like smell.
If you send a lot of emails, you need to make sure your SMTP server is not blacklisted.
Remind your users to add your FROM address to their "safe senders" list.
Use a system that collects bouncebacks and use them to scrub your mailing list. This will also help keep you off the blacklists.
If the emails are critical, consider sending them return-receipt-requested. This will not really guarantee anything, but it might give you some metrics on actual deliverability.
There's not really a good way to determine if the email actually arrives in their inbox, you can only confirm that you sent it. Attach a receipt that lets you know when they open it perhaps?
Microsoft Outlook provides similar functionality, however it is based on the email client. I'm not sure if other clients, like Thunderbird, support this.
However, there is nothing in the protocols that specify receipts.
One option that may work: send a link to a generate web page and monitor that page for hits. This provides its own issues however: confidentiality, etc.