We had to change the registrar for our domain so the IP's for our DNS resolves to a different IP and the incoming SMTP incoming IP's have also changed. We have I think got the firewall allowing traffic from the registrar's IP's. But its bouncing email's With "Diagnostic-Code: smtp; The recipient server did not accept our requests to connect.". We're using Qmail on a Slackware server. I think I need to check my tcpremotehost for tcpserver and change it with the tcpremoteip function ummmm? I'm stuck, any help? I'm about 4 days old in terms of LINUX btw. My OS is slackware 2.6.37.6 and Qmail won't tell me lol. Any help appreciated. Tim

I'm assuming the DNS records were also at the old Registrar. Did you get a zone dump before changing?

When you transfer registration your whois records including name servers will transfer but other zone records such as A records, MX records, TXT records etc... (i.e. zone file records) don't transfer. If you're using your own DNS servers or pointing to a 3rd party this isn't a problem. However, if the zone records were at the Registrar they abandon them.

You *MIGHT* be able to contact the old Registrar and have them give you old zone records if you didn't do a zone dump beforehand but that would depend a lot on who the Registrar was.

From what you wrote it sounds as if you know what your MX record should be (your own mail server's IP). It may be you just need to update the name servers at new registrar. If you transferred say from GoDaddy to Network Solutions you'd find the name servers GoDaddy uses for zone files are at domaincontrol.com whereas the ones Network Solutions uses are at worldnic. Most registrars have a place to "change where DNS points" which is usually to tell it to use 3rd party name servers or its own (e.g. Network Solutions calls theirs Advanced DNS [ADNS]. If you use that you don't have to tell it the actual name servers - it will decide which ones to use when you add the zone records (MX, A, TXT, etc...).

In my limited experience with transfers, changing the registrar does not change which DNS servers are authoritative for the the domain, but MensaWater is correct, if the authoritative servers were those of the old registrar, it's possible...maybe likely...that they've removed your domain from their name servers.

Although, I'm confused as to why changing the registrar would change the hosting IP address. Did you also change where the domain is being hosted?

Do a (where domain.com is your domain name) to see which name servers are currently authoritative for your domain.
Then investigate how to update the records on those name servers
-or-
Set up your domain records on different name servers and update the registration to change the authoritative servers for the domain.

It's not so much that it "changed" it but that it might have "removed" the record that points to it.

We do quite a number of acquisitions here and nearly all of them involve us inheriting one or more domains. What I find is that one can have:
1) A Registrar
2) DNS Zone files
3) Web Hosting
4) Mail Hosting

One might also have worked with another party to design and setup the web pages. Often that party is the one who Registered the domain (sometimes as a reseller for the larger Registrars, sometimes simply under their own master Registration account).

Most of the Registrars allow you to make your zone file records on their DNS servers and will also allow you a control panel for web hosting and offer you mail accounts all on their servers.

However, it is possible (and not unsusual) that all 4 of the functions above are separate.
Here we use Network Solutions as our main Registrar.
However we have our own DNS name servers so tell the Registrar to point to our own DNS name servers for the zone files rather than having them on theirs.
We have separate servers for web hosting so setup records to point to those. (In fact we have many in house and many others at an outside marketing firm so the web hosting varies depending on domain.)
Finally we used to use MS Exchange (internal) for email but now use Office 365 (external).

However, I've seen many companies that use the Registrar's DNS name servers and add records there even if they use other parties for web hosting and/or email. I've seen some (in fact the next one we're doing) that uses the Registrar for all 4 functions).

The issue the OP describes appears to be that at least 1 and 2 were at the Registrar. When he transferred Registration the Registrar simply abandoned his DNS zone records. I was suggesting that despite that the new Registrar may still be pointed to the original Registrar's name servers but those no longer have the records. If this is the case he can probably get things going quickly by creating zone records at the new Registrar (which should mean telling it to use its own name servers rather than the ones it inherited).

Email can present another wrinkle in that there are additional services (item #5) that one can send email to to verify it is not spam before it is sent to external recipient and/or before it is received by internal recipient. In those situations the MX record generally points to that external company's mail server and a separate configuration at the external company tells it to send the email to the user's own mail servers after processing. Additionally many services (e.g. Google Mail, Office365) require additional records such as TXT or SPF records in addition to the MX for the proper flow of mail.

P.S. whois <domain.tld> may or may not work depending on the TLD (top level domain) and the Registrar. The folks at GoDaddy (who should definitely go... somewhere) hide whois info and force you to go to their web site to get whois even for public domains. For .com, .net and others command line except at such Registrars usually works but for TLD like .shop your setup may not have been updated to know it exists or where to get the answer.

1 members found this post helpful.

Excellent overview of things MensaWater. Hope that will be helpful to the OP and others. Thank you for taking the time to post that.

An overview of my understanding:
A domain name is associated with a DNS service in its registration record.
The DNS zone entries at that service point the domain name to the IP address(es) where its web and email (and sub-domains,etc) are hosted.

The comments about the limitations of whois were new information to me...I mostly use to identify senders of spam.

My comment about changing the hosting IP address from the OP saying
Changing the registrar only wouldn't normally change the destination IP's -- tho I agree that it could cause the domain's DNS entries to disappear.

We use Tucows/OpenSRS and are a reseller of registrations there. Most of our customers are hosted on our servers, and we utilize the Tucows DNS servers for them. Some are hosted by and use other DNS servers, and we just insure that their domain names are pointed to the DNS server they are using, which are then maintained by them.

I've got all my nameservers working ok, my MX record refers to my email domain (mail.) and my A record gives the DNS for that domain. Emails get to my IP but they are rejected with this...

Action: delayed
Status: 4.4.1
Diagnostic-Code: smtp; The recipient server did not accept our requests to connect

I'm fairly sure Qmail or tcpserver is rejecting the new IP the emails are coming from.

So you have an MX record in the zone file for (e.g.) "mydomain.com" that something like:

And a corresponding "A" record for smtp.mydomain.com:
Where x.x.x.x is the external IP of (or NAT to) your mail server?

Note that you also have to have NS records within the zone file to tell it what your name servers are even though whois may already have this information.

FYI:
It is difficult to help you without seeing your real details. If we knew your domain we could try to query your DNS records and also could try to see if attaching to your mail server works from remote locations.

Which server is sending that delayed messages?
If its the sending server, then
Are you sure your qmail-smtp is running? Does it show in Are you sure that port 25 is open on your firewall?
Please check the qmail log: /var/log/qmail/smtp/current to see if the request is even reaching your smtp server. If qmail is rejecting the mail, it would show in the logs, but if the request is not reaching the server, the bounce message will come from the sending server and there will be nothing in the logs.

My guess is it's the latter, and either your qmail-smtp is not running (unlikely if you're using tcpserver) or your port 25 is blocked.

There is nothing in the above that suggests it gets to YOUR IP. The only thing that can be positively stated about the above is that whatever it TRIED refused the connection. That could mean it got to mail server which refused it (unlikely as you'd expect a refusal reason in that case) or more likely that whatever it went to didn't accept mail traffic either because it isn't a mail server or because it didn't like the sender's IP (e.g. some spam filter or other blocked the sender's IP).

You might want to go to something outside your network and do test lookups and email verification. A good site for that (there are many) is: https://www.dnsstuff.com/tools

Use the DNS lookup to verify your MX record and the A record related to same (and/or AAAA if you're also using IPv6). Use the mail tools tab to check access to your mail.