Emails to hotmail go to spam

This all depends on mandrill ips, mailwizz can't help.
The solution would be to try and get a dedicated ip from mandrill.
 
Something interesting happened. I added elasticemail server and added elasticemail DKIM and SPF to my domain DNS, and hotmail was marking my emails as spam too.

As elasticemail allows to send emails from their app, I sent a test campaign just to see if the issue was on mailwizz, and it went to spam too.

But then I sent an email from gmail using my domain to a testing hotmail account, and the email was sucessfuly delivered. Comparing the emails source code I found this: elasticemail campaign only sent an html version and it was base64 encoded, while mailwizz sent plain text and html version and it was base64 encoded as well. But Gmail sent both versions also, but it was quoted-printable encoded.

So I went to elasticemail settings and enabled the option to generate automatically the plain text version, and changed the encoding from base64 to quoted-printable.

Then I sent again the campaign from elasticemail app (not mailwizz), the same that was marked as spam before, and now it was delivered perfectly.

So I suspect hotmail doesnt allow base64 encoding. After I changed those settings, all my campaigns sent from elasticemail app are delivered perfectly.

Then I sent a campaign from mailwizz using elasticemail server, I was hoping that the email was sent using quoted-printable encoding by using elasticemail setings, but it was still sent as base64 and the email went to spam.

Is there a way to change the email encoding on mailwizz? I think that´s the issue.
 
The spam issue is not related to MW.
There are so many things to set up out of MW that it's quiet difficult to say what is the reason.But of course if the message is delivered, this is not an issue of MW.
You have to check the content, the ip rep, the bounce volume, the domain rep, the nr of users complains, the FBL set up and so on.
And still, if everything is set up correctly, the ISP's can mark your message as spam.There is no magic recipe to get your messages always in the inbox, just a lot of work with each ISP rules.

Hope this can help.

Cheers
 
What @Hip says makes sense and what's interesting in this case, is that i don't know how emails end up in base64 since mailwizz doesn't do base64 encoding on emails.
If you look inside /apps/common/components/mailer/MailerSwiftMailer.php at line 294 you have:
PHP: 
$message->setEncoder(Swift_Encoding::get8BitEncoding());
which forces 8bit encoding and since 7bit/8bit/qp/base64 are all acceptable encodings, i don't see why hotmail would reject any email because of encoding.

You could try:
PHP: 
$message->setEncoder(Swift_Encoding::getQpEncoding());

or simply disable the encoder if above doesn't work:
PHP: 
// $message->setEncoder(Swift_Encoding::get8BitEncoding());

Maybe try the above and see where it gets you.
 
Hip said:
The spam issue is not related to MW.
There are so many things to set up out of MW that it's quiet difficult to say what is the reason.But of course if the message is delivered, this is not an issue of MW.
You have to check the content, the ip rep, the bounce volume, the domain rep, the nr of users complains, the FBL set up and so on.
And still, if everything is set up correctly, the ISP's can mark your message as spam.There is no magic recipe to get your messages always in the inbox, just a lot of work with each ISP rules.

Hope this can help.

Cheers
Click to expand...

@Hip I understand there are a lot of factors involved. But according to my test, the campaign was marked as spam in a moment, then I changed those settings and now it is successfully delivered. I think those settings had something to do, right?

Mailwizz already sends the plain text and html versions, so the only difference is the encoding.

Anyway, I´m not saying it´s mailwizz fault. I just want to test if after changing the encoding the campaigns are not marked as spam.
 
twisted1919 said:
What @Hip says makes sense and what's interesting in this case, is that i don't know how emails end up in base64 since mailwizz doesn't do base64 encoding on emails.
If you look inside /apps/common/components/mailer/MailerSwiftMailer.php at line 294 you have:
PHP: 
$message->setEncoder(Swift_Encoding::get8BitEncoding());
which forces 8bit encoding and since 7bit/8bit/qp/base64 are all acceptable encodings, i don't see why hotmail would reject any email because of encoding.

You could try:
PHP: 
$message->setEncoder(Swift_Encoding::getQpEncoding());

or simply disable the encoder if above doesn't work:
PHP: 
// $message->setEncoder(Swift_Encoding::get8BitEncoding());

Maybe try the above and see where it gets you.
Click to expand...

Thank you @twisted1919 , I will try that and report back to you.
 
@Jose Vega - That will make a difference only if you re using SMTP server for ElasticEmail. If you are using the web api implementation then that doesn't have an encoder, it uses their PHP SDK for sending emails, case in which, if there's an issue, its in their end.
 
twisted1919 said:
@Jose Vega - That will make a difference only if you re using SMTP server for ElasticEmail. If you are using the web api implementation then that doesn't have an encoder, it uses their PHP SDK for sending emails, case in which, if there's an issue, its in their end.
Click to expand...

@twisted1919 I´m using web api. Where can I find the code that calls the elasticemail API? the API allows to set the encoding: http://elasticemail.com/api-documentation/send - The emails are using base64 because it´s the default, so I want to set manually QuotedPrintable.
 
