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
  • 8

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,053