Our company had 4 domains whose emails and DNS were hosted by usintegration.com, and then we moved the email and DNS hosting for 3 of the 4 domains to a new company. Now, the 3 domains that were moved can't send or receive emails to and from the one domain still left on the old server. All other email functions work fine for all 4 domains. There are no bouncebacks, error messages, or emails stuck in queue, and no evidence of these missing emails hitting the new servers.

The new hosting company (logixcom.com) confirms that everything is fine on their end, and assures me that it's most likely an old zone file still remaining on US Integration's nameserver, and so the emails sent from the US Integration is routed to what it believes is still the authoritative nameserver (it's own). Because the old zone file's MX records still contain the old resource, the requests never leave the old nameserver to go online to do a fresh search for the real (new) authoritative nameserver. The compounding problem is that US Integration isn't able to identify the problem, much less fix it.

Is the problem truly that this old zone file just needs to be deleted from US Integration's nameserver? If so, what's the best way for me to describe this to them? If not, what do you think could be the issue? Any help is much appreciated. I'm not in IT, so all this is new to me. I know it seems weird for me (the client) to have to do this legwork, but I just want to get this resolved.

Here's what I've done:

  1. Ran dig to verify that US Integration's MX records still point to the old authoritative nameserver, instead of going online to do a fresh search:

    ~$ dig @bart.usintegration.com courycollection.com mx

    ; <<>> DiG 9.6.0-APPLE-P2 <<>> @bart.usintegration.com courycollection.com mx ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61227 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

    ;; QUESTION SECTION: ;courycollection.com. IN MX

    ;; ANSWER SECTION: courycollection.com. 3600 IN MX 10 mail.usintegration.com.

    ;; ADDITIONAL SECTION: mail.usintegration.com. 3600 IN A

    ;; Query time: 29 msec ;; SERVER: ;; WHEN: Sun Dec 26 16:59:22 2010 ;; MSG SIZE rcvd: 88

  2. Ran dig to try to see where Logix's servers look when emails are sent from the 3 domains that were moved, and got refused:

    ~$ dig @faith.logixcom.net.net colcordhotel.com mx

    ; <<>> DiG 9.6.0-APPLE-P2 <<>> @faith.logixcom.net colcordhotel.com mx ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 31599 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available

    ;; QUESTION SECTION: ;colcordhotel.com. IN MX

    ;; Query time: 31 msec ;; SERVER: ;; WHEN: Sun Dec 26 17:00:14 2010 ;; MSG SIZE rcvd: 34

UPDATE 12/28/10: US Integration said they deleted the zone files, and subsequent dig shows that their resolvers are now pointing to the correct Logix nameserver, but the issues continue. Funny thing is that the US Integration owner (who has an @usintegration.com email) can email back/forth with me (who has an @courycollection.com email), but our sister property (colcordhotel.com who is hosted by US Integration) still can't send to us.


Have the old domains been fully removed from the old mail server? In many mail servers, if a domain is defined as a name served by that server, it will not even look to DNS to see where mail should be delivered (since it already hosts that domain, no need to look it up). Mail from old-domain.com to other-domains.com would just be delivered locally if they were still configured on the mail server, regardless of what DNS says to do with it.

As for incoming mail, it could be related as well. If the receiving server sees mail coming in from the Internet on domains that are supposed to be local (i.e. inbound SMTP without any sort of authentication or from a known IP range) then it may be treating it as suspect and filtering it as spam.

These sorts of things are also easier to diagnose when the real domains are used. Example domains are great for theoretical or generic problems, but specifics work much better for specific problems.

| improve this answer | |
  • I've updated the OP with the actual domains. Everything you say sounds right. From what I've learned, it seems that an old zone file still exists on the old nameserver, which is preventing the request from getting past the internal routing. Problem is, how should I explain this to the old host so that he can fix this? Is is as simple as telling him, "delete the zone file for all the domains that have moved away," and hope he understands? Or is there another way to get him to do what needs to be done? – maxfinis Dec 27 '10 at 9:58
  • It could be an old zone file, but I was referring to the mail server configuration itself (i.e. the mail server could still be set up to handle mail for the domains that are no longer pointed to it). – Justin Scott Dec 27 '10 at 18:31
  • No way for me to know for sure, but I was assured by US Integration that that was not the case. In fact, they've tried several times to fix this issue, but to no avail. – maxfinis Dec 27 '10 at 23:16
  • From the information provided, it does in fact appear that the old provider still has outdated DNS information on their name server which they will need to remove. If they don't have a clue as to how to do this, I'd move everything away from them sooner than later and use a provider with employees that know what they're doing. – Justin Scott Dec 28 '10 at 1:38
  • Believe me, we're trying to move as fast as we can to get away from them. We've already moved 3 of our 4 domains away, but we just can't move that last one right away. Also, I updated the question to show that US Integration did delete the zone files, but problem continues. – maxfinis Dec 28 '10 at 15:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.