Issues w/ Exchange and NAT on a Cisco PIX 501

I recently deployed an exchange server, and am getting some messages kicked back from large ISP's like AOL and comcast. Whenever the message gets kicked back, I get a message from the System Administrator that includes the following:

<xxxx01.x.CORP #5.5.0 smtp;521-EHLO/HELO from sender does not map to xxxx01.x.corp in DNS>

I am assuming this means that AOL is doing a reverse DNS lookup of the originating ip address and finding that it does not match the reverse DNS entry, and is classifying it as spam. That is easy enough, but the problem is that my mail should be originating from .123 which matches the reverse DNS entry.

My network is configured with my exchange server on the inside of the PIX with a static translation from to the .123 adress. I think the problems resides with another entry on my pix :

nat (inside) 1 0 0

As far as I can tell, this entry is translating all of my private address to the interface address of .122, which conflicts with the static translation referenced above, but is consistent with my problem. My two servers reside at .10 and .11, and my workstations use the range .100 - .255. I think I need to remove the NAT entry above, and replace it with one that specifies translation of the workstation range to a few public ip's .125 and .126, but I don't know how to write that command. Any help?
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.

>nat (inside) 1 0 0
  This is fine - don't remove it or your internal hosts won't be able to access the Internet!

>...with a static translation from to the .123 adress
   Hmm, doesn't appear to be, since you're getting the following:
>...from sender does not map to xxxx01.x.corp in DNS

Please post all "static (inside,outside)..." & "nat (inside)..." statements, with public IPs masked like so: x.x.x.123

Keith AlabasterEnterprise ArchitectCommented:
Can you check that you have a reverse dns entry for your domain (the MX record)?
AOL performs a reverse dns lookup and if this does not resolve to you, they will block/reject your mails. This is a fairly popular method of trying to del with spoof emailing.
brainboltAuthor Commented:
calvinetter: here are the statements.

global (outside) 1 interface
nat (inside) 0 access-list VPN-nonat
nat (inside) 1 0 0
static (inside,outside) tcp x.x.x.124 3389 3389 netmask 0 0
static (inside,outside) tcp x.x.x.123 www www netmask 0 0
static (inside,outside) tcp x.x.x.123 smtp smtp netmask 0 0
static (inside,outside) tcp x.x.x.123 3389 3389 netmask 0 0
static (inside,outside) tcp x.x.x.123 pop3 pop3 netmask 0 0


keith_alabaster: I had my isp setup a reverse dns entry for xxxx01.x.corp pointing to x.x.x.123. I believe that it is setup right because if I go to and do a reverse dns lookup for the .123 address, I get this response:

x.x.x.123 PTR record: xxxx01.x.corp. [TTL 3600s] [A=None] *ERROR* There is no A record (may be cached).
Prepare for an Exciting Career in Cybersecurity

Help prevent cyber-threats and provide solutions to safeguard our global digital economy. Earn your MS in Cybersecurity. WGU’s MSCSIA degree program curriculum features two internationally recognized certifications from the EC-Council at no additional time or cost.

Keith AlabasterEnterprise ArchitectCommented:

Reverse DNS entries for MX records
OK. The IPs of all of your mail server(s) have reverse DNS (PTR) entries. RFC1912 2.1 says you should have a reverse DNS for all your mail servers. It is strongly urged that you have them, as many mailservers will not accept mail from mailservers with no reverse DNS entry. Note that this information is cached, so if you changed it recently, it will not be reflected here (see the Reverse DNS Tool for the current data). The reverse DNS entries are: [TTL=3600] [TTL=3600]

The above is the result for my domain
Use the dnsstuff reporter. (
Put in your domain name in the left hand box and then scroll down the results. The above is what you should see (similar) for your MX records.

brainboltAuthor Commented:
keith_alabaster: I'm not sure I understand. I have a reverse DNS entry setup for my mail server, as shown by the response I posted from the test (x.x.x.123 PTR record: xxxx01.x.corp. [TTL 3600s] [A=None] *ERROR* There is no A record (may be cached)). Am I missing something?

If I go to and run the test you suggested, I get the folowing message:

[ERROR: corp doesn't have its own zone. I only handle domains with their own zone and a direct parent zone (just or, not or or Try running the test using corp instead.]

The name of my my internal domain is xxxx.CORP. When the domain was originally setup, it was named that way, so it does not match my company website domain name. Could this be causing the problem? How?
Keith AlabasterEnterprise ArchitectCommented:
That is because corp is NOT a zone name.

Yes, the lookup you need to be performing in needs to be based on the email addresses as far as the outside world see thems. So if your emails go out as then is the one you need to be looking up in

For example. all my emails internally have me@internal.zone1 but anything I sent out for delivery to the internet goes out as If I do a lookup at, I get the reverse entries as per my post above. Those entries resolve to my mail senders.

corp, as you state, is your internal name, not how the outside world sees you. It is this outside reverse lookup that I think you will find AOL cannot recognise.
Keith AlabasterEnterprise ArchitectCommented:
The records are not correct.  If I do a dnslookup on your IP address, i get a name back ok. If I then do a search on the domain name it returns, it tells me that the domain does not exist. If the two are not 'tied' together, AOL (and others) will reject your mail.
To test the comparison,

do an nslookup on This will return which is the ip address of my mail server.

now do an nslookup on that ip address. It will return the name of my mail server ( Therefore AOL can prove that the emails have come from my domain and the IP address is assigned to me.  ie I am not spoofing the address.

Can you do the same on yours? I think you can't.

brainboltAuthor Commented:
Correct, because it returns the xxxx01.x.corp address, which is not a zone name, as you mentioned before.

It looks to me like I have to change the name that it is returning when the ip address is looked up. My exchange server is broadcasting it's name as xxxx01.x.corp to the world, but the world cant get back to that name because it is not a zone name. Is that a fair statement? Do I have to rename my internal domain to match my website domain to be able to do that?
Keith AlabasterEnterprise ArchitectCommented:
The external interface of the PIX, is this physical interace using the .122 address?

brainboltAuthor Commented:
Sorry for the slow response. Yes, the external interface on the pix is set to x.x.x.122.
Keith AlabasterEnterprise ArchitectCommented:
OK. So the NAT element is not working for traffic coming out of your SMTP server and leaving the PIX.

ie Your MX record says to find you on .123 but you are sending from the .122 record therefore your reverse dns does not tally. Your NAT command tells everything to go out with the external interface IP address (.122) so we need an additional NAT or you can change the MX record to point to .122.

I'll just get the NAT command for you but then its your call.

Keith AlabasterEnterprise ArchitectCommented:
Add a global and NAT combination so that mail leaving from the smtp server through the PIX leaves as the .123 address.

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
brainboltAuthor Commented:
Added these two statements to my PIX config:

global (outside) 10 x.x.x.123
nat (inside) 10 0 0

Emails are now originating from the correct IP address, and are being accepted by AOL.

Thanks, keith_alabaster.
Keith AlabasterEnterprise ArchitectCommented:
Thanks Brandon.

Good job
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
Software Firewalls

From novice to tech pro — start learning today.

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.