Mail to valid addresses rejected with error 550 5.1.1 <xx@yy.zz>: Recipient address rejected: User unknown in relay recipient table

I am running Exchange 2007 on Windows 2008 Server R1.
Symantec SMSMSE 6.5 is provides spam protection.

Generally, there are no problems in receiving mail from thousands of senders.

The problem is with a few specific senders - that is specific companies/server/domains cannot send mail to any of our recipient addresses - no mail from any sender at those locations reach us..
Despite the addresses they send to are entirely correct, for instance a reply to our mail to them, they receive an error (and we can send to them with no problems).

In error messages there will be a peamble from their own server, ending with

550 5.1.1 <xx@yy.zz>: Recipient address rejected: User unknown in relay recipient table

However, as mentioned the address they send to on our server is correct.
I have added the sender to our whitelist, for safety's sake, though the error is not spam related anyway.

Any suggstions on probable cause or how to pinpoint the cause?





Flemming50Asked:
Who is Participating?

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

x
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.

Neil RussellTechnical Development LeadCommented:
Have you changed MX records recently? New server or changed ISP, hosting service etc?
I have seen this when a site is accessing cached MX records that are out of date.
 
0
Flemming50Author Commented:
No changes for the last year,
and i have checked the IP setup and MX myself, I have asked a friend to do same for me and have had my internt provider check it as well.
No problems, we all conclude.
0
Neil RussellTechnical Development LeadCommented:
Have you got one of the remote sites to try and tenet to you mail server on port 25? I know this ask a lot but this eeror NORMALY indicates either an error at there end, a mising/blocked account or a server to server to server error such as DNS/MX
0
Acronis True Image 2019 just released!

Create a reliable backup. Make sure you always have dependable copies of your data so you can restore your entire system or individual files.

Neil RussellTechnical Development LeadCommented:
P.S.
Its not much use you checking your MX records as this is not what they will see from there site if it is a cacheing issue. You would need to see what they are seeing from there mail server.
0
Flemming50Author Commented:
I have not had senders use telnet - unfortunately, these are not very sofisticated IT wise, nor part of larger organisations, so they have no particular IT support. Mail may well be online with some ISP, so perhaps I could figure it out by contacting their provider, but in reality it is quite difficult. to get support from an ISP as a non-client...
0
shauncroucherCommented:
Go to http://www.mxtoolbox.com/ and run the tests there, see if they reveal anything.

Sounds DNS to me, as neilsr already states.

Shaun
0

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
Flemming50Author Commented:
Thank you shauncroucher:, nice tool.
All tests resolve fine and gives correct reply back, so seeming no problems with configuration.
0
Flemming50Author Commented:
I did resolve the issue.
As I said - the problem was with a few specific senders, different companies in different Scandinavian countries.
Turns out they were all hooked up with mail through the same web hotel company.
Incidentally I host my web site there as well, but no other services through this supplier.
The ISP had set their DNS up to point mail to us to their server, which is wrong. I am only hosting a web site with them. They dont correctly sync their MX / DNS with the Danish hostmaster, but keep their own setup for their clients. So my correct MX record was nullified for all their internal mail users, but remained correct for the rest of the world.
0
Neil RussellTechnical Development LeadCommented:
My very first post said "Have you changed MX records recently? New server or changed ISP, hosting service etc?
I have seen this when a site is accessing cached MX records that are out of date"

This surely pointed the questioner to investigate the MX records as i said?

His close stated...
"The ISP had set their DNS up to point mail to us to their server, which is wrong. I am only hosting a web site with them. They dont correctly sync their MX / DNS with the Danish hostmaster, but keep their own setup for their clients. So my correct MX record was nullified for all their internal mail users, but remained correct for the rest of the world."

The MX records were at fault.
0
Glen KnightCommented:
I read it as the MX record was fine it was the DNS zone transfers that were the problem?
0
Neil RussellTechnical Development LeadCommented:
"The ISP had set their DNS up to point mail to us to their server, which is wrong. I am only hosting a web site with them"
Done with the MX record on the hosting companies internal setup?
0
Flemming50Author Commented:
Actually the MX record was correct, and nothing was changed.
Actual problem was that a WEB hotel ONLY was set up with a web hotel.
Mail and all other services unchanged.
Turns out that when, web site was set up, hosting company internally pointed their own mail users towards a non-existing mailbox on their own mail server.
This had no effect on the "real" MX record, and was invisible for all, exept hosting companys administrators.
Which is reason why only a select few senders of email was affected.
Hosting company did not host DNS for our domain, and could not set MX record or any other records, rather I ponted our WWW to their site manually.
Against all guidelines, they did not sync their internal mail routing with official records.
I found solution by investigating which ISP handled the mail of those who could not send, and then called that ISP, told them they were not forwarding mail sent to us.

Anyway, I attempted to split points between shauncroucher: and neilsr, but was unable to - got error message. Their solutions not quite correct, but still gave a hint to check that in fact MX record was not right, and mxtool helped figure out pattern in senders.
0
Flemming50Author Commented:
Solutions suggested convinced me what was in fact NOT wrong, and inspired in looking for other patterns. Tool helped track senders ISP (the culprit)
0
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
Email Protocols

From novice to tech pro — start learning today.