Switched ISP IP address, now internal exchange server showing MSexchangetransport errors

Our organization recently switched ISPs.  We got a new data T1 and new IP addresses from AT&T.  I've switched our A record tat our registrar to point to the new WAN IP for our exchange server. Everything seems to work, but here's the problem:

Most email goes out from our organization.  I tested several high level domains: gmail.com, yahoo.com, but there are a few other domains that I cannot send email to.

When I try and send mail to a comcast.net, agfc.state.ar.us, or several other domains, we get a delay of delivery notification from our exchange server.

Our exchange server is not set up as a mail relay, our SMTP virtual outbound settings do not point to a smart host.  We are managing everything from our exchange server

There are hundreds of application event warnings for the MSexchangeTransport in our event logs. Here are a few examples:
Source: MSExchangeTransport
Category: SMTP Protocol
Event ID: 7010
Description:
This is an SMTP protocol log for the vertual server ID 1, connection #466. The client "166.137.140.122" sent a "rcpt" command and the SMTP server responded with "550 5.7.1 Unable to relay for xxxxx@agfc.state.ar.us". The full command sent was "rcpt TO:<xxxxx@agfc.state.ar.us>". This will probably cause the connection to fail.

I've got hundreds of these in my event log.  I just need some help figuring out why some mail is going through and some is not.

Thanks in advance for your help.
J_bodenheimerAsked:
Who is Participating?
 
TBK-ConsultingConnect With a Mentor Commented:
The SPF in of itself will get you past most spam filters, but there are some that will absolutely not pass your email unless the reverse dns points the ip address to mail.yourdomain.com

For the SPF Record creation, there is a link to www.openspf.org from mxtoolbox.com but it's hard to find sometimes ... try going directly to www.openspf.org and the tool is right on the front page towards the right side ...

If you still can't get all your email passing thru servers for proper delivery, you may want to consider using your ISP's email servers as a smarthost to deliver the email.
0
 
TBK-ConsultingCommented:
you need to change or add an SPF Record to your DNS Records so that other servers will know that you are set to a good ip address that is authorized to send your domains email ... also you need to have reverse dns setup properly from the new ISP for that IP Address to show it does belong to the mail server.
0
 
J_bodenheimerAuthor Commented:
Can you provide me with instructions for change/add of an SPF record in my DNS records?  That would be awesome.  I think I have the reverse setup properly.  

Also, what is a good command line input I can give to test proper reverse DNS?

Thank you TBK for your prompt response on this.
0
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

 
TBK-ConsultingCommented:
mxtoolbox.com has a reverse dns lookup tool and also has a tool to help create the spf record as well
0
 
J_bodenheimerAuthor Commented:
TBK,

I'm really just an admin for the organization.  I mainly do hardware.  I see on mxtoolbox.com that the spf query shows no record, but I'm not finding the tool that will help me create an spf record or where that spf record is even suppose to reside.

Here's a little more information:
When we switched our T1 over to AT&T and got the new IP address, they will not set a reverse lookup, but will allow our IPs to be associated with our registrar's name servers.  
Are you say I have to work with my registrar to make sure there are reverse dns set on their name servers and the SPF record as well?

Thanks!
Jason
0
 
J_bodenheimerAuthor Commented:
TBK Gave the right solution for the question I asked, but ultimately the best solution for me was to completely give DNS control to our ISP.  
We were having our Registrar handle DNS, which made it quick and efficient to make changes for CNAME and A Records, but when it came to reverse DNS lookups for our inhouse exchange server, the provider that is hosting your exchange server's IP address is (as a rule) the provider you want to handle your DNS.   I think it's stupid and the SPF record should've worked...  in theory it should have, but in practice it did not.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.