Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17


Exchange 2007 SPF showing SonicWall X1 public IP.

Posted on 2013-06-20
Medium Priority
Last Modified: 2013-07-02
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!
Question by:rmayo
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 5
  • 2
LVL 35

Assisted Solution

by:Seth Simmons
Seth Simmons earned 320 total points
ID: 39262513
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.

Author Comment

ID: 39262531
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

Author Comment

ID: 39263037
Get your Disaster Recovery as a Service basics

Disaster Recovery as a Service is one go-to solution that revolutionizes DR planning. Implementing DRaaS could be an efficient process, easily accessible to non-DR experts. Learn about monitoring, testing, executing failovers and failbacks to ensure a "healthy" DR environment.

LVL 14

Assisted Solution

Kaffiend earned 640 total points
ID: 39264699
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

Author Comment

ID: 39264802
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.
LVL 14

Assisted Solution

Kaffiend earned 640 total points
ID: 39267392
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.

Accepted Solution

rmayo earned 0 total points
ID: 39281466
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.

Author Closing Comment

ID: 39292537
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.

Featured Post

Office 365 Training for Admins - 7 Day Trial

Learn how to provision tenants, synchronize on-premise Active Directory, implement Single Sign-On, customize Office deployment, and protect your organization with eDiscovery and DLP policies.  Only from Platform Scholar.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

There are times when we need to generate a report on the inbox rules, where users have set up forwarding externally in their mailbox. In this article, I will be sharing a script I wrote to generate the report in CSV format.
Know the reasons and solutions to move/import EDB to New Exchange Server. Also, find out how to recover an Exchange .edb file and to restore the file back.
In this video we show how to create an email address policy in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.:  First we need to log into the Exchange Admin Center. Navigate to the Mail Flow…
The basic steps you have just learned will be implemented in this video. The basic steps are shown to configure an Exchange DAG in a live working Exchange Server Environment and manage the same (Exchange Server 2010 Software is used in a Windows Ser…

715 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question