How do I find out why Gmail is seemingly refusing connections from my specific IP range?

I'm getting a "Connection timeout" error when attempting to send email through smtp.gmail.com using the email facilities in Django running on a Linux machine on Amazon's EC2 service.

Oddly, I can send mail using sendmail, but it initially gets the same timeout error and then falls back to an alternative server, which accepts a connection, e.g.

~$ echo -e "Subject:test subject\ntest body\n" | sendmail -v myuser@mydomain
Loading lookup modules from /usr/lib/exim/4.72-1.fc13/lookups
Loaded 0 lookup modules
 <= app@domain U=app P=local S=443
Loading lookup modules from
Loaded 0 lookup modules
delivering 1ReChV-0001Hx-Ss
Connecting to aspmx.l.google.com []:25 ... failed:
Connection timed out (timeout=5m)
 aspmx.l.google.com [] Connection timed out
Connecting to ALT1.aspmx.l.google.com []:25 ... connected

This is only occurring from Amazon's cloud. I can connect to smtp.gmail.com from my localhost using the same credentials, and send email just fine. And I can ping smtp.gmail.com just fine from everywhere, so it doesn't seem to be a routing or firewall issue.

Google lists no problems on their status dashboard.

The server in question sends very low volumes of email (10-20 a day), so I'd be surprised if it was flagged for spamming.


Sending email from an EC2 instance is just not a good idea unless you are handing the email to a mail server that has specifically agreed to accept your mail. There are a variety of reasons, but the main one is that an EC2's IP address is dynamic and a mail server must be on a static IP address to accept bounces.

Basically, if you want to send mail, you need to send it to a real mail server that will take responsibility for delivering the mail to its destination. Amazon offers such services, with real mail servers hosted at static IP addresses.

  • This doesn't really answer my question. This setup has been working fine for over a year. Why would it suddenly stop working? No IPs have changed. – Cerin Dec 24 '11 at 4:30
  • My point is that it's not reasonable to expect it to work. The question is just as much why it was working before as why it's not working now. You're not handing mail to your own mail server, you're not receiving mail as the final destination, and you're not relaying mail from one server to another. Those are the only configurations that should be expected to work. – David Schwartz Dec 24 '11 at 4:39
  • If Google has identified your address as dynamic, I would expect them to refuse unauthenticated SMTP connections. You may have triggered them to block you by sending email that bounced, but could not be returned to sender. – BillThor Dec 24 '11 at 4:43
  • @David, I should have mentioned I don't really want a "real email server". These machines are only sending out transactional emails and don't accept replies or incoming email. This setup is perfectly reasonable given those constraints. – Cerin Dec 24 '11 at 15:24
  • @Cerin Mail just doesn't work that way. Unless you have special arrangements with Google, you get the normal arrangements, where part of the sender's responsibility is to accept bounces. If you want an arrangement where you can send mail without having a real mail server, someone else has to do your share of the work -- you need to hand the emails to a real mail server that has agreed to accept them from you. Google has not. And you aren't doing your share. – David Schwartz Dec 24 '11 at 20:48

Most of the times that I see similar problems with mail servers (and from the logs presented I understand that you connect to ALT1.aspmx.l.google.com but mail is not sent) disabling TCP Window scaling helps bypassing (not solving) the problem.

I do not know what OS you're running on the EC2, but if it is Linux you may try adding:

net.ipv4.tcp_rmem = 4096 87380 174760
net.ipv4.tcp_wmem = 4096 16384 131072
net.ipv4.tcp_window_scaling = 0

in your /etc/sysctl.conf and run sysctl -p afterwards.


I've found Google has locked accounts/IP Addresses/ActiveSync etc when their automated protection systems suspect suspicious activity.

ie, A user using Outlook with POP/SMTP suddenly can't log in with Outlook.

To 'unlock' an IP, you can log into the GMail account from that IP using the website gmail.com, and the account will usually come good in a few minutes.

Otherwise Google Tech Support once directed me to https://www.google.com/accounts/UnlockCaptcha or http://www.google.com/a/your_domain.com/UnlockCaptcha for an account that ActiveSync had locked down and nothing would bring it back.

See here for more information: http://www.gmailhelp.com/2009/10/unlocking-googles-gmail-captcha/

  • The strange thing is, if this is true, it's only "locked" from a specific IP. I can login to the Gmail account just fine everywhere else. – Cerin Dec 24 '11 at 15:22
  • Yeah I thought of that after I had written the comment and thought my answer may no longer apply. But I've just thought of something else: Are you using Google Apps Business rather than just GMail? If so, (I know they're not exactly for this circumstance) you can try adding your EC2 IP to the whitelist or inbound gateway under Settings -> E-Mail -> General. I'd still do the CAPTCHA and web login from the EC2 IP first though. – Dom Dec 25 '11 at 1:39
  • Hmm also, I've never really used sendmail so not sure what I'm reading in the log above, but are you connecting to the MX records for @domain.com on port 25 to deliver a message like a server? Or are you connecting to smtp.gmail.com on port 465 with SSL and a valid Username and Password? If it's the latter, you're acting as a user, not a mail server, and the thread above about getting a real mail server is moot. If it's the former, set your sendmail script up as the latter. – Dom Dec 25 '11 at 1:46

The problem has seemingly resolved itself. Since I could still send email using alternative Google servers, I suspect it was some minor networking issue between my server and Google.

Not the answer you're looking for? Browse other questions tagged or ask your own question.