My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 2314: Allow incoming email to work with custom domains
223 people starred this issue and may be notified of changes. Back to list
Reported by, Oct 25, 2009
Support for incoming email was added to app engine as explained here 
However it only works with domain. It would be ideal 
if there was support for custom domains and incoming email so would result in the app engine webhook being 
Oct 26, 2009
If using google apps, why not just setup a group with the desired customer facing email and with only one 
member, the email address?
Oct 26, 2009
I believe this is a documentation and usability bug.

It seems like this feature request would be satisfied by a little bit tighter 
integration between AppEngine and Google Apps for your Domain. I'd like to see the 
ability to register a domain email address with an app spot receiver instantly. At 
minimum, the receiving mail docs should explain the preferred way to configure this.
Nov 6, 2009
For many use cases it would be nice to attach a subdomain for encoding more information 
in the email as well. That is, support for the email address formats like the 
Jan 28, 2010
I have just read the details on the GAE mail service and i nearly fell off my chair.
What a wonderful opportunity for start-ups to offer email services for their users.
Like myspace and others alike. 

But sadly i steadied myself as hidden away was this small point! The brilliance of
the service is clouded by a tiny but important/practical issue such as this one - And
these kinds of problems seem to riddle app engine and hol dit back - But, on a
positive note most of the early down-points such as file size and usage have been
sorted and if this one gets sorted it pushes app engine even further to the "best
choice for start ups on a budget" their are some great frameworks such as Django and
Web2py. All worth considering if your starting up. I personally like the simplicity
of the standard bundled framework. PIL offers great imaging - beats .NET! just try a
thumbnail and see for yourself, and that's an out of the box comparison. The storage
is first class and  

I love app engine, its simple fast and build on sound technology. I'm voting for
this, i think its a super feature and i'm going to take a risk and use app engine on
the basis that i think the team will keep pulling the stops to remove the anchors
that are keeping GAE out of the race for solid cloud computing.

Mar 10, 2010
I tried this out on my domain and it works fine. You can also redirect all mail for a 
domain using the catch-all feature of apps and a gmail redirect.

There's a demo page up at; send email to the domain and it 
shows up there.

That said, the docs could use improvement.
Mar 14, 2010
I agree with Comment 4.
It is not a solution to add some email-forwarding. We wanted to make a startup with a
simple application where you can upload things to a website by sending a mail.

But now we cant do that, because we would need a custom domain. Please google add
this feature. Can't be that difficult!
Mar 14, 2010
I have a similar problam and I wouldn't like to use email-forwarding, too. So I vote
yes on allowing incoming email to work with custom domains.
Apr 13, 2010
I've worked around this by setting up an account for the desired email address, and then forwarding and deleting 
all email to that address to the appspot email.  I couldn't find any documentation of limits on incoming mail to a 
google apps email account, and it has been working thus far.
May 26, 2010
I also agree with Comment #4.

A couple posters have said "just enable email-forwarding", but with a Google Apps
address, is this even possible?  

In particular, when I add a forwarding address "", I am
then told "A confirmation code has been sent to verify permission." - my question is:
how can I access this "confirmation code"?
Oct 4, 2010
I am attempting to get a google app engine project running that will be accepting emails from a yahoo group. So the first step is to add the appspotmail address to my yahoo account. What i've set-up to get around this verification issue is to simply forward the email received in GAE to my own email address. Aside from some truncation issues in the html segment of multipart emails, this seems to work fine. However, for some reason when i follow the link that comes through (and i have no reason to think it has been altered in any way) The yahoo confirmation page tells me "Sorry, the verification email has expired", and since it was a matter of minutes, rather than the 5 days they suggest it should be active for, i can only assume that this situation is somehow based on the google mail server's response to the original email. Anyone have any ideas what might be going on here?
Oct 14, 2010
Project Member #11
(No comment was entered for this change.)
Status: Acknowledged
Labels: log-3098692
Dec 15, 2010
Project Member #12
(No comment was entered for this change.)
Labels: Component-Mail
Dec 16, 2010
Just as a follow up, I've come to believe that the most likely problem i'm having is that the validation email is being invalidated as soon as it is sent because my appspot email address has no appropriate SPF record to back it up. Herein lies the bigger problem with the custom domains issue - we have no control over the DNS so we will never be able to run a fully compliant mail server.
Mar 11, 2011
I don't get it - why not just add a POP client to the API?

That way users would be in total control and spam wouldn't be Google's problem.
Aug 26, 2011
Project Member #15
Bulk edit: mark escalated issue as Accepted.
Status: Accepted
Dec 1, 2011
After wasting 2 days on this, i have figured out there is pretty much no "hosted" way to do a wildcard to wildcard DNS email forwarding from your custom domain to domain. I have talked to pretty much all big league hosting and DNS providers(dyndns, zoneedit, easydns..) and no one supports this. Only way out is to either run your own mailserver or wait for Google to support.
Dec 1, 2011
The bottom line is that when you use AppEngine you are relying on a very small group of engineers (the AppEngine team) to build out features.  They are the gatekeepers, and their time is very limited.  There is no community development.  This explains why the pace of the project is slow and many users/customers are unhappy with the service.

