550 5.7.1  Exchange 2003

dlabbadia01 used Ask the Experts™
500 pts because it's an emergency.

I have an Exchange 2003 Enterprise server.  I recently migrated a mail domain from a decommisioned exchange environment to this server and added it to the recipient policy.  Internal users can send to this domain, but external senders receive the following:

Sorry, we were unable to deliver your message to the following address.

Remote host said: 550 5.7.1 Unable to relay for myname@mydomain.com [RCPT_TO]

--- Below this line is a copy of the message.

Received: from [] by n59.bullet.mail.sp1.yahoo.com with NNFMP; 17 Jul 2009 16:13:17 -0000
Received: from [] by t1.bullet.sp1.yahoo.com with NNFMP; 17 Jul 2009 16:13:17 -0000
Received: from [] by omp205.mail.sp1.yahoo.com with NNFMP; 17 Jul 2009 16:13:17 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 171487.24112.bm@omp205.mail.sp1.yahoo.com
Received: (qmail 30503 invoked by uid 60001); 17 Jul 2009 16:13:16 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1247847196; bh=5sdnqqu2eO1NP7T1yRk8Vav5c59kEJVwXpTxmPCAEPk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=NG9bEjybu09h7I8GHG8aHIpDgdMwzAcLhaArh8nZ+IWIjMCORYKkiq3qXmf6ojndvpZU5nKH3K55pFlmUOxJKhPK5FUXJWiaxLmBi9RRET47GDhZKqq76DHtacvscQKQQQTKZGloGc1vG+vMw2BCIP482Y63R47FhhwLRbMEdVI=
DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
Message-ID: <866201.30496.qm@web43516.mail.sp1.yahoo.com>
X-YMail-OSG: IQZma5UVM1mMVXLP4HsxWOyKlhvpdwYy2jxEWjHvyCE2XPgQnlGcig3phGl_R9SEoQDoHz_uM.zykrr6XfRuJytbLLYdwEqPxfUu.Ngt03.W9ppp9w7X_Nfm_yBJya1S909qsS2YeaaK0Sp7M7Sz7TkTgh9AHe2TrO0QtSmidiePGB9yeBERQzblU9hIlFUMAmaxN9u.u9GR2BTI7PsvcQ1AaTdvZIGskX6xozRDHq5LShb6UQfYQZ0BHRy7V4Rbg2aTCYQ-
Received: from [] by web43516.mail.sp1.yahoo.com via HTTP; Fri, 17 Jul 2009 09:13:16 PDT
X-Mailer: YahooMailClassic/6.0.18 YahooMailWebService/
Date: Fri, 17 Jul 2009 09:13:16 -0700 (PDT)
From: My Name<myname@yahoo.com>
Subject: FAH Q
To: myname@mydomain.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Are your MX records setup correctly? Pointing to this new server?

Use mxtoolbox.com to check MX record, telnet the MX record and try sending a test email
Basic telnet testing to ensure mail can reach a destination mail server.
Note you cannot use backspace or delete when using telnet, if you make a spelling mistake, start the command again after the error is generated.
Note you should use < > around email addresses as some email servers will not accept email addresses unless they are enclosed in <   >
1) Use mxtoolbox.com to find the MX record of the mail server at your chosen destination. So to find the mailserver for bbc.co.uk, type bbc.co.uk in the MX Lookup box.
make a note of the hostname (or one of the multiple hostnames) returned.
2) Log onto your Exchange server and open up a command prompt.
Type the following:
[Wait for 220 response]
[Wait for 250 response]
[Wait for 250 response]
[Wait for 250 response]
[Wait for 354 response]
This is a test message
(note the dot on its own to end the session)
You should now get a message that the email has been queued for delivery.
Destination and RCPT in your case is Your domain. Mail from is an external user email address such as yahoo or gmail
Success in ‘20 With a Profitable Pricing Strategy

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!


SMTP shows this so i think it's reaching ok.  i will run the other tests

