We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you two Citrix podcasts. Learn about 2020 trends and get answers to your biggest Citrix questions!Listen Now

x

Fowarding account on a subdomain

Medium Priority
706 Views
Last Modified: 2012-05-06
Hi
I have set up a sub-domain (sub.ourdomain.net) 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 (@domain.net) to this trial account (@sub.domain.net).

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 user@sub.domain.net"

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

Hear from you soon
Comment
Watch Question

Author

Commented:
or has InterScan MSS Notification got somethign to do with it?
Jian An LimSolutions Architect
CERTIFIED EXPERT
Top Expert 2016

Commented:
my question will be the mx record

tell me what is your mx record for sub.domain.net

regardless of your current domain.net, it should send the email to sub.domain.net not domain.net


try to get it from http://www.mxtoolbox.com/ 

Author

Commented:
Hi, limjianan

The MX records for the subdomain are:
Preference      Host Name      IP Address      TTL              
10      aspmx.l.google.com      209.85.217.44      21600            
20      alt2.aspmx.l.google.com      209.85.201.114      21600            
20      alt1.aspmx.l.google.com      74.125.45.27      21600            
30      aspmx5.googlemail.com      74.125.45.27      21600            
30      aspmx4.googlemail.com      66.249.93.27      21600            
30      aspmx3.googlemail.com      209.85.199.27      21600            
30      aspmx2.googlemail.com      209.85.135.27      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 Architect
CERTIFIED EXPERT
Top Expert 2016

Commented:
okay.

but that's going to be odd.

The external sender also receives a message "550 5.7.1 unable to relay for user@sub.domain.net"

do you mean let's say a gmail account user cannot send email to user@sub.domain.net?

or external sender receive a message of above when he send to user@domain.net and get the above message?



by default, user should able to send and receive email if he go in to user@sub.domain.net




If this is the case, you need to work for your internal @sub.domain.net as the internal DNS might have some issues ..

Author

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 user@domain.net and get the above message?).

What I mean is this:
  1. An external account (say, hotmail or gmail) emails me@domain.net
  2. Our Exchange Server is 'supposed' to forward this on to me@sub.domain.net (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 domain.net)


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

Hope this helps
Thanks again

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

Open in new window

Solutions Architect
CERTIFIED EXPERT
Top Expert 2016
Commented:
try this.
on your exchange server
can you try to run command

nslookup
set type=mx
sub.domain.net



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..

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts
Jian An LimSolutions Architect
CERTIFIED EXPERT
Top Expert 2016

Commented:
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

Author

Commented:
Hi
Sorry I've not been in touch...staff disruption!
Will be in touch v. soon

:)

Author

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


The NS lookup from our front end Exchange server showed 212.53.89.138 - this relates to the A record for sub.domain.net (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
Thanks
stillspangle


Jian An LimSolutions Architect
CERTIFIED EXPERT
Top Expert 2016

Commented:
the problem lies in exchange server for sure.

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

you can also try to send email from <username>@domain.com to <username>@sub.domain.com 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.


Author

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.
stilspangle

Jian An LimSolutions Architect
CERTIFIED EXPERT
Top Expert 2016

Commented:
i just check with google apps, it seems it has something like this

http://www.google.com/support/a/bin/answer.py?hl=hr&answer=96855

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.

Author

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 sub.domain.net to behave as if it were a completely independent domain (e.g anotherdomain.com) 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. user@sub.domain.net rather than user@anothersimilardomain.net


I still really appreciate the fact that you kept monitoring this question despite my long absence from contributing to it.
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?

Author

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. sub.domain.net, www.sub.domain.net) including mail.sub.domain.net that all pointed to the same IP (212.xxx).

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
Stilspangle

Commented:
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....

Author

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.
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.