I've been banging my head against this for some time now.  basically I've got an exchange 2003 server inside my network that goes through the firewall to the DMZ where the inbound and outbound mail hits a spam filtering appliance,  the mail should then go from that spam filtering appliance out to the internet.  our mail headers on outbound mail confirm this but the referenced IP address is wrong causing RFC's to fail and blocking our legitimate email from specific destinations.  does anyone know what could cause this.  I've already reviewed the firewall and nat rules on my Firewall and could find nothing there.  in fact a packet trace using source and destination addresses says it's natted as I expect it to be, but the mail headers still use our internet ip address instead of the one dedicated for email.

Is this configured wrongly in the spam filtering appliance?
 
What interface does it use to send outgoing mail? What is that interface's IP address?

I've checked with the spam filter manufacturer, and their response was that the spam filter is only aware of it's own IP address, and that the header receives it's source address based on the address the recipient sees.  in this case out firewalls external interface.  however the firewall has a range of addresses aside form it's statically configured address.  As I've said, I've verified my nat entries and the firewalls built in packet tracer says it's natting the traffic to the correct address.

I'm not entirely clear on what you're reporting.
" the referenced IP address is wrong causing RFC's to fail" I don't understand.
Do you mean the recipient spam filter is doing a reverse DNS lookup, maybe and that's what's failing?
 
Have you checked your public DNS, especially PTR record?
 
" the mail headers still use our internet ip address instead of the one dedicated for email. "
 
This is a bit hard to figure out without specific information, bu the headers will contain a record of each SMTP hop on the way to destination. If your NATing firewall acts like an SMTP proxy, then it will also appear in your headers as one of the SMTP hops on the way to destination.
Some spam-filtering can be done by reading through the email headers to see if there are any "bad" IP addresses in there, but this is not particularly efficient so happens (if at all) a long way down the list of other things that are checked first. There's no such thing as a "wrong" address in the headers, just "bad" IP addresses belonging to spam relayers. I doubt this is your problem. I suspect you're talking about a reverse DNS lookup issue.

would a Cisco ASA being acting as an SMTP relay without being configured to do so?  that could be my issue.  the specifics are like this.  OUtside interface on the firewall = 10.10.10.10/29.  during a reverse path check this address shows up as the source address for the email and fails the check.  all our mail, and our external PRT records, an dmx records point to 10.10.10.11/29 which is accessed through the same physical interface on the ASA.  

Received: from my.company.com ([10.10.10.10])

the above is the last received line in a header sent from my internal email.  The address in there is the address of the ASA's physical interface.  we can make that number change by assigning the 10.10.10.11 address to the physical interface and make it work.   

bump for good luck

As Vince said, this is difficult to troubleshoot with limited information.

My suspicion is that the Received from 10.10.10.10 is because that was the IP that acted as the gateway.  In actuality, I would hope that it is the public IP address and not the RFC 1918 one.  If you only have one public IP address on your DMZ, you may need to declare this as you MX as this is what other systems will see.  Otherwise, if you have multiple IP addresses, configure a 1:1 NAT on your SMTP server.

Actually, I just re-read your post and could use some clarification: you said that your firewall interface is 10.10.10.10, but 10.10.10.11 is accessed through the same physical interface.  Does this mean you are port forwarding or are you forwarding the IP via nat (back to what I said above if your only public interface shows as 10.10.10.10).
 

I made some progress on this this afternoon after bumping my post.  i was actively monitoring my nat translations while testing emails.  what i found is that although I was able to successfully do what i wanted using the packet trace built into the ASDM my static nat translation was not working as i thought it was.  i was doing PAT on source/dest ports 25.  but after watching the outbound traffic form my spam filter i found it was hitting the catch all rule which gave it the wrong source address.  the spam filter was not sourcing on port 25.  

that being said i've changed it from doing straight ant on all ports for this ip address and got the results I was looking for.  problem now is that OWA can't be directly nated to the exchange server on the same ip address.  unless anyone has another suggestion i'l probably just point my owa PTR record to a different IP address.

to attempt to clarify we have a bank of addresses x.x.x.x 255.255.255.224.  the f0/3 interface has the ip address assigned as one of these addresses but is not the address smtp is meant to flow through.  as you mentioned above i'm going to attempt to do 1:1 nat translation for smtp, and create a second translation on a different address for OWA.  I've got the source address in the email headers correct now.  but i had to remove the nat entries for owa to do it.  

Am i making any sense.  i feel like i'm not explaining this very well.