problem sending email to one external domain

We have a problem sending email to one of our vendors.  Everything was working fine until about 3 days ago when all mail going to failed.

User1 on 3/22/2011 1:31 PM
You do not have permission to send to this recipient. For assistance, contact your system administrator.
< #5.7.1 smtp;550 5.7.1 Unable to relay for>

In message tracking, it gets as far as starting outbound transfer of message then generates the NDR.

I have ran smtp diag from the Exchange server and using my address with User1, it completes successfully; both mail from and rcpt are ok..  I have checked several spam sites and our public address is not found in any blacklist database.

I just sent a test email to that user to generate an NDR and had diagnostic logging enabled for Exchange Transport.  The only thing I found in the application log that stands out is where the NDR occurred.  It shows that error (unable to relay) on rcpt command, but what I don't get is the remote host IP address is not what resolves to either of their mx records.  The smtp diag test resolved the mx records correctly, but Exchange shows something different.  I'm at wits end on this one.
LVL 37
Seth SimmonsSr. Systems AdministratorAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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

To cross check the issue
Telnet to 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.
Alan HardistyCo-OwnerCommented:
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?

Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

AmitIT ArchitectCommented:
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,

It may be something as simple as clearing your domain name or IP from a spam list.
Seth SimmonsSr. Systems AdministratorAuthor Commented:
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.

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

It's multiple email accounts from all users at  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.

I already mentioned I have checked a number of sites and returned no results for our external address on spam blacklist.
Alan HardistyCo-OwnerCommented:
Sounds rude not to ask you to look at my article appropriately titled:

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.
Alan HardistyCo-OwnerCommented:
Thanks - If you like it - feel free to vote for it ; )
Seth SimmonsSr. Systems AdministratorAuthor Commented:
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 and 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 and so does the telnet test; though responds as microsoft smtp 7.5 with a server on their domain name.  I just can't figure out how Exchange is getting 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.
Alan HardistyCo-OwnerCommented:
If you want to be sure - drop me a test email to alan @ - 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 : )
AmitIT ArchitectCommented:

Check this link, it might help. You can paste the header information and see where it is failing.
Alan HardistyCo-OwnerCommented:
Okay - test message received.

Here are my findings:

Your sending IP is - Reverse DNS on this IP Address is and resolves to IP - So far, so good.

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

Seth SimmonsSr. Systems AdministratorAuthor Commented:
Seth SimmonsSr. Systems AdministratorAuthor Commented:
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
Alan HardistyCo-OwnerCommented:
That would work - or create another name in DNS pointing to the .80 IP address, change the server name and Reverse DNS to match.
Seth SimmonsSr. Systems AdministratorAuthor Commented:

Problem resolved...

Restarted SMTP virtual server and it suddenly started sending mail using the correct MX records for that domain.  Confirmed with them that no MX records changed so I'm at a total loss as to why SMTP service was not using the correct address to communicate with the last 3 days.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Seth SimmonsSr. Systems AdministratorAuthor Commented:
figured it out on my own
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.