Ah, i've missed that param, thanks for pointing it out.
apps/common/models/DeliveryServerElasticemailWebApi.php:
PHP: 
$postData = array(
                'username'      => $this->username,
                'api_key'       => $this->password,
                'from'          => !empty($fromEmail) ? $fromEmail : $this->from_email,
                'from_name'     => !empty($fromName) ? $fromName : $this->from_name,
                'sender'        => !empty($fromEmail) ? $fromEmail : $this->from_email,
                'sender_name'   => !empty($fromName) ? $fromName : $this->from_name,
                'reply_to'      => !empty($replyToEmail) ? $replyToEmail : $this->from_email,
                'reply_to_name' => !empty($replyToName) ? $replyToName : $this->from_name,
                'to'            => sprintf('%s <%s>', $toName, $toEmail),
                'subject'       => $params['subject'],
                'body_html'     => !empty($params['body']) ? $params['body'] : null,
                'body_text'     => !empty($params['plainText']) ? $params['plainText'] : CampaignHelper::htmlToText($params['body']),
                'encodingtype'  => 3, // THIS HAS BEEN ADDED!
            );
 
Jose,

You started using MailWizz a little after me and I've been following your posts. I don't want to be a troll on this post but having used some different services, I am offering my personal experience to tell you that I would bet my last $1 that encoding has absolutely nothing to do with why your emails are going to spam.

You have two issues: First, there's Amazon & Mandrill and there's everyone else. Nobody has the deliverability that Amazon & Mandrill have. I know there are other very well established services out there but they do not have the reputation that Amazon & Mandrill have and your emails are going to be treated like they are from an unknown source. (And I suspect that every provider is subject to accidental blacklisting where they have to break their backs to get those situations repaired.)

You absolutely have to make sure that your DKIM & SPF are passing when they get through to the other side - view the source code of the email and search for "pass" & "fail" and make sure that any fail is accounted for, even if the email reached the inbox. I have multiple accounts on multiple services to track this stuff.

But regarding Microsoft: I have had the displeasure of using every Microsoft email service over the years: Hotmail, Windows Live Mail, Outlook, Office 365, and Microsoft's ability to filter spam is non-existent. I have had dozens of occurrences where I sent a single email to someone in the same domain and had the email go to spam. My college used to use Windows Live Mail and now uses Office 365 mail and I constantly have email from administrators landing in my spam filter. There is just no possible logic that anything programmed to check for spam would not exempt someone emailing me from the same [private] domain! If I had to guess, I would say that the Microsoft filters are very sensitive to the sending rate. Microsoft has absolutely no credibility in what it delivers to a user's inbox and while it affects us as senders, people need to know just how much email they miss because of how badly Microsoft filters the mail. On the other hand, iCloud will discard your suspected spam with no notice to either the sender or the receiver. MANY ISP's do this too.

About the encoding, I can tell you that I won't claim to be an authority on this, but I have had to track down about 20 different incidents of missing emails over the past 2-3 years and spam filters/systems/blacklists are all absurdly simple to the point that it's offensive and you would be giving these guys way too much credit to think that they look at anything so technical as your encoding. Even if I'm completely wrong on my premise about Base 64 encoding, I would never believe in a million years that Microsoft would filter on that - what ends up in my spam filter is the most ridiculous spam - in fact, I don't actually get spam on those accounts, so every single item that Microsoft flags is a false positive. (I'm trying to confirm this information with people that I think might know and I can't - but I'm telling you that the filters for Microsoft are so awful that I just can't believe this has anything to do with what you were thinking.)

From what I can tell, no transactional email service has any way of reporting that an email was delivered but that the recipient's system sent the email to the spam filter automatically. As long as it accepted, it is considered delivered.

I mean no disrespect but your content, when translated to English, has wording that corresponds to much of the email I find in my spam filter from Phishing attempts. People take a religious angle when they are trying to get you to send them money to help their loved ones, etc. I think you're going to always have some trouble delivering your email. I have a similar situation with content not appropriate for under 18 year olds and we have no way really to know if our emails get into the inbox. My only solution here is to keep track of the open rates in a spreadsheet so I can track irregularities. If anyone knows of other ideas or tools available to track this information I would love to hear about it.

Thanks in advance.
 
Hi robthecomputerguy thank you, I appreciate your comment. You´re right, the encoding wasn´t the issue. I solved it by getting a dedicated IP, using multiple delivery servers because yahoo marked as spam my emails when I sent too much from the same server, setting up reverse DNS, and remove wrong emails from my list.

Right now everything is working fine.

You got me thinking about the religious thing. I always thought we were a "pure" website and no one would consider us as phising or spam because we only deliver biblical studies to ministers and christian people. But now that I think about it, you´re absolutely right. I think it depends on my subscribers activity, if they mark my emails as spam manually or if they open and click my links.

Btw currently I´m getting around a 11% open rate and 50% click rate relative to the open rate. How are your open/click rates doing? I´ve kept this rates for over a year.
 
Sorry for the late response.
Microsoft using SmartScreen filter technology. Its a well known fact that SmartScreen is not that smart.
Actually if your IP is new, its almost certain that your mail will be marked as spam(false positive) and you have to build GOOD reputation in order to change that. Thats a bit weird, because how can you build good reputation if you starting from negative point and your emails end up to spam folder.
More info here: http://mail.live.com/mail/troubleshooting.aspx
 
You must log in or register to reply here.
Back
Top