Link to home
Start Free TrialLog in
Avatar of tferlaak
tferlaakFlag for United States of America

asked on

SMTP Connector not sending to some domains after ISP and Static IP Change

I have been racking my brain on this issue for the past couple days. recently changed ISPs from Comcast to TDS. With that got a new IP Address.
DNS registrar is Godaddy.
The server is a Small Business Server 2003, with Exchange 2003. Hosting out own email.
Since the change was made users have been unable to send email to 7 very different domains (so far). I go to the exchange server queue and see the emails sitting there with the SMTP protocol error message. And the users get a NDR email. The most descriptive one was a #4.4.7 error.

Heres what i have checked:
Reverse DNS is correct
No blacklists
SMTP Banner Correct
External IPs removed from the banner area.
Ran Exchange Best practices and made some of the changes it suggested.
Ran the Connection and email wizard in SBS
And much more.

Couple things that may be causing issues that i can see:
the path to the internet is as follows:
Server1 -----> SonicWall router/firewall -----> Cisco router for the T1
192.x.x.x         x.x.x.238                                    x.x.x.237
Should the reverse dns be pointing to the 238 or the 237 address?
Should i be pointing my address to the 238 or 237 address.

Any help would be greatly appreciated.
Thank you
Avatar of connectex
Flag of United States of America image

The reverse DNS entry should be the IP address that's being used to forward port 25 through your router/firewall.
Avatar of dattatraykadam

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of tferlaak


Checked your link, it tested successfully for the outbound SMTP test.
Currently the pointer record for reverse DNS is pointing at the WAN Ip address of the Sonicwall. the 238 address. The sonicwall's WAN Configuration has the 238 address as the IP, and the 237 as the default gateway.
Also, Currently the Reverse DNS record is pointing to the 238 address, and the godaddy address for is pointing at that address as well.
Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Alan Hardisty
Alan Hardisty
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
The SMTP connector is configured. We do not use SmartHosts as we host all email internally and use the internal dns.
Good link, Alan. The only thing that seems to me to be the problem is the reverse DNS entry. The ISP has a reverse DNS entry configured, but its for only the 238 address, and not for the 237 address. If the Sonicwall is configured to use the Cisco Router as the default gateway, (237 address) Would traffic that is going out actually be going out with a 238 address or a 237 address. I have a sinking feeling that  the server is sending out mail, it goes through the sonicwall and gets a tag of the 238 address, then when it hits the Cisco router, it changes that tag to a 238 address, and when the recieving mail server sees that it does a reverse dns lookup on and sees the 238 address and says "this doesnt match what the address is pointing to, im going to deny it"
I could be completly off base on that but at this point im grabbing at straws as MXtoolbox has always checked out perfectly and never had any issues with the SMTP test, Blacklist check, SPF check, Reverse Lookup check and any other tests i have performed.
Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Interesting enough, your address seems to be one of the problem addresses. As soon as i get a bounceback i will send it to you via my gmail account.
Thanks so much for your help on this.
NM looks like it went through. Originally in the queue it sat at retry for a bit, then finally went through.
Just by chance would these other domains but non-us like the .uk on Alan's?
We use Greylisting - so your initial attempt will be bounced.  It loses plenty of spam just with Greylisting : )

Okay - you are sending out using the .238 IP Address.  Configuration seems fine but your SPF record contains the PTR detail which is not recommended:

Please check
Its all US, .coms and .nets.
Would PTR Detail be causing it though? I can take that out right now, let the TTL run out and try again. Its just odd, Everything i have checked looks fine, but still no go when i try to force connection via the queue.
Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Hmm... Anyone know if Godaddy's Hosted email uses that spam listing?
Not got a clue unfortunately.

What was your old IP Address (or is that still in use by you)?
reason i ask is that one of the domains that we have issues sending to is email hosted at godaddy.
Well - as you stand - the APEWS listing is all I can see that might be causing you a problem.

Having said that - my IP is also listed on APEWS.  Do you want to let me know an email address you are having problems sending to that is hosted on Godaddy and I'll see if I can get the mail through?

Would rule in or out the APEWS listing as the problem.
I will have to look at my notes when i get home and let you know. It was a comcast IP address. Never had any problems sending to the domains prior to this.
sent you the address.
Message sent - with a delivery / read receipt attached.
Delivery receipt arrived : )

So - it's not APEWS.

Are you using an Autosignature?

It could be GoDaddy not liking you and you may need to contact them directly and ask to be removed from a blacklist.
I actually have contacted godaddy, they looked at the header of the email getting bounced, checked the domain i was sending to, also checked my domain listing. couldnt find any issues either. ugh.
4.4.7 Error:

Numeric Code: 4.4.7

Possible Cause: The message in the queue has expired. The sending server tried to relay or deliver the message, but the action was not completed before the message expiration time occurred. This NDR may also indicate that a message header limit has been reached on a remote server or that some other protocol timeout occurred during communication with the remote server.

Troubleshooting: This code typically indicates an issue on the receiving server. Verify the validity of the recipient address, and verify that the receiving server is configured to receive messages correctly. You may have to reduce the number of recipients in the header of the message for the host that you are receiving this NDR from. If you resend the message, it is placed in the queue again. If the receiving server is on line, the message is delivered.

Extracted from
if you could only see the steam pouring out of my ears right now. They gave us a blacklisted IP. Appearantly it was listed on a bunch of private spam lists that you cannot access by normal means.
I found this out by going to 
SMTPDiag tool came back with "
Error: Expected "220". Server is not accepting connections.
Failed to submit mail to
Connecting to [] on port 25.
554 Your access to this mail system has been rejected due to spam or virus conte
nt. If you believe that this failure is in error, please submit an unblock reque
st at"
This is for the godaddy address we were sending to. So i wen to the address and unblocked our IP and it started magically sending.
So now i have to do this for every one of those domains. Is there any way to mass unblock these other smaller domains?
Just looked at the queue, and unblocking from the address unblocked from a lot of them and the mail started flowing out amazingly.
There will still be a bit of cleanup but ill work though it. Thank you all for your help. i really appreciate the effort on your parts.
I'll have to remember the SMTPDiag tool - if it unearths more Hidden Blacklists!  Very odd - but appreciate the update.