2

I have a problem with switching my project from hoster A to hoster B. There are three parties involed: the old hoster, the new hoster and NetworkSolutions as a registrar.

I have a .com and and a .net-Domain. Both had Nameservers set from the old Hoster A. I changed that more than 24 hours ago and should now be in full control of setting the DNS entries. The .com-Domain is working properly, the .net-Domain isn't.

Both have the same DNS entries. However, when I send an email from GMAIL the new mail server replies with a 554 5.7.1 : Relay access denied error. When I send a mail from the new mail server (with an .com-Account), the mail ends up in the old mail server. However, the TTL of old MX and A-entries have expired and the new mail server seems to take no notice of it.

I do not understand this error, as its a standard mail server provided by the hoster. I wonder if there is something I've configured wrong with the DNS zonefile or whether this is an issue with the mailserver configuration or whether the old hoster needs to change his name servers with the domain.

enter image description here

Unfortunately, this is a live project and every lost mail is bad. I'm gonna reward questions to this answer as soon as I can (please don't edit this out).

What I've done so far: - made sure the DNS Zone file is 100% the same as the working domain has - Verified that the problem is not with just google: https://www.ultratools.com/tools/emailTestResult - Lowered the TTL on all my settings yesterday to ensure fast propagation

UPDATE:

When I run a php script, it resolves the "mail.domain.tld" host to the old mailservers IP. The domain.tld will resolve properly to the new IP. So it DOES use the new nameservers and yet it resolves the MX entry in a wrong way. Can this cause the relay issue?

Manuel Arwed Schmidt
  • 153
  • 7
  • 2
    Without the real domain names to look at the records all anyone can do is guess. –  Apr 06 '15 at 21:56

1 Answers1

2

The relay access denied message means that the mail server that got the message doesn't know anything about the domain (meaning there are no local mailboxes that it can drop the message in) so it then tries to relay the message to it's remote host. However, since the sender didn't authenticate with a password, it refuses to relay it to the remote system.

Assuming the DNS is correct (MX record is pointing to proper new hoster mail server address), then this means that the domain/mailboxes are not configured on the new hoster's server.

If the new hoster claims that the mailboxes/domain are configured properly, then the DNS is pointing to the wrong server.

Both of these possibilities can likely be fixed with a quick call to new hoster's support team.

Joe
  • 1,043
  • 8
  • 11
  • I can login to the mailboxes. Though I have found out that the webserver is still resolving the mail.domain.tld adress to the old mailserver's IP. Though this one should have expired. Can you imagine why it isn't updating properly? – Manuel Arwed Schmidt Apr 06 '15 at 22:12
  • 1
    Looks like mxf922.netcup.net is the MX record. Is that the server you login the mailboxes? – Joe Apr 06 '15 at 22:14
  • If DNS should have expired by now, then I would check local /etc/hosts file – Joe Apr 06 '15 at 22:14
  • Yes, it's the mailserver. The TTL was 3600 - i'm not sure if all mail servers respect such a short TTL. Also i'm not sure whether asking php for the subdomain mail.domain.tld can identify issues with potential resolve issues with the MX record. – Manuel Arwed Schmidt Apr 06 '15 at 22:18
  • Then it is most likely a misconfiguration of the server. I suggest you contact the new hoster support team and they should be able to resolve it quickly – Joe Apr 06 '15 at 22:19
  • You were right. Something went wrong while configuration the mail server. Hoster fixed it manually. – Manuel Arwed Schmidt Apr 07 '15 at 03:00
  • Very glad to hear it is resolved – Joe Apr 07 '15 at 16:04