If you're using Exchange 2003 (I'm assuming you are as you indicated Windows Server 2003), you could just setup an SMTP Connector on the bulk mailing server with yourdomain.com cost 1
(make sure your default SMTP connector has * cost 5
or it'll never match yourdomain.com on the new send connector) and add your corporate mail server as the smarthost. This will ensure that [email protected] gets routed through the corporate mail server; anyrecipient@*.tld will get routed out normally.
EDIT
Has your firewall changed? MX records correct? From your bulk mail server, try this from the command prompt:
'nslookup' hit ENTER then set type=mx
hit ENTER again, the type in yourdomain.com and first make sure that the MX records resolve correctly and secondly, try to telnet to that MX record like so:
telnet <mx.record.tld> 25
if you get back a 220 Microsoft Exchange xxx
(you can type quit
to exit) then you can connect to your mail server via NAT reflection (going out and back in again) so the issue must be elsewhere in the bulk mail software.
If only your new mail server has changed, then it's likely your new Exchange Server is not allowing connections and/or you're trying to relay from [email protected], which will be denied by default. You can open up the Default Virtual SMTP Server and under Connections and Relay settings add to the "allowed" list for both relay and connections (or you can use SMTP authentication if the bulk mailer supports it).
If neither of these are the issue, and since you seem to be limited to configuration choices on your bulk mail server software, you could create a Zone in Active Directory (assuming you're using Active Directory for DNS internally) for yourdomain.com and then add an MX record which resolves to your Exchange Server's internal IP address so that when your bulk mail server looks up the MX record for yourdomain.com, it gets the internal MX record (which in turn needs to resolve to your internal IP address for your mail server). The only problem with this method (split DNS) is that you need to make sure your internal DNS zone is identical to your external/Internet DNS zone for yourdomain.com, otherwise, if anyone tries to hit up www.yourdomain.com internally or whatever you won't have any/the correct records to do that.