Fowarding account on a subdomain

I have set up a sub-domain ( and I am trialling Google Apps on it (with 1 account so far).

I have had a forwarding account set up on my Exchange mailbox ( to this trial account (

I can send from both accounts but the forwarding does not seem to be working at all.  More bizarrely, any external email (i.e. outside either domain) sent to my Exchange account results in some odd behaviour:

1) I receive the email at my Exchange account
2) It is not forwarded onto my subdomain account
3) The external sender also receives a message "550 5.7.1 unable to relay for"

Is this related to the fact it is a subdomain account and Exchange is getting all upset?

Hear from you soon
Who is Participating?
Jian An LimConnect With a Mentor Solutions ArchitectCommented:
try this.
on your exchange server
can you try to run command

set type=mx

can you tell me the result?
i wonder where is it pointing to.

i wonder when the exchange server pick it up as it own and decided not to forward it to outside but look inside..
stillspangleAuthor Commented:
or has InterScan MSS Notification got somethign to do with it?
Jian An LimSolutions ArchitectCommented:
my question will be the mx record

tell me what is your mx record for

regardless of your current, it should send the email to not

try to get it from 

Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

stillspangleAuthor Commented:
Hi, limjianan

The MX records for the subdomain are:
Preference      Host Name      IP Address      TTL              
10      21600            
20      21600            
20      21600            
30      21600            
30      21600            
30      21600            
30      21600

These are defined by Google.

The MX records for the principle domain are a couple pointing to Messagelabs

Hope to hear from you soon
Jian An LimSolutions ArchitectCommented:

but that's going to be odd.

The external sender also receives a message "550 5.7.1 unable to relay for"

do you mean let's say a gmail account user cannot send email to

or external sender receive a message of above when he send to and get the above message?

by default, user should able to send and receive email if he go in to

If this is the case, you need to work for your internal as the internal DNS might have some issues ..
stillspangleAuthor Commented:
Hi, limjianan
Thanks for your input so far.

It is the second part of your question that happens
(you said: or external sender receive a message of above when he send to and get the above message?).

What I mean is this:
  1. An external account (say, hotmail or gmail) emails
  2. Our Exchange Server is 'supposed' to forward this on to (which it doesn't for any type of incoming message, internal or otherwise)
  3. The sender in 1 above gets that 'unable to relay' message (see attached snippet)
(I just tried this with a gmail account to

If I send directly 'to' there is no problem.  I can also send 'from'

Hope this helps
Thanks again

****** Message from InterScan Messaging Security Suite ******
Sent <<< RCPT TO:<>
Received >>> 550 5.7.1 unable to relay for
Unable to deliver message to <>.
************************     End of message     **********************

Open in new window

Jian An LimSolutions ArchitectCommented:
also you can try to create routing connector
put in the smtp address into it
and tick allow messages to be relayed to these domains
stillspangleAuthor Commented:
Sorry I've not been in touch...staff disruption!
Will be in touch v. soon

stillspangleAuthor Commented:
Me've probably moved  on (quite rightly) but I'll update you anyway...

The NS lookup from our front end Exchange server showed - this relates to the A record for (set up in Netnames)

I'm having problems convincing my Network Manager that the problem isn't related to Google Apps but with the way our Exchange server is handling this subdomain email.

He is convinced the problem lies with Google (Apps).  I am not so sure but do not have the expertise to provde otherwise.

I hope you're still monitoring this question.  I have 'upped' the points, too

Jian An LimSolutions ArchitectCommented:
the problem lies in exchange server for sure.

if an external user can send the email to <username> , that means the internet handling it correctly.

you can also try to send email from <username> to <username> and it should failed to ..

so it is lies in exchange server handling the the email.
by default, since it is a subdomain email, exchange will think the email should flow internally not externally.

stillspangleAuthor Commented:
Thanks.  I passed on your comments to my NM who appears to be a little more receptive (I referred to your status in this cateogry!)

He has asked me how to make Exchange treat the subdomain messages as ones that should be delivered outside our domain.

I'm not sure if that's straightforward to answer, but hope to hear from you soon.

Jian An LimSolutions ArchitectCommented:
i just check with google apps, it seems it has something like this

and you are right, exchange should able to response correctly,

however, the error message is generate from InterScan Messaging Security Suite

I am thinking is more to the InterScan Messaging Security Suite issue?

I am not sure until now... let me request for more help here.
stillspangleAuthor Commented:
Hi again
Thanks, I've seen that article before.  I'm not sure that's what I'm looking for as I am not interested in Dual Delivery.  I was expecting to behave as if it were a completely independent domain (e.g and simply using Google Apps as the front-end for emails.  Does that make sense?

We had an earlier trial, with selected users, using our principle domain.  In this, we employed Dual Delivery where we had to update our MX records so that every email passed through Google and it 'simply' passed on the emails not provisioned in Google Apps onto our Exchange server (i.e. trial accounts got delivered to Google, others got forwarded on).  However, we were getting 'too many messages trying to be sent' errors and Google acknowledged it had an issue with this set-up.  This is well-documented in the Google Apps Admin Forum.

To revive the potential of using Google Apps, I set-up this sub-domain to preserve the domain quality of the accounts.  i.e. rather than

I still really appreciate the fact that you kept monitoring this question despite my long absence from contributing to it.
tntmaxConnect With a Mentor Commented:
So when you did an mx lookup from the parent domain server, it returned an A record of 212.xxxx instead of one of the gmail mx records. Did you manually setup this mx record in dns? Is the relay error coming from the exchange server or from gmail?
stillspangleAuthor Commented:
Hi, all
It appears that my NM has resolved this issue.  He told me that there were a number of A records (e.g., including that all pointed to the same IP (

Apparently, removing these was the answer.

If I assume he  is right, have either of you offered the advice for this solution?  I don't know enough to be sure that the advice you gave led to him solving this problem.

However, I am also much more than willing to offer these points (as a commensurate split) for your sheer endurance in helping me with this.

Hope to hear from someone soon so that I can end this question (for you, as much as me).
Kind regards
I'd be fine with a points split. I was going to say the next step would be to delete them as they were there manually....
stillspangleAuthor Commented:
I have used EE for a number of years now (back in the days when there was a free sign-up!).  This continues to be an excellent resources.

Thank you experts and thank you Experts Exchange.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.