If you want a flexible system, the kind in which you can address your product requests and technical requirements with ease and flexibility, then AppEngine is not right for you; Linux is right for you.  Go provision cloud machines and spool them up with CentOS.  Then choose from among MILLIONS of pieces of software to solve your particular problem.  

The core question when choosing AppEngine or normal cloud is this:  Is BigTable more important to you than the flexibility, configuration potential, and control that a Linux cloud offers you?
Dec 1, 2011
I am perfectly happy with the product and pace of development.
May 8, 2012
Project Member #19
(No comment was entered for this change.)
Labels: cherry-1
Jul 1, 2012
I see that this issue has been marked as accepted since Aug 26, 2011 (10 months ago) - could someone from the app engine team give an indication as to when we can expect this feature to be implemented? thanks! 
Jul 1, 2012
@Mickling you can kind of get around it by using a GApps domain group, and putting the email address in your group
Jul 3, 2012
I quote @Mickling.
@gwyn, what do you mean?
Jul 3, 2012
Assume your app id is myapp and your google apps domain is Create a domain group in your apps domain with an email address of your choosing (ie Add to the group as a member. Now when an email is sent to it will be forwarded to I have tried this and it works, but I can't remember if you are able to get the original email address from the incoming email handler.
Jul 3, 2012
That's a solution.
But the problem is I need some sort of "wildcard" forwarding (see comments above), while preserving all the original headers... Since we can manage incoming mail to, and also from the Google Apps service for the custom domain, I can't imagine why not combining the two and easily get the requested feature.
Jul 3, 2012
Email Group in Google Apps is not equivalent of e-mail address.

Email Group applies extensive spam filtering, i.e. you will be getting not all e-mail sent to Group address.
Jul 3, 2012
@myroslav correct. hence i said "you can kind of get around it"
@andreco - you can [kind of, again] do the same thing with a google apps user account. If you create an account with a meaningless, generic name such as, you will find that you can embed random text to the username ‘+’ sign (for example Then you can set up a GMail filter to auto forward to your App Engine and handle the mail there. But again, you probably lose the original email headers. Not a solution, but an idea ...
Aug 21, 2012
I think google should simply provide some MX DNS records just as it provides CNAME .
Aug 25, 2012
There is no  DNS / Email provider to support wildcard forwarding. The only workaround is to use the email tag to identify the email sender/receiver but of course it sucks as that doesn't look pretty. . I'm wondering if there is any ETA for this issue, at least in years not months or weeks.
Sep 6, 2012
Project Member #29
(No comment was entered for this change.)
Labels: Component-CustomDomains
Dec 7, 2012
And how does it retrieve
Feb 10, 2013
I've been waiting for a long time on this feature, please get working ASAP.
Mar 28, 2013
Please update on the status of this request.  Google App Engine in possibly the most important technological innovation in the last couple years, enabling unprecedented ease in the creation of applications that improve the quality of life globally, and this is to my knowledge the last glaring shortcoming.
Aug 8, 2013
It would be really great to implement this. I currently have to setup a catch-all forwarding on my webhoster - but the whole purpose of "scaling" is gone, as I don't want to build a dedicated fault-tolerant email-server myself - this is what Google App Engine is for.
Aug 27, 2013
Here are two workarounds:

1) Your domain name registrar may allow catch-all mail forwarding. For instance, allows catch-all email forwarding. You can thereby forward all mail to your app and process accordingly. The drawback of this method is that the forwarding takes, from my experiment, ~7 minutes with namecheap. Additionally, Google might eventually blacklist the server your registrar is sending mail from, if it is forwarding a lot of spam to a Gmail account. (E.g. if is sending mail to, and the registrar under is forwarding mail to a Gmail account, Google may blacklist the registrar's server.)

2) You can have instantaneous catch-all forwarding by using Google Apps. (Google Apps is, confusingly, a separate service from Google App Engine.) Setup is simple, and Google Apps will walk you through it: you verify ownership of your domain, and you change the MX records with your domain registar to point to Google's mail servers. Then you enable catch-all in the Google Apps' Gmail advanced settings -- it requests that you create a separate account to receive catch-alls, but you can use your main account. Now you'll be receiving all mail from in Google Apps. Finally, from your Google Apps mailbox's settings, you can enable mail forwarding to wherever you please, and you're done. The drawback of this method is that using Google Apps' will run you $5 per month.
Oct 9, 2013
namecheap and most of the providers (e.g. google apps) offer such features for personal usage (e.g per user) . Don't expect to receive a significant amount of emails and use the service of these providers. Sooner or later your account will be suspended or just stop working. Not to mention the SPAM filters or reliability. Such solutions should not be even proposed unless they target a pet project.
Sign in to add a comment

Powered by Google Project Hosting