Exchange 2003 NDR

chelpoolunited used Ask the Experts™
Hello All,
Some of the exchange users at my location are complaining anout the nod-delivery of the mails with following error.

the following recipient(s) could not be reached:
on 5/25/2009 12:20 PM
You do not have permission to send to this recipient.  For assistance, contact your system administrator. < #5.7.1 smtp;554 5.7.1 This message has been blocked because the return email domain is invalid.(failed to obtain DNS record for domain>

But the thing is that they do not get this error every time they send a mail. They face this issue only for some remote domains. I have verified and found  A, MX and PTR records for my mail server are in place. One thing that is troubling me is internal FQDN of my mail server is "" whereas external FQDN for mail server is "". The MX record visible to the world is obviously pointing to "" but corresponding PTR record is pointing to "". It seems the setup was done this way because we had standard naming convention for servers but our DNS hosting service provider does not allow Hyphen to be present in the A record. So, external FQDN was different from internal. Please let me know if it has anything to do with this problem! If not then what can I do to get it resolved.
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
So from external (Internet), is a valid DNS entry?
It may caused by those remote domains are doing revers-look up and found your PTR record ( not valid.
1)Are you hosting your own dns for the outside world?  Or Is the dns being hosted by domain provider/web hosting provider?

Your external domain is
Your internal domain is
Your email address space is
Your server is ""
Your external mx is ""

Bascially your external matches your internal domain name.

When you said that these recipient getting NDR, are they sending internally?

As far as I know, as long as you're sending internally exhange doesn't need any dns-lookup -- it's internal delivery.  If you're sending out to the internet and you're getting a rejection -- You may need to create a rDNS.  You may have to contact your ISP to create this for you.  The rDNS should be the for the FQDN


@flyingsky: For external world i.e. from internet is not a valid DNS name because my domain hosting service provider does not allow hyphen in A record.

@LANm0nk3y: The dns is being hosted by domain provider/web hosting provider for me. NDR is recieved only in case of some of the remote domains. No problem whatsoever for internal mail communication.
My external domain is
My internal domain is
My email address space is
My internal FQDN is
My external MX is
All you have said is right. So your suggestion is to point the rDNS to instead of

(The reason for rDNS pointing to instead of is, initially when this setup was done rDNS was not in place and then our admins started recieving complaints about NDR dur to reverse lookup failure and NDR used to show it as

Please guide!!! Thanks for your prompt response!!!
Ensure you’re charging the right price for your IT

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

yes rDNS is used to counter spams.  Many antispam box will not allow mail as soon as it performs Reverse DNS lookup and it fail to find one.  As long as you have a valid rDNS for the IP your mail is going out through, you should be find.  If you're sending out through, the the ip that it's translated outside has to have a rDNS entry.

For example:  If =, but the translated ip is (your valid ip on the internet) then your rDNS should be for that address.  If you're simply port-forwarding your 25 port, then it's most likely that your WAN ip is the one you should have rDNS for.

You didn't quite answer my question as far as your recipient receiving NDR -- were they sending to external mail or internally?
You just need change the PTR to


@LANm0nk3y: Users were sending mails externally. No problem whatsoever in internal mail communication.


After checking the headers of the delivered mails we found that the headers said the mail was recieved from "". It was a problem with masquerading. We changed that to and then we also changed the PTR record in order to point to It seems to be working fine now but we will be observing it for next 2-3 days. I ll let you people know then! Thanks for all the help you have provided!!!!


The problem has been solved. Thanks for the help!!

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial