sending mail with php & escaping hotmails junk folder

Question

I have been trying to get PEAR::mail to successfully deliver emails to hotmail users without being flagged as SPAM and ending up in the junk folder, i have no problems with yahoo/gmail only with hotmail.

google suggested that this is a common problem with hotmail and that possible causes can include

• incorrect reverse DNS for main IP of the server
• lack of SenderId/SPF records
• being blacklisted

having checked all of the above i can only think of one other reason - incorrectly formatted headers ?

to test this theory i set up outlook to send email via the same address that PEAR::mail uses and sent a quick test - it delivered straight to my inbox

so i compared the headers from the email sent from PEAR::mail against the headers sent by Outlook and there are only a few differences - i have only listed the differences to save space (and peoples eyes)

PEAR::mail headers (not in outlook headers)

X-PHP-Script: www.example.com/register.php for [users ip address]

Outlook headers (not in PEAR::mail headers)

X-Mailer: Microsoft Office Outlook 11
Thread-Index: Ack6CWSQlgV8s6+6SWyifka2NNpB7g==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350

the only other differences that i can see are

• the order of the From: and To: headers are reversed
• and in the Received: section of the headers

Outlook

Received: from myhomehostname.com ([ip address] helo=simber) 
by mywebhostname.com with local (Exim 4.67)

PEAR::mail

Received: from apache by mywebhostname.com with local (Exim 4.67)

could these small differences in the headers be the cause or am i looking in the wrong place ? i knew this might be problematic hence why i chose to use the PEAR::mail class rather than rolling my own but now i really have no idea where to go with this, any help would be greatly appreciated.

Update: as per changelog's suggestion i have tried adding the MS headers to the PEAR::mail class and i have tried replacing PEAR::mail with PHPMailer (with & without the extra headers) - they all end up in the junk folder.

I am starting to believe that it may not be the headers afterall.

Update 2: i should have mentioned that the emails are just a registration confirmation to validate the email address the user signed up with - no mailshots etc so our volume is extremely low.

I have considered warning users who provide a @hotmail/live email address to add us to their address book or check their junk folder - but this just seems unprofessional to me - it may be that i have to resort to this.

As for becoming Sender Score Certified - its very unlikely that i can justify the cost of this when considering the low volume and purpose of these emails.

Answer 1

I have always used PHPMailer in my projects, and what I did to avoid Hotmail's junk folder was to call a method they had that added MS Headers to the message.

Take a look at the source, and add those headers yourself.

Also, I recommend including a text-version if you're sending HTML e-mail.

Answer 2

I'd suggest modifying the headers you send to math 100% what outlook sends, and see if that solves the problem. Really it's a tough one though, hotmail is known for having a super crappy spam filter, sending lots of legit email to junk, and lots of spam to your inbox.

Answer 3

My company does professional e-mail marketting campaigns (through strongmail servers) we send thousands of (sollicited) emails a day to all kinds of addresses.

The problem you are facing is that you have no authority. You could just be some spammer trying to send loads of spam.

The thing you need to do is:

• Add unsubscribe links
• Apply for hotmail's Junkmail reporting program (JMRP) and MAKE SURE people that press the 'this is junk' button do not get mailed again. This will up your 'sender score; @ hotmail and allow you messages to get through.
• Add SPF and other antispam solutions.
• Do not send more than 50 e-mails per minute to @hotmail.com (other domains have other limits)

B.t.w we use PHPMailer to compose our messages, no problem at all with that :-) The problem nowadays really is the restricting receiving mailservers.

Answer 4

Email Deliverability is closer to an art than a science. I can pretty much guarantee that it has nothing to do with your headers. Trying to spoof headers is likely the worst thing you can do. The received: header is added by the mail servers as they receive the messages: spoofing this will cause your email to get flagged as spam: one of the spam filters commonly used is to count then number of relays (ie received: headers). If there's too many you get a higher spam score.

Reverse DNS and SPF are the minimum entry barriers. For hotmail in particular, there are three other very important factors AFTER you get your SPF and DNS records in line:

• IP/Domain Reputation
• Volume
• Being in the Address Book

Reputation isn't the same as being blacklisted. You need to build trust with hotmail. Hotmail uses Sender Score Certified as their main reputation broker -- you can check your reputation with them if you want, but it may cost you.

If you're on a shared host or an IP address that has a checkered past, you won't have much luck with hotmail.

You build reputation by having a consistent volume with low spam complaints. You can send 1M messages an hour all day long, as long as you do it every day. If you're sending less than 10,000 messages a day, you likely won't be able to build up a decent reputation. You can get a report on your volume at Sender Base.

Finally, the best way to make sure you end up in the inbox is to get your users to add the sending email address to their address book. Hotmail uses this as a safe sender list. In fact, I think there's an additional trusted sender option in Hotmail now too (it's been awhile since I've been in the delivery game and I don't use hotmail).

Here are some other best practices for sending email:

• ALWAYS use the same IP address
• ALWAYS use the same FROM address
• if you have a large list that you send newsletters to, make sure you retire old addresses (ie, check open rates)
• if you have a large list, try segmenting it and sending from different IP addresses based on risk (ie, newer addresses may mark the message as spam)