2009-07-17 16:13:17 n59.bullet.mail.sp1.yahoo.com SMTPSVC1 EXC-DC2-00 0 HELO - +n59.bullet.mail.sp1.yahoo.com 250 0 47 34 0 SMTP - - - -
2009-07-17 16:13:17 n59.bullet.mail.sp1.yahoo.com SMTPSVC1 EXC-DC2-00 0 MAIL - +FROM:<myname@yahoo.com> 250 0 44 31 0 SMTP - - - -
2009-07-17 16:13:17 n59.bullet.mail.sp1.yahoo.com SMTPSVC1 EXC-DC2-00 0 RCPT - +TO:<myname@mydomain.com> 550 0 59 37 0 SMTP - - - -
2009-07-17 16:13:17 187-10-24-174.dsl.telesp.net.br SMTPSVC1 EXC-DC2-00 0 QUIT - 187-10-24-174.dsl.telesp.net.br 240 922 69 4 0 SMTP - - - -
It sounds like the MX record is sending external mail to a server that is not authoritative for the new domain name. That's why Internal users don't have a problem, because the mail gets sent to the exchange server using MAPI where it finds the server is authoritative for the mail, instead of external users who must use SMTP and DNS to find the server.  

You might have a telecommunications issue. You gave away your external IP in that commend snippet and I tried pinging, came back with (i've starred some of this):

Pinging 174.**.10.*** with 32 bytes of data:
Reply from 67.**.237.**: Destination host unreachable.
Request timed out.
Request timed out.
Request timed out.

When adding the new domain to the recipient policy, did you set it up as the authoritative server for the domain by checking the "This Exchange organization is responsible for all mail delivery for this address" checkbox?
Can you do the telnet test from outside, do you get the 550 response? I don't know if that IP I retreived is correct or not.



here's MX tests at that site.  Everythign was green but look at the bottom:  Note the part that says Reverse DNS Check mentionis "mail.mydomain.com" but my MX record is mail01.mydomain.com.  Will this matter?

220 EXC-DC2-00.dc2.local Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at Fri, 17 Jul 2009 12:29:27 -0400
Connect Time: 0 seconds - Good
Transaction Time: 0.266 seconds - Good
Relay Check: OK - This server is not an open relay.
Rev DNS Check: OK - resolves to mail.mydomain.com
GeoCode Info: Geocoding server is unavailable
Session Transcript: HELO please-read-policy.mxtoolbox.com
250 EXC-DC2-00.internaldomain.local Hello [ [62 ms]
MAIL FROM: <test@mxtoolbox.com>
250 2.1.0 test@mxtoolbox.com....Sender [62 ms]
RCPT TO: <test@mxtoolbox.com>  
550 5.7.1 Unable to relay for test@mxtoolbox.c [78 ms]


Shaun that IP your using doesn't even look close to the one on my server.  
No, sorry my bad. Your server is responding fine, but not accepting for your new domain. Follow hypercats suggestion. Try restarting Simple Mail Transer protocol service for good measure, but shouldn't really need to do this.

EXC-DC2-00.dc2.local is the correct server yes?


that is the internal server name shaun.

hypercat, that option is checked off for that domain.
Do you have any other device or software doing a virus or Anti-Spam check infront of the Exchange that you need to add the new domain to allow relay.


talla, I have symantec mail foundataion for exchange with anti spam but i do not configure relay options for it.  i will double check to be safe

does it matter that my mx record is mail01.mydomain.com
but my reverse ptr record at my isp is mail.mydomain.com

I think you have three problems.  
One is that your MX record points to mail01.yourdomain.com, but when I do an nslookup on your public IP address, it resolves to mail.yourdomain.com.  You need to change the host name on that IP address to match your MX record.  There may be a problem with the DNS hosting company's servers, where one of them has the wrong host name, or something like that.  
The second problem is that your server is advertising itself with its internal FQDN (EXC-DC2-00-dc2.local) rather than the public FQDN of mail01.yourdomain.com.  This will sometimes cause problems receiving mail from large ISP's like Yahoo, AOL, etc.  
Third, your reverse DNS entry points to an entirely different domain name than your MX and A records for that IP address. This could be the one problem that is causing the particular failure message your getting - the "relaying denied" - as it is being seen as belonging to an entirely different domain on the reverse lookup.
Actually, I did a more thorough lookup of the reverse DNS entries, and it appears that there are 3 PTR records for your IP address.  None of them points to "mail01", all of the point to "mail" at the various domains. So, this is still a problem.
As hypercat stated above may lead to problems sending and receiving mail from some sources. You need to add the new domain to the Symantec software as it only allow mail in for the domains listed.



very helpful indeed.  right now this is how i have DNS setup

A record = mail01.mydomain.com
MX record = mail01.mydomain.com
PTR record = mail.mydomain.com

would this be resulting in your nslookup issue?

i just sent a request to my ISP to add a PTR record for mail01.mydomain.com for it's IP.  

as far as the second problem, how do i change how it advertises?

Depending on the version of Symantec select the admin tab on the left and you will see the entry for your existing domain in system settings.


tallafornia, do you know where that setting is located?
To fix the name advertised by your email server, open the Exchange System Manager, and do the following:
  1. Navigate to the Server\Protocols\SMTP\Default SMTP Virtual Server object.
  2. Right-click on the Default SMTP Virtual Server and click Properties.
  3. Go to the Delivery tab, and click on the Advanced button.
  4. In the Fully Qualified Domain Name field, type the public name of the server (i.e., "mail.yourdomain.com").
I'm getting some weird results doing an nslookup on that IP address. Sometimes I get "mail.yourdomain.com" and sometimes I get "mail01.yourdomain.com."  I'm beginning to wonder if there's a problem with the public DNS records for your domain.  I would definitely advise cleaning up the DNS records for each domain so that there is only one A record for each domain for that IP address, and your MX record for that domain points to that A record.



right now that option is unchecked with NO domains listed in it.  it leads me to believe that is not the problem because the other two domain this exchange org is responsible for work fine...



you may be seeing mixed nslookup results because i just added the new PTR record for mail01.  So now there are two PTR records for that domain at my ISP.  

on my DNS server however there is only a single host record for mail01 and a single mx record for mail01.  i think that part is fine.

so in resolving this, should i

a.  remove the PTR record for mail.mydomain.com
b. add a host record for mail.mydomain.com and an associated mx record with a lower value than mail01?


i was just reading somewhere that in the recipient policy i need to CHECK the box next to the domain in order to receive mail.  i was under the impression the check was just if you wanted it to apply to new users.  is this true?  right now it is unchecked.
Use whichever name you want, just be sure to use only ONE of those names and make sure that the host and rDNS records are both pointing to the same server name. You don't want to have two host names and two MX records for that domain, both pointing to the same IP address.  It's unnecessary and will just confuse things.


i'm sorry for being overly questioning but i want to make sure, seeing it's production that i'm doing the right thing:

right now for that domain I only have a single host record for that domain as follows:  

mail01.mydomain.com A
mail01.mydomain.com MX
mail01.mydomain.com PTR (just added 10 minutes ago)
mail.mydomain.com PTR

that being said i can see the confusion here.  what is strange though is i have this EXACT same scenario set up for two other domains that are working.  what could be causing the difference i would really like to know...
I'm not sure which box you're referring to.  Look at the attached screen captures - this is the way it should be.

There is a lot of talk here that is completely not true. Here are some facts:

1) You can only have 1 PTR record for an IP address. It is impossible to have more than 1.
2) Your PTR record does not have to match your MX record at all, this is not a requirement.
3) Your PTR record does not have to include the domain name of your email.
4) The PTR DOES have to be a fully qualified domain name ie: hostname.domainname.com and so might as well be the same as your MX record for neatness but this IS NOT responsible for the problems you are seeing.
5) Your SMTP virtual server is displaying the internal name of your server and it should not be. It does not usually case problems with you receiving mail though, there are millions of servers that display a local name here, as this is what exchange does out the box. By all means change it but it will not be causing the issue here.

