How to stop Gmail from marking mails sent by my web app as spam?

Question

I have a simple web application that provides daily financial data. Users subscribe, and we send them an email every day. However, Gmail is marking all of our emails as spam. What should we be looking out for?

Answer 1

This is a common problem many companies that send out automated emails face today, overzealous spam filters. I've seen my brokerage and bank simply start off each email with "Please add '[email protected]' to your safe senders list." Keep in mind this brokerage and bank probably have an army of developers and still resort to a reminder to the human recipient :) Most spam filters are based of Bayesian algorithms, and they will never get it 100% right.

Answer 2

Chiefly, to avoid a spam engine classifying your messages as spam you should:

• Make sure they aren't spam (i.e. ensure that only users who have really opted in get mailed - make sure you keep an opt-in audit log)
• Make sure they don't look too much like spam - $$$ MAKE MONEY FAST is not a good subject line
• Ensure that the sender address is not spoofed and does not appear to be spoofed. Use a domain that you are authorised to send from (add valid SPF records if you like)
• Not do anything that looks malware-ish (e.g. HTML emails containing scripts, forms, flash etc)

But by and large the main one is:

• Do not send them from an IP address which is known for sending spam.

The last point means that YOU CANNOT USE SHARED HOSTING. Almost all shared hosting providers allow the sending of mails which don't conform to any of the above. Shared hosting providers' relays are almost always on lots of blacklists.

It only takes one vulnerable web app on your shared hosting for it to turn into a spam gateway - something which you can't afford.

EDIT: Oh yes - if you're not setting the envelope-sender, your hosting provider may have it set to something stupid - ensure that you do set it to the same as From: - this makes sure that your messages aren't seen as spoofed

Answer 3

You could also take a look at the tests performed by SpamAssassin. Of course that's not what Gmail is using (or who knows?) but you'll get a feeling for the kind of things that might qualify you as spam.

At the end of the day, you're still fighting a losing battle -- there is no certain way of getting out of the spam box (spammers would love that, heh), since one man's financial data might be another one's spam. Do make sure to throw a warning to your users and let them worry about their email solution marking things as spam, since they're the only ones who can really do something about it.

Edit: Alright, I was under the impression that SPF would actually help in this situation, but it doesn't seem to be the case. Do use SPF but it won't help you past the spam filter.

Answer 4

• Make sure your mail host is a valid A record, rather than a CNAME.
• Make sure your MX record is set to the full host name of your mail host (which is set-up as an A record).
• Make sure you can do a reverse lookup of your mail host's IP address. This will be important for setting up SPF/Sender ID records.
• Set up SPF/SenderID information as a TXT record.
• Once you've configured everything you should verify it. Make sure there are no warnings or errors before contacting Gmail support.
• As MarkR states, test your emails with Spam Assassin. Send yourself an email from your app and copy the raw message (including headers) to a text file and run it against Spam Assassin's command line test.
• If you are sending plain text emails, make sure you have the charset in the Content-Type header set to ISO-8859-1. Gmail seems to be very particular about this.

Answer 5

Why not have something on the signup form along the lines of.

Some email providers may automatically mark the emails as spam. All automated emails will be sent from [email protected], please add this to your safe list

Whatever you do it is likly that your emails will get marked as spam somethings anyway, ive had emails from large corperations go straight into the spam box when they were responding to support requests id made. So its better to make sure your users are prepared for that posibility.