Sender ID Framework troubleshooting

Per has earlier written about SenderID and we of course implemented the required SPF records at Inceptio. But then we needed to change our E-mail server publishing to another Firewall with another IP Scope / ISP and the trouble began. Usually changing the IP address of a DNS record takes some time to replicate (Actually technically it needs to expire in the cache on the DNS servers around the world, but that’s another story).
So changing the IP address required changing our A record for mail.inceptio.dk - which should be enough as our SPF record points to mail.inceptio.dk (And all A records) –

"v=spf1 a mx mx:mail.inceptio.dk -all"

After changing the firewall configuration, the A record and waiting a few hours everything seemed to work fine, email was flowing in- and outbound and rpc/https worked - I was happy ;-)
Then I received an e-mail with the text "Sender is forged (SPF Fail)" appended to the subject line. At first I thought it was a matter of DNS cache expiration and that time would solve the problem – but then a few hours later a mail bounced with the error “**Message you sent blocked by our bulk email filter**”.

For troubleshooting I used the SPF testing tool from dnsstuff (That provides other great tools as well) and a few others with only positive results. After a bit of troubleshooting I decided that synthetic testing method of dnsstuff wouldn’t give me an answer to the problem. Instead I used port25’s automated testing tool, which basically is an e-mail address called check-auth@verifier.port25.com that you send an e-mail to. A few minutes later you will receive an authentication report that includes compliance checks for the Sender ID standard and Yahoo’s DomainKeys (Also check their site for other resources).
In my case the problem was that the new firewall used a different outbound IP address than I expected. Changing the configuration of the firewall solved the problem and now its working fine again (Actually the whole situation reminded me about the problems we had back in the NT4/W2K and Exchange 5.5. days, with e-mails bouncing due to Exchange clusters using the Host IP address instead of the Exchange Virtual IP address because of problems with the gethostbyname() method as I described in my old article Tips for Clustering Exchange Successfully).