PTR DNS record question


I am running Exchange 2003 SP 2 on Server 2003 SP2

On my server if I do a nslookup -q=MX
It comes back with:  internet address =

In ESM, if I go to 'Default SMTP Server -> Delivery -> Advanced
it tell me the fully qualified domain name is (not
I set it up on purpose this way because I was transitioning from an old mail server that already had that name.

The mail server has been running very well for the past few weeks.
However the other day I got a bounce back from an outside domain I was trying to send it. The error was:
Diagnostic-Code: smtp;554 5.7.1 : Client host rejected: ACL mta_clients_dict_arch_ip
I assumed this was some type of blacklist thing, but when I contacted the mail admin at the problem domain he told me otherwise.

He said because the FQDM set up in SMTP was not the same as the FQDM my MX record was pointing to, my server was rejected.

The PTR record that my Server company (Rackspace) has set for my server on their DNS servers is correctly pointing back to my new mail server. The name on the PTR record is the same name FQDM as is showing in ESM above.

I always thought that the name the PTR record referenced just needed to be the same name the server broadcast itself, which in this case it is.

So, I have a few questions.
1. Was I correct in this assumption? Is this outside mail server I am connecting to that is throwing the errors just being really picky or will I have this problem with other mail servers in the future if I don't change things on my end?
2. In order to change this, do I just have to change the name in ESM (Default SMTP Server -> Delivery -> Advanced) and then have my Server company change the PTR record on their DNS server? Or is there something else I need to change or have changed anyplace else?


Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

the FQDN mentioned there should be always  Your COMPUTERS FQDN [properties of My computer->computer Name]
or what ever u want there as the FQDN you need to have a host record for the same on your local dns server.
hence when you do:
which domain are you not able to send mail? [which gave that error?]
lets say that the remote domain is ABC.COM

set q=mx

does this give the remote domain's MX Properly with the IP  address?

then open a different command prompt and do this

telnet MX /IP 25
does this connect or drop?
Jamie McKillopIT ManagerCommented:

"the FQDN mentioned there should be always  Your COMPUTERS FQDN [properties of My computer->computer Name]"

The above statement is incorrect. The FQDN on Default SMTP Server -> Delivery -> Advanced should match the external DNS record you have setup for the external IP of your exchange server. This is usually not the same as the internal FQDN of your Exchange server.

You need to setup an A record and PTR record for your external FQDN. Your problem is likely that you don't have a proper FQDN, you just have the domain portion but no server portion. Pick a proper FQDN (ie, have the corresponding A and PTR records created, then change the FQDN on your Default SMTP server to match.

"He said because the FQDM set up in SMTP was not the same as the FQDM my MX record was pointing to, my server was rejected. "

If the above statement is true and they have their system setup that way, it is setup incorrectly. There are many Exchange Admins (including myself) that setup separate inbound and outbound mail servers.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

michaelshavelAuthor Commented:

Thanks, I realized that statement that you said was incorrect was indeed incorrect. I was waiting to see if anyone else posted.

The problem was that my SMTP banner name did not resolve to the IP of my mail server. My smtp banner however WAS the same as my PTR record.
My hostname was:
My PTR record was:
My IP address for my mail server resolved to

Once I changed my hostname to and my PTR record to, everything was fine for this particular server my mail server was trying to send mail to.
i was told that he (the other server) was doing a 'three way check' and that's why my server could not connect.

So, does that all make sense to you? Was the other mail server set up incorrectly or was he correct in having me change things so my banner?

The problem is fixed now, I am just curious if this is SOP in a mail server or does he just have his server set up to be really 'picky' as to who will connect to it.

Jamie McKillopIT ManagerCommented:
All that is required for a sending mail server is an "A" record (hostname) and a PTR record that both match. You do not need an MX record for a sending server. Anyone who sets up their system to reject mail due to the absence on an MX record is going to end up rejecting a whole lot of legitimate email.

michaelshavelAuthor Commented:
Ok, thanks very much.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Email Protocols

From novice to tech pro — start learning today.