If the mail server that is supposed to be receiving mail is EXC-DC2-00-dc2.local then the problem is that that server does not believe it is responsible for Accepting mail for this second domain. Simple as that really. Double check the recipient policy for it.

As long as you have the PTR record that you just added, pointing to the same name as your A record, you should be fine.  All I was saying is that you don't need the PTR record for mail.mydomain.com because there is no associated A record. The only time a PTR record is referenced, in terms of email servers, is when a receiving email server does a rDNS query to confirm the identity of the sending email server.


seriously, adding a checkbox next to the domain in the recipient policy fixed the problem.   to me this makes absolutely zero sense.  i have other domains without check boxes that work fine.   someone enlighten me please...


and by box i mean the one on the recipient policy properities, not the authoritative one, that one i had checked already.
@shauncroucher - I would have said the same thing as you did in #1 of your comments, except that I just did an nslookup for the PTR record for his IP address and got this response from DNSStuff.com (I've masked part of the IP address and the domain names):
The reverse DNS entry for an IP is found by reversing the IP, adding it to "in-addr.arpa", and looking up the PTR record.
So, the reverse DNS entry for *.*.115.201 is found by looking up the PTR record for
All DNS requests start by asking the root servers, and they let us know what to do next.
See How Reverse DNS Lookups Work for more information.

