Monday, January 28, 2013

When to use Gmail's SMTP in your app and when not



This post is about the very legitimate automated emails generated by any application, such as for transactions and signups. Getting these delivered to the inbox (instead of spambox or nirvana) is the goal. 

The short answer: 

Sooner or later you may hit the sending limit. It's not when you deploy, and maybe not while beta testing. So better know the limits, risks and alternatives.

The longer answer:

If your sender address is hosted on Gmail then using their SMTP server is the obvious choice because:
  • You already have access to it
  • High availability
  • Unlikely that Gmail's smtp servers get added to block lists such as this one

How to connect to Gmail SMTP

All you need is the following information, and an SMTP library for your programming language:
  • host: smtp.gmail.com
  • port: 465
  • ssl: yes
  • user:
  • password:
The email address you use to log in must be a real account, not an alias. If you prefer to send the address from a different address, use the "from" field. Not modifying the "from" and "reply-to" increases your chances of getting delivered to the inbox.

You test it, email delivers, so you deploy your app, done.

Errors to expect

Soon after, your beta testers report to not receive any email. Checking your logs finds errors such as "550 5.4.5 Daily sending quota exceeded." or "535, response: 5.7.1 Please log in with your web browser and then try again.". What happened?

3 types of Gmail accounts

There are three types of Gmail addresses:
  1. The common Gmail domains: anything @ gmail
  2. Google Apps for free: yourname @ yourdomain
  3. Google Apps pro: yourname @ yourdomain
If you go and sign up for a new Gmail address from your desktop, then try sending mail from your (remote) server location, you'll get the 535 error quickly (it's the typical spammer pattern). You need to verify your account by SMS, and mailing goes on. For a short moment. It appears that such accounts can only send to a handful of different email addresses per day. I was not able to find official statements and numbers. The number is probably so low for new accounts, so if you have an established one it may work longer.

If you have your own domain set up for Gmail then the limit is higher. It makes sense since you have a public whois record. Google disabled signups for the free apps service a couple weeks ago. That's probably why I cannot find official information about the limits. The number of recipients per day is quoted as 500 on the internet. If you have such an account already then you can continue using it.

For the paid account the official page says 2000 unique, external recipients per day. 

Other risks

The official page has another fact:
"The value of these limits may change without notice in order to protect Google’s infrastructure"
Also, I've found unofficial/unverified information about Google lowering the daily send limit on high bounce rates. This makes perfect sense; spammers have high bounce rates. This is an open door to malicious users of your app: sign up with a couple invalid addresses, and your email system may be interrupted for a while.


Using your own SMTP

If you decide now that Gmail SMTP is not for you, there are some things to consider with your own.

If you access the SMTP of your provider, then you may face similar limits there. After all your provider has to make sure their customers don't spam, and not the whole server gets blacklisted. But this can and does happen nevertheless: Either because one of the other users spammed, or because one account was hijacked and abused. As a result your email messages may be accepted by the SMTP, but never make it to their destination. Maybe you get bounces, maybe not.

Be sure to create a Sender Policy Framework record.

Conclusions

A combined approach

I still believe that using Gmail's outgoing mailserver has its advantages. They are reliable, and in case of denial they return clear status codes. A solution with Gmail as primary, and your server as fallback, sounds like a good idea to me.

Further reading

Google's Bulk Senders Guidelines has more useful information to get delivered.

Not for marketing

Given the limits and risks, I'd definitely not use Gmail for sending anything that could be marked as spam by the receivers. Marketing, newsletters, even if the user at some point actively asked for it. Only send high priority mail such as transaction confirmations though Gmail SMTP.

1 comment:

  1. Another option would be Amazon SES: http://aws.amazon.com/ses/

    ReplyDelete