R=lookuphost defer (-1): lowest numbered MX record points to local host

S

saphirblanc

New member
Joined
Feb 12, 2013
Messages
2
Hi everybody :),

We've linked two different servers (not at the same location with DA).
However, when we try to send emails from server A to server B, messages are frozen and logs say :

R=lookuphost defer (-1): lowest numbered MX record points to local host

Emails are well received from other IPs and sent to others as well. The issue is only between email addresses stored onto those two servers.

Have you got an idea :) ?

Thanks,

Yann
 
saphirblanc said:
We've linked two different servers (not at the same location with DA).
However, when we try to send emails from server A to server B, messages are frozen and logs say :

R=lookuphost defer (-1): lowest numbered MX record points to local host

Emails are well received from other IPs and sent to others as well. The issue is only between email addresses stored onto those two servers.
Click to expand...
I've deleted two previous replies to this thread; the first was a reply explaining how to resolve the problem on CPanel; the second a reply pointing out that the first reply was incorrect. I feel that deleting incorrect information will keep Googlers from wasting time finding incorrect information.

Here's what's going on and how to fix it...

First, to understand, here's how exim decides to route email:

The problem only occurs when exim attempts to deliver from the server, or relay through the server, to the domain in question...

Exim checks to see if the email is to be delivered locally or not: It checks the /etc/virtual/domains file. By default DirectAdmin presumes all email is delivered for every domain hosted on the server. To change that you must uncheck the checkbox on the MX records webpage in the control panel for the domain. But it's often not that simple because to get access to that page you must have DNS access turned on for the domain.

If email is turned on for the domain, then exim doesn't even check DNS for the domain; it just delivers the email locally.

If email is turned off for the domain, then exim will check MX records in DNS:

Then exim will attempt to deliver email to the servers pointed to by the public MX records for the domain, starting with the lowest-cost (highest priority) MX record, and trying servers pointed to by other MX records with higher costs (lower priorities) until it finds a server which will accept the email.

If exim finds that the lowest cost MX record points to itself, and the domain isn't listed in the /etc/virtual/domains file, it can't deliver the email, so it holds it in the queue until the freeze time expires, hoping you'll find and fix the problem so it doesn't need to return the email. That's the error you're getting.

So the first thing you need to do is decide which server you want the mail received on, and adjust the MX records and/or the /etc/virtual/domains file accordingly. If the email shouldn't be delivered to either server, but rather to a third email server, then both your servers should be set to not host email for the domain. If the email should be delivered to both servers, then both servers should be set to host email for the domain. If the emails should be delivered to one of the servers, then set the MX records and local delivery according.

While the file can be changed manually, and you may be tempted to do so, especially if you don't give the user access to DNS, making it harder for you to make the change through the control panel, you should resist the temptation if any user on your server has the ability to change the setting... because if by chance you're manually editing the file while any user is changing it through the control panel, you may corrupt the file.

Jeff
 
Hi Jeff,

How clear was your answer. Thank you so much :)!
In fact, after some researches on those servers, my colleague had done a mistake and added another IP on the server which was in fact corresponding to the address of the other one.
The server thought it was itself and did not try to look somewhere else.

Thank you to have taken time to help us! :D

Cheers,

Yann
 
nobaloney said:
I've deleted two previous replies to this thread; the first was a reply explaining how to resolve the problem on CPanel; the second a reply pointing out that the first reply was incorrect. I feel that deleting incorrect information will keep Googlers from wasting time finding incorrect information.

Here's what's going on and how to fix it...

First, to understand, here's how exim decides to route email:

The problem only occurs when exim attempts to deliver from the server, or relay through the server, to the domain in question...

Exim checks to see if the email is to be delivered locally or not: It checks the /etc/virtual/domains file. By default DirectAdmin presumes all email is delivered for every domain hosted on the server. To change that you must uncheck the checkbox on the MX records webpage in the control panel for the domain. But it's often not that simple because to get access to that page you must have DNS access turned on for the domain.

If email is turned on for the domain, then exim doesn't even check DNS for the domain; it just delivers the email locally.

If email is turned off for the domain, then exim will check MX records in DNS:

Then exim will attempt to deliver email to the servers pointed to by the public MX records for the domain, starting with the lowest-cost (highest priority) MX record, and trying servers pointed to by other MX records with higher costs (lower priorities) until it finds a server which will accept the email.

If exim finds that the lowest cost MX record points to itself, and the domain isn't listed in the /etc/virtual/domains file, it can't deliver the email, so it holds it in the queue until the freeze time expires, hoping you'll find and fix the problem so it doesn't need to return the email. That's the error you're getting.

So the first thing you need to do is decide which server you want the mail received on, and adjust the MX records and/or the /etc/virtual/domains file accordingly. If the email shouldn't be delivered to either server, but rather to a third email server, then both your servers should be set to not host email for the domain. If the email should be delivered to both servers, then both servers should be set to host email for the domain. If the emails should be delivered to one of the servers, then set the MX records and local delivery according.

While the file can be changed manually, and you may be tempted to do so, especially if you don't give the user access to DNS, making it harder for you to make the change through the control panel, you should resist the temptation if any user on your server has the ability to change the setting... because if by chance you're manually editing the file while any user is changing it through the control panel, you may corrupt the file.

Jeff
Click to expand...


Hi Jeff,

You explanation im femiliar with i know about the mx local mail server option but still walking into problems and getting the
R=lookuphost defer (-1): lowest numbered MX record points to local host
Click to expand...
error.

This is the situation i got.

The customer use to have a webhosting account about 10 domains ar in it.
We now installed a vps server with directadmin for the customer we placed a backup of the account on the vps and that is running fine.
One the old account we changed all dns records and unchecked the localmail server check box on the mx page.

We are still getting the error even after 24 hour, the dns lease time is set to 300.

I am able tot get it to work when i create a A record for example mail2 and point to the same ip als the main mail records and change the mx mail to 20 and create mx 10 to mail2.

It looks like it won't accept mail 10 and gives the error.

I have manually check /etc/virtual/domains and the domain is not in it any more on the old account.

What else could cause this issue do you have any idea where running default spamblocker 4 with dkim and spamassassin and clamav

Kind regards
 
I've explained the problem, and why you're having it. For some reason the sending server thinks it's got the lowest numbered MX record pointing to it. Check the DNS from the sending server and see if it points the lowest cost DNS to that server.
Code: 
dig example.com mx
How many mx records do you see? Post them here (don't hide any information at all if you want further help; the only way to debug it is be able to check the problem and we cn't do that with hidden information.

If everything looks right then the only way to resolve the issue would be to log into the server and do some forensics, and if I do that I'd have to charge.

If you're interested in hiring me then please use email to contact me; it often takes me a few days to respond to PMs.

Thanks.

Jeff
 
nobaloney said:
I've explained the problem, and why you're having it. For some reason the sending server thinks it's got the lowest numbered MX record pointing to it. Check the DNS from the sending server and see if it points the lowest cost DNS to that server.
Code: 
dig example.com mx
How many mx records do you see? Post them here (don't hide any information at all if you want further help; the only way to debug it is be able to check the problem and we cn't do that with hidden information.

If everything looks right then the only way to resolve the issue would be to log into the server and do some forensics, and if I do that I'd have to charge.

If you're interested in hiring me then please use email to contact me; it often takes me a few days to respond to PMs.

Thanks.

Jeff
Click to expand...

Hi Jef,

Thanks for the reply the problem is found.
We initiale didn't notice that it was a utp conflict, or own server was using the same ipv6 address to thats why it pointed to local host.
 
You must log in or register to reply here.
Back
Top