Exchange 2007 SPF showing SonicWall X1 public IP.

Sorry if this is a long one, but here it goes. I have Exchange 2007 that was running on Server 2003 x64. Powershell got removed, and since my option at that point wasn't simply to reinstall powershell; I moved the database over to a new Server 2008 machine and synced IIS across. After a long weekend of working out the bugs and getting our BES 10 to work with it again, I finally got everything working. That is until I noticed we were getting more delivery failed notifications than usual.
   I started sending test emails to my outside accounts and noticed Yahoo shows Received-SPF: fail (domain of does not designate as permitted sender). The ip address it showed was from my SonicWall public IP. Most people would say I'm OK since this didn't have an error code, but other sites like Hotmail are flagging my emails as spam. Now is when it gets into the crazy workings of our setup, I hop you can bear with me.
   So, I have a public IP set up for our Exchange server, It is registered with our ISP as That IP is NATed to our internal Exchange IP address in our SonicWall. Our internal domain lets say is mydomain.local, not .org. So the Exchange server is Exchange.mydomain.local. I have a DNS pointer to exchange.mydomain.local with the internal IP, and a MX record for exchange.mydomain.local. In our Exchange Management Console, every place that asked for FQDN for ehlo or helo response I put exchange.mydomain.local. I noticed the txt files we had for spf info in our DNS server were outdated from our last mail server (which was called so I changed it to reflect the new server.
   So my big problem is when I check the header info from my test emails, no matter what I change it is still showing that Public IP address from our Sonicwall. Is this a routing issue within our SonicWall? Or is there somewhere else I should be looking? Any help is greatly appreciated!!! Thanks!
Who is Participating?
rmayoAuthor Commented:
We finally got it figured out. Our new Exchange server is a virtual, and it has 2 NIC cards assigned to it. The server was sending on the secondary NIC that was setup on the server so the NAT wasn’t applying to it.  We adjusted the NAT and server to ensure that both NIC’s were capable of sending out of the NAT so these SPF issues would not arise again.
Seth SimmonsSr. Systems AdministratorCommented:
i'm not really familiar with sonic wall, but from a general firewall standpoint, it sounds as though the original mail server was going out configured to use a different public IP than  your gateway, specifically the address in the public spf/mx records and now with a different machine it doesn't have that so it uses the gateway address which is different causing the SPF check to fail.

for example, if your public gateway address was external and internal and your exchange server public address was with internal address, there could have been a sonic wall rule that says for traffic going out from set source IP as but now your new server you just configured might be internal with no source IP configured for outgoing traffic on the firewall so it appears to the outside to have a source of which doesn't match SPF record.  it isn't a routing issue, sounds as though traffic from that new server needs to be configured to have the correct public address matching spf/mx records for outgoing traffic.  hope that makes sense.
rmayoAuthor Commented:
I see what you're saying. I'll specify a little more. My local exchange server IP adress lets call it was taken from the the old send mail server when it was taken out of production. I never set up a public gateway address. It just has the internal gateway that it has always had. We are using a NAT in our SonicWall that says anything sending to our public exchange IP will NAT to
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

rmayoAuthor Commented:
I think seth2740 may be on the right track - it is definitely worth checking out (unless you were the only person to have ever configured that Sonicwall, and absolutely do not remember ever setting up an NAT statement that applies to *outgoing* traffic from the old mail server)

Look at your firewall, and see if you have a NAT policy that looks something like this:
(In the firewall, the stuff below is laid out horizontally, and we are looking for the first 2 fields)

------------------------------------ Sonicwall > Network > NAT Policies ---------------------------------------
Original: old email server's private IP address (you may need to hover your mouse over a field to discover the actual IP address associated with a named object)
Translated: the public IP address you need the mail server to use


If you see a NAT Policy in the Sonicwall config where the beginning of that policy looks like that, then that is the line you will need to modify.  It should be pretty obvious what to change once you spot this line

If you don't, then that is a policy you will need to create, which will make outgoing communication from the mail server use the public IP address you want it to use
rmayoAuthor Commented:
After spending all day investigating, I am now thinking it isn't the sonicwall. We had mail sending last week fine before we migrated our Exchange over to a Windows 8 server. (And no, it isn't SBS) We had server 2003 before. I searched through some outgoing emails last week and found the header included the correct Public IP address for our mail server. Also, I don't think it could be our DNS. Even though we have the same spf txt files, ptr, and mx records that we had way back when we had sendmail, the ip addresses and server name has always stayed the same. Besides, it worked with our 2003 server. Sorry my parameters for my question seem to keep changing, but I'm learning as I dig into the issue. The only problem we had with the migration to server 2008 was a few hiccups going from IIS 6 to IIS 7.  Is there anything in IIS that could cause these problems? I appreciate everyone's feedback to far.
If you want the mail server to use an IP address different from your firewall, you need to have (or create) a NAT policy on the Sonicwall that makes that server's communication use that particular IP address.  Doesn't really matter if you are using a Sonicwall, a Cisco device, or anything else - you need to have some kind of rule/policy on the firewall that makes traffic from the server use a different IP address than the default.  

Actually, I'm afraid I am not sure what the question is anymore :)  
If I read correctly, you want email sent from your mail server to look like it comes from a particular, specified IP address, and not from the IP address of the Sonicwall.  If that is the case, then see above.  If it's not, then please re-frame the question to let us know more specifically what you feel the problem is, so that we can try and help you to a solution.
rmayoAuthor Commented:
As with any network, no one can possibly understand your setup like you can. Understandably it is difficult to give someone else from the outside a full picture of your network. I took the solutions from everyone else and used them to rule out all other possible causes. This led me to trace further down the line of outgoing mail and eventually to the server's NICs themselves.
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.

All Courses

From novice to tech pro — start learning today.