Unable to send e-mail to remote office

[shakatak]

I'm in a mess right now in trying to figure this out but our users at domainA.com are unable to send e-mail to our users at domainB.co.za which is in South Africa.

I get the following error/bounce back message:

There was a SMTP communication problem with the recipient's email server. Please contact your system administrator. smtp;550-Verification failed for <users@domainA.com>

Any help would be greatly appreciated.

Thank you.

 

[WhoKilledKenny]

Kinda need more info. Does your exchange organization cover both sites and are you using an SMTP connector between the two? Or are they separate Mail orgainizations that are using the Internet to send messages. Or is it something completely different from what I've described.

 

[shakatak]

We use exchange at the office I'm at but the remote office does not. We use exchange and select the user via the address book and their e-mail is hosted via their ISP. I've sent them a test message from my personal account and did not receive an error/bounce back message so I'm assuming the problem is on our end but I can't figure it out.

They are separate organizations that are using the internet to send messages. Any idea? Users are getting on my butt about this.

 

[markdmac]

How did you add the users to the GAL? Have you created contacts in AD?

Do you have a DNS zone setup for them that may be causing problems?

I hope you find this post helpful.

Regards,

Mark

Check out my scripting solutions at

http://www.thespidersparlor.com/vbscript

 

[shakatak]

I added the users to the GAL by creating contacts and did not create and exchange mailbox for them. I am using their external e-mail address.

As for the DNS zone, you'll have to explain more to me like a 5 year old because I'm still a newbie when it comes to this sort of stuff. Are you referring to the "Forward Lookup Zones" section? If so, I do not see the external domain that I'm trying to send e-mail to.

 

[markdmac]

Yes, that is what I was referring to.

Creating a contact with the external address is the correct way to do what you did.

OK, so next thing to verify is how you have DNS setup.

DNS Settings:

Configure the server NIC to only list itself or other DCs, no ISP DNS gets configured on the NIC TCP/IP properties.

In DHCP, set the DNS scope option to only provide the IP of your local DNS server

For any statically configured IPs, make sure the DNS only lists local DNS servers and not ISP DNS.

In the DNS snap-in on the forwarders tab enter your ISP DNS.

I hope you find this post helpful.

Regards,

Mark

Check out my scripting solutions at

http://www.thespidersparlor.com/vbscript

 

[ShackDaddy]

Shak, I'm wondering if the remote domain manually put your domain into their DNS and have the wrong MX record for you. The error you are getting suggests that the destination mail server didn't expect to get the mail from the server that sent it. At first I thought it was using "SPF", but I think it's more likely that since they are a close affiliate, they may have their own DNS records that are causing their server to bounce your mail. I assume from the way you asked the question that you are able to send mail everywhere else, yes?

ShackDaddy
Shackelford Consulting

 

[shakatak]

Mark: All the settings you mentioned are correct. The only part I am unsure of the ISP DNS in the forward lookup zone. Do I create a new forward lookup zone or add a new host / domain in the section for ourdomain.com?

Shack: I don't think they would have to enter the MX record manually because we are the only ones that use Exchange. They download their e-mail via POP from their Web Host. Do you think their web host provider would have to make the change?

The users at the remote domain can send e-mail to our domain, but we can't reply or send new messages because they just bounce back. If I reply or send a new message from my personal e-mail account (Yahoo!, Gmail, etc.) they can receive it. It is only from our domain to their domain when the messages bounce back. For the life of me I can't figure it out and I'm getting chewed out by users.

 

[markdmac]

The only part I am unsure of the ISP DNS in the forward lookup zone.

DNS Forwarders and DNS Forward Lookup Zones are two different things.

A DNS Forwarder is where your DNS server will go to find an address it is unfamiliar with. Right click the server name in DNS snap-in and choose properties. Click the Forwarders tab.

I hope you find this post helpful.

Regards,

Mark

Check out my scripting solutions at

http://www.thespidersparlor.com/vbscript

 

[shakatak]

Thanks, Mark. I checked and there are 2 ISP DNS servers in there so it looks like it's configured correctly. I'm beginning to think that maybe the MX record does need to be updated on the remote office's end. I was just told by the IT Director that we (corporate office website) switched web hosting providers. Is it possible this might affect the remote domain from receiving our e-mail? I would think they need to update the MX record on their end.

 

[ShackDaddy]

The problem is often caused by a cached MX record at the remote site. If you recently changed ISPs (and probably external IP addresses), then the problem is most likely due to a bad MX or A record there that it is using to verify your identity.

Consider this sender verification scenario:

- You send a message to their server.
- It puts a hold on the session.
- Their server connects back to the sending server and in order to validate your original email, pretends like it is going to send mail to the sender that is trying to send the
original message.
- If your server says the recipient is not valid, their server will reject the original mail.

So what would cause the recipient not to be valid when the remote server connects back to your system?

The FQDN that your server uses to identify itself may be one that has a bad IP cached at the remote office, so that when it connects to you for verification, it fails. Is your MX on the same name as your server identifies itself on? I doubt it. That would explain why they can send emails to you, but can't follow up and verify emails sent by your server.

Just some ideas....

ShackDaddy
Shackelford Consulting

 

[shakatak]

We didn't change ISPs just the web host where we have our corporate website. Should I check with our new web host to see if our MX record and A record what they should be instead of what was being used with our previous web hosting service?

If the IP is bad and is cached at the remote office, what exactly do I need to do to change or clear out the cache? Is it something as easy as clearing out cookies in IE?

Thanks guys for all the suggestions and help. I really appreciate it.

 

[markdmac]

Use

http://www.dnsstuff.com

to verify what your MX record is.

I hope you find this post helpful.

Regards,

Mark

Check out my scripting solutions at

http://www.thespidersparlor.com/vbscript

 

[shakatak]

I did and provided that to the IT staff in our remote office; however, they are about 10 hours ahead of us so I won't find out what the results are until tomorrow. I'll keep you guys updated to see if it works. I really hope it does. Thank you so much for all your help.

 

[shakatak]

Success!!! The problem was actually on our end. What happened is the MX record was showing up as an IP address in the Host Name field. I changed it to include our mail.ourcompany.com address and to point to our IP for the mail server.

Basically, I did a lot of comparing with how other sites are set up (Dell.com, nytimes.com, etc.) and looked at how it had everything set up as 1 MX Record or 2(Host Name and the IP), 2 NS Records (Host Names only), and 1 CName Record.

Ours came up as 1 MX record as IP address in the host name field and IP in the IP field, 2 NS Records (this was fine), and no CName record.

I wanted to thank ALL of you that helped me out with this because it really lead me in the right direction as to where I should look. It helped me out a great deal so thank you!!

 

[ShackDaddy]

Just an FYI: don't let CNAME records have anything to do with your mail setup. You can use them to point to web services and such, but never try to point your MX at a CNAME.

And now you know that an MX for a domain can never point at an IP address....

ShackDaddy
Shackelford Consulting