How I am searching:
Asking d.root-servers.net for 201.115.*.*.in-addr.arpa PTR record:  
       d.root-servers.net says to go to z.arin.net. (zone: 216.in-addr.arpa.)
Asking z.arin.net. for 201.115.*.*.in-addr.arpa PTR record:  
       z.arin.net [] says to go to ns1.cervalis.com. (zone: 115.*.*.in-addr.arpa.)
Asking ns1.cervalis.com. for 201.115..*.*..in-addr.arpa PTR record:  Reports mail.domain1.com. [from *.*.111.24]

*.*.115.201 PTR record: mail.domain1.com. [TTL 86400s] [A=None] *ERROR* There is no A record for mail.domain1.com. (may be negatively cached).
*.*.115.201 PTR record: mail.domain2.com. [TTL 86400s] [A=*.*.115.201]
*.*.115.201 PTR record: mail.domain3.com. [TTL 86400s] [A=*.*.115.208] *ERROR* A record for mail.domain3com. does not point back to original IP (A record may be cached).
*.*.115.201 PTR record: mail01.domain1. [TTL 86400s] [A=*.*.115.201]
*.*.115.201 PTR record: mail01.domain3.com. [TTL 86400s] [A=*.*.115.201]

You have more than one PTR record for *.*.115.201.  This is legal, but most programs will only use
the first PTR record listed (which may vary).  Best practice is to have just one PTR record.


Also the reason I have the internal server address advertised instead of an external name resolution is because this server serves the purpose of delivering mail for several business entities.  that being said i woudln't want anything in the header to be inclusive of only one of the entities domains.  so i use a generic.

i was hoping to avoid this by making multiple PTR records as well such as


but from what i can tell the request simply get round robbined.  this kind of stinks in reality because it associates businesses i don't want associated.

any solutions would be very great.  

also if you have any ideas about why simply checking that box fixed my problem i'd love to hear it.

thanks in advance you guys have been great.
The description for the checkbox is as follows:

"Use this list box to view the e-mail addresses that will be generated for members of a recipient policy, as well as the e-mail address types available in Microsoft Exchange 2003 Server. If the check box next to an e-mail address type is selected, the e-mail address that corresponds to that e-mail address type is currently being generated for the members of a recipient policy. If the check box next to the e-mail address type is cleared, the corresponding e-mail address is disabled and is not being generated for the members of a recipient policy.

In this list box, select the address type you want to create, or select the address you want to modify.

Once the addresses have been applied to the recipients accounts, they will not get removed by unticking the policy. This means that if the policy has ever had the tick applied, then existing recipients will have the proxy address. If the tick box has never been ticked, users will never get the proxy address.



right, so how does that have anything at all do to with fixing my problem which it did instantly.  
Just use one PTR record and ensure it points to your primary hostname. mail.externaldomainname.com and this is absolutely legal and correct and will not cause any problems when sending/receiving for your other domains.

As for the SMTP banner, the ONLY requirement is that it is a fully qualified 'externally resolvable' domainname. Just use the same fqdn that you are using for your PTR record and that will be fine.

The reverse DNS (rDNS \ PTR) record is configured by the people who issued your IP address in most instances (so your ISP).
Below are two articles which explain the general requirements for reverse dns (rDNS\PTR) records for your IP address.
I try to adhere to the following when setting up a rDNS (PTR) record:
Be a Fully Qualified Domain Name (FQDN) such as server.domain.com (not just 'domain.com' or 'server').
Should not contain 'in-addr-arpa' and should not include words like pool or dyn etc.
Should match what you use in your SMTP HELO\EHLO hostname (as some mail servers will check that the IP address of the SMTP TCP session matches who you say you are in your EHLO statement).
For neatness and as a good rule of thumb, if your incoming mail is delivered to the same server that you use for Outgoing you should make sure all the following FQDN's match:
MX record
rDNS (PTR) record
SMTP EHLO hostname
http://www.amset.info/exchange/dnsconfig.asp (Courtesy of EE member Mestha)
On the tick box:

I can only assume that the other domains you say have not got a tick next to them HAVE HAD A TICK AT SOME STAGE, because otherwise your recipient objects would not have SMTP proxy addresses for the domain name.

This one that you have had trouble with today HAS NEVER HAD TICK BOX TICKED (correct?) meaning the recipient objects were not updated with the SMTP address.

I have done some lab testing and I have tested the tick box. Even if it is UNTICKED, mail is accepted by the exchange server, but of course, there will be no valid recipients because none of the recipient objects will have the proxy until I tick the box.



