problem sending email to one external domain

Please refer :

http://helpdeskgeek.com/networking/you-do-not-have-permission-to-send-to-this-recipient/

What is the version of Exchnage server ?

Also it is possible that external domain have blocked your domain or IP Address

To cross check the issue
Telnet to externaldomain.com from your domain server
Send the test E-mail using Telnet command
After sending the mail you will get the exact error

Hope this helps.

What version of Exchange do you have?

Have you got a specific SMTP Connector / SEND Connector configured for this domain and you are using an old IP as the smarthost address?

Do you have the old server IP address for the remote domain in your hosts / lmhosts.sam file in c:\windows\system32\drivers\etc ?

Have you got a DNS entry for their domain added using the wrong IP address?

Alan

Below are the resons:

1) This is a permissions problem.  It seems due to some reason the sender is not allowed to email this account or an anonymous user is trying to send mail to a distribution list.

2) Check SMTP Virtual Server Access Tab and see if you have allowed this machine to relay.

3) User may have a manually created email address that does not match with your system policy. Ask user to use Check name button

Have a look at this article, https://www.experts-exchange.com/Software/Server_Software/Email_Servers/A_2427-Problems-sending-mail-to-one-or-more-external-domains.html

It may be something as simple as clearing your domain name or IP from a spam list.

viralrathod:
Exchange 2003.  As mentioned, ran the smtp diag test from the Exchange server and was successful.  I did do a telnet session to that address (which I found to be their Exchange server) and the test failed with the same error when I did rcpt to; came back with the same relay error.

alanhardisty:
No send/smtp connector; no manual dns/hosts/lmhosts entries; no smarthost

amitkulshrestha:
It's multiple email accounts from all users at domain1.com.  I tried same user from my gmail account and works fine.  They are user accounts, not distribution lists.  We are the sender, not the recipient.

jtwcs:
I already mentioned I have checked a number of sites and returned no results for our external address on spam blacklist.

Sounds rude not to ask you to look at my article appropriately titled:

https://www.experts-exchange.com/Software/Server_Software/Email_Servers/A_2427-Problems-sending-mail-to-one-or-more-external-domains.html

This will get you to check if your server is RFC compliant or not and once it is and you still have issues - then the issue is beyond your control 99% of the time.

Sound like it is not you, it is them.....
@alanhardisty  good article.

Thanks - If you like it - feel free to vote for it ; )

yes, that is a good article and I have already considered these factors

i have been leaning more toward an issue on their end (trying to get answers as to what changed earlier this week) but still waiting on them

i still don't understand the address difference here.  as i mentioned, when i do the smtp diag test, it passes.  The error in the transport shows a different IP address than what the mx record has so that's the part I can't make sense of.  When I do the telnet test to that address (which is in the same domain), I can reproduce the problem.  It's the fact that Exchange isn't communicating with one of the 2 servers listed for mx records.

For example, if domain2 had mx records as 10.1.1.1 and 10.1.1.2 if i do telnet test or smtp diag test, it passes with mail from and rcpt to.  Exchange transport shows it fails when connecting to 192.168.1.1 and so does the telnet test; though 192.168.1.1 responds as microsoft smtp 7.5 with a server on their domain name.  I just can't figure out how Exchange is getting 192.168.1.1 when it's not an mx record (not the real addresses of course; just example to show the difference on how it's resolving.)  I did flush dns cache on exchange server and stills same behavior.

If you want to be sure - drop me a test email to alan @ it-eye.co.uk - I can then see what you send out as, check you are RFC compliant and then hopefully leave you happy that it's not your problem : )

Alan,

Check this link, it might help. You can paste the header information and see where it is failing.

http://www.levinecentral.com/mail_parse/default.aspx

Okay - test message received.

Here are my findings:

Your sending IP is 208.xxx.xxx.80 - Reverse DNS on this IP Address is vpn3.domain.com and vpn3.domain.com resolves to IP 208.xxx.xxx.80 - So far, so good.

The problem is that your FQDN is buf-ex02.domain.com and that doesn't resolve to anything in DNS.  If you change your FQDN on the SMTP Virtual Server> Delivery Tab> Advanced Button to vpn3.domain.com - the other domain may be happier to receive your mail.

Alan

I guess I'm not alone...

http://serverfault.com/questions/142634/in-spite-of-correct-dns-exchange-sending-to-wrong-destination-server-for-single

the vpn records point to our firewall for user access; wonder if it makes more sense to just have the buf-ex02 (internal name) as the .80 address and the vpn as alias records to that

That would work - or create another name in DNS pointing to the .80 IP address, change the server name and Reverse DNS to match.

figured it out on my own