i just tried unticking the box after successfully receiving mail while it was ticked and got an instant kickback.  i'm curious to know if it's because i manually added email addresses with this domain name onto peoples mailboxes BEFORE adding it to the recipient policy and then choosing "do no update people with this change blah blah" when i actually went ahead and did.  perhaps it's just mismatched and it doesn't really believe they are associated.  i'm still somewhat stuck in a bind because i need to keep this domain checked, yet i don't want every new user to get this domain.  oh well.  i'll keep you informed on my progress thoughout the day if anything new comes up.   both of you guys will be receiving points as it's been quite productive thread.
There is a time delay applying the domain so it is 'Authoritative' if you don't run 'Apply policy now'. I always do this (force of habit with 2003). This could be the problem here though. Even if unticked (to not polulate recipient objects), the Recipient policy will not apply for some time, unless you Right click and Apply now?



yeah i ran a RUS.  figured that was fine.  i just didn't want this domain spit out to all the people that the check box to update when the recipient policy updates.  it's only for a unique set of individuals.  i need to just build a second recipient policy with a query based on a custom attribute but i was trying to put out the fire first.

thanks guys i'll consider this resolved but will leave open for a few more hours in case somethign comes up
Yes, it's been a good thread.

Windows 2003 is notorious for not applying Recipient Policy changes immediantly, causing mass confusion. In Exchange 2007 the changes are applied instantly which is a much needed change.

Exchange 2007 also seperates out the two concepts of Accepted domains and email address policies because they really are two different features. Adding the domain to the Recipient policy UNTICKED is like telling Exchange it is responsible for a domain.

Ticking is like telling Exchange to go create an email address based on the alias (or custom properties you specify) for the domain name.

In other words, it is perfectly acceptable to have the domain name listed without a tick box, and this should do what you desire. Just remember to tick the Apply policy now!

I'm fairly certain that i can turn this domain on and off by simply unticking it.  There is somethign more going on than the recipient policy.  About two weeks ago I manually added address on some peoples account for this domain. Then a week ago i added the domain to the recipient policy and intentionally left it unticked because i didn't want anyone else getting this domain applied (new or old).  it's been a week and email was still not coming in to the domain (little did i know).   so while we started discussing i found a thread that said ticking that box allowed for mail delivery.  so i ticked the box, and choose No to the question of "Address generation for smtp has been enabled for all newly created Recipients.  Do you want to automatically add this Address Type to all existing Recipient E-mail addresses".  This instantly solved the issue.  I then, for testing purposes went back an unticked and choose apply and it immediately stopped mail delivery for this domain.  So i reticked, chose No and it immediately worked again.  I'm not even sure it's RUS related.  I'm going to leave it ticked for the weekend and untick Monday to prove or disprove this  theory.

Does this make more sense as to what i'm experiencing?
Yes, it does sound very odd that. In my test lab if I untick the domain and Apply policy now, I still get a 2.1.5 response on a basic telnet test when using that domain as RCPT TO. This means the server will accept the mail happily (of course it would NDR once accepted because there are no recipient objects with the proxy address added) but nonetheless Exchange believes it is authoritative for the domain.

Do you have a test environment you can use to see if you can replicate the correct operation of this feature?



unforutnately i just tore it down two days ago.  i use vmware so i can easily deploy a development scenario in the next week or so.  i just took your recommendation and answered YES to that option about adding it to all existing mail recipients.  i don't mind going through and manually removing them monday i just wanted to see if that option somehow forced a relationship with the accounts.


After the weekend, i tested email to the d omain in question and it was being received correctly.  I went into ESM, modified the recipient policy to untick the box next to the domain in question and tested mail delivery again.  mail immediately got returned with unable to relay error.

this is blowing my mind how that check box can make a difference in mail delivery.  

You aren't going to assign any points?


i'm trying to.  i can't figure out how to accept my own solution because that's what fixed my problem but give you guys the points.  it won't let me.  i can only issue points to you guys if i chose your solution.  so feel free to just type in my solution and i'll give you all the points.
I'm pretty sure you should be able to select your solution and then choose "Split Points" to assign points to both yourself and us.


I need to give these guys some points and i can't figure out how to divide them up.  As soon as I select my solution it does not allow me to divide the points.


i can either "Accept As Solution" for my solution and you get no points, or "Accept and Award Points" whjich removes any of my posts that contain the solution that worked for me.  So I guess I'll just split them up between you guys.  Thanks for all your 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