Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1345
  • Last Modified:

Some cant resolve my mail server after a recent domain move, while most can.

here's the scenario:  Recently moved a customer's web domain from one provider to another. (ez-web to GoDaddy). Along with the outside website hosted by the provider, we are running an SBS2003 Exchange Server with the MX record for this domain pointing to the IP address of the company's firewall and exchange server at a different location.  When the domain was moved, the MX records were apparently reset to GoDaddy's internal email servers temporarily (about 2-3 hrs) before I became aware, and went into their interface and updated the MX and A records back to the IP and host of the mail server, not the webhost. Within 5 minutes after that, mail was incoming again and working.  However, since this move several customers report they cannot send email to us anymore, and have forwarded a variety of errors for me to try and correct on my end. I contacted GoDaddy and they say my MX and other DNS records are all set up properly, and confirmed they were working.  

here's one of the errors..which points to the incorrect mail servers... the domains and email addys are obscured here.

--- Session Transcript ---
 Fri 2008-06-13 11:11:57: Parsing message
 Fri 2008-06-13 11:11:57: *  From: customer
 Fri 2008-06-13 11:11:57: *  To:
 Fri 2008-06-13 11:11:57: *  Subject: TEST
 Fri 2008-06-13 11:11:57: *  Message-ID:
 Fri 2008-06-13 11:11:57: Attempting SMTP connection to
 Fri 2008-06-13 11:11:57: Resolving MX records for []
 Fri 2008-06-13 11:11:57: *  P=000 S=001 TTL=(50)
 Fri 2008-06-13 11:11:57: *  P=010 S=000 TTL=(50)
MX=[] {}
 Fri 2008-06-13 11:11:57: Attempting SMTP connection to
 Fri 2008-06-13 11:11:57: Resolving A record for []
(DNS Server:
 Fri 2008-06-13 11:11:57: * TTL=(4)
 Fri 2008-06-13 11:11:57: Attempting SMTP connection to
 Fri 2008-06-13 11:11:57: Waiting for socket connection...
 Fri 2008-06-13 11:11:57: *  Connection established (
 Fri 2008-06-13 11:11:57: Waiting for protocol to start...
 Fri 2008-06-13 11:11:57: <-- 220
 Fri 2008-06-13 11:11:57: --> HELO .com
 Fri 2008-06-13 11:11:57: <-- 250
 Fri 2008-06-13 11:11:57: --> MAIL From:<customer>
 Fri 2008-06-13 11:11:58: <-- 250 ok
 Fri 2008-06-13 11:11:58: --> RCPT To:<enduser>
 Fri 2008-06-13 11:11:58: <-- 553 sorry, relaying denied from your
[] (#5.7.1)
 Fri 2008-06-13 11:11:58: --> QUIT

here's another one..

-----Original Message-----
Sent: Tuesday, June 17, 2008 8:47 AM
Subject: Undeliverable: RE: PURCHASE

Your message did not reach some or all of the intended recipients.

   Sent: Tue, 17 Jun 2008 08:59:06 -0400
   Subject: RE: PURCHASE

The following recipient(s) could not be reached:
   Error Type: SMTP
   Error Description: No mail server
   Additional information: No mail servers exists for the address.

And the First one to report an issue, this error:

Subject: Delivery failure notification

With reference to your message with the subject:
   "Internet Messages"

The local mail transport system has reported the following problems it encountered while trying to deliver your message:

Error connecting to primary server ''.


Anything I can point these people to that will help them get more accurate DNS data and/or get them resolving this domain handled by Godaddy ??.. this last customer example tried to email me at another domain also handled by GoDaddy and it also did not get through, but did to another outside domain not associated to that in this case, it doesnt appear to be the destination mail server at all so much as the source sender having trouble resolving anything past godaddy name servers...   but all of the 3 cases now in front of me occurred just after this domain was moved and hasnt worked itself out in the last 4-5 days now.

Help !!  

  • 8
  • 6
1 Solution
So what you have here is a problem with DNS servers caching the temporary GoDaddy MX data.  Anyone who did an MX query on your domain has cached the incorrect MX info for whatever length of time was specified in the TTL field in the temporary GoDaddy zone file.  

Fortunately, this problem will eventually fix itself.  Unfortunately, there is almost nothing you can do to speed up the process.

sorry i dont have a better answer.

errr . . . i meant to say "Anyone who did an MX query on your domain while the temporary GoDaddy zone data was authoritative has cached the incorrect MX info for whatever length of time was specified in the TTL field in the temporary GoDaddy zone file."

AylwardAuthor Commented:
The TTL was for 1/2 hr to an hour.. and this is days later.
NEW Internet Security Report Now Available!

WatchGuard’s Threat Lab is a group of dedicated threat researchers committed to helping you stay ahead of the bad guys by providing in-depth analysis of the top security threats to your network.  Check out this quarters report on the threats that shook the industry in Q4 2017.

are you certain that the TTL was an hour in the GoDaddy temp zone data?  Cuz it doesnt matter what you had set before, or now; the SOA from the temp zone data would govern how long it was cached.

i understand you may wish not to, but if you can post the domain name, the community could be of more assistance.

AylwardAuthor Commented:
the domain is

 the TTL on that other entry showed as 1 hour when I changed it to the IP i needed it pointed to.
AylwardAuthor Commented:
This is the DNS listing I see at the provider for my domain. Am i missing anything ??

Name Servers: (Last Update 6/13/2008)
Total DNS: (Available)
ARecord mainserver
ARecord mail
ARecord @
CNAME www @
CNAME ftp @
MX @
So a few recommendations:

1 - You have an MX record that is listed as an IP address rather than a host name.  You need to change the record from to the canonical DNS name for that address (i.e., the unique A record for that address).  Fully RFC-compliant mailservers will not be able to send email to your domain until you change this.

2 - There is no rDNS (PTR) record for  This will not affect who can send you mail, but it will affect who you can send to.  You need to contact the ISP who owns the IP and either have them create a rDNS entry for the IP address, or delegate the zone containing that address to you.

3 - Also, not related to the MX issue, you have listed as a name server for your domain, but there is no NS record for it in your domain.

AylwardAuthor Commented:
i actually had it listed as the A record name and just changed it yesterday to the IP itself, hoping it would help those having trouble resolving that A record.. it didnt help but wasnt working as a pointer to the A record either. I will change it back. Unfortunately, still no closer to getting any of these 3 customers sending mail to us successfully yet, Im afraid.  :(
AylwardAuthor Commented:
still the same problem for these customers.... its not correcting itself.. anything else I can do here ??
i am still seeing your MX record as pointing to an IP address.  this may be because the TTL is set to a day and you only changed the MX sometime yesterday?

Here is what I am seeing from dnsreport::

FAIL Missing nameservers 2 ERROR: One or more of the nameservers listed at the parent servers are not listed as NS records at your nameservers. The problem NS records are:

FAIL MX is host name, not IP ERROR: You have one or more MX record(s) that contain an IP address. This is not valid. A fully RFC-compliant mailserver will not be able to send you mail (although some mail servers will, due to the TCP/IP functions that they use). The problem MX records are:

FAIL Reverse DNS entries for MX records ERROR: None of your mail server(s) seem to have reverse DNS (PTR) entries (I didn't get any responses for them). RFC1912 2.1 says you should have a reverse DNS for all your mail servers. It is strongly urged that you have them, as many mailservers will not accept mail from mailservers with no reverse DNS entry. You can double-check using the 'Reverse DNS Lookup' tool at the DNSstuff site (it contacts your servers in real time; the reverse DNS lookups in the DNS report use our local caching DNS server).

FAIL Connect to mail servers ERROR: I could not complete a connection to any of your mailservers! Could not connect without glue or A record.
If this is a timeout problem, note that the DNSreport only waits about 40 seconds for responses, so your mail *may* work fine in this case but you will need to use testing tools specifically designed for such situations to be certain.

I verified by doing an nslookup on the authoritative name server in case i was caching the data.  It appears that the zone data MX record itself still has not been modified to reflect a valid A-record DNS reference.

Until this gets fixed I cant really troubleshoot much more.

AylwardAuthor Commented:
can you run that again and see how it does now ?? it all resolves for me just fine, so your view is definitely helpful here. I have modified the MX records as suggested. Does it show up right now, short of the RDNS ??
AylwardAuthor Commented:
Your last gave me the last couple bits I needed I think... Thank you for the education in Mail DNS ! Obviously, I was lacking there...hehe.. One of my problem customers just got thru this morning, after the last MX record change.I believe you showed me what was wrong there..Thanks again !!
Everything appears to be RFC-compliant with the following exceptions:

1) There is an rDNS entry (RR's stock rDNS zone data), but it doesnt match your A record obviously.

In addition:

WARN Mail server host name in greeting WARNING: One or more of your mailservers is claiming to be a host other than what it really is (the SMTP greeting should be a 3-digit code, followed by a space or a dash, then the host name). If your mailserver sends out E-mail using this domain in its EHLO or HELO, your E-mail might get blocked by anti-spam software. This is also a technical violation of RFC821 4.3 (and RFC2821 4.3.1). Note that the hostname given in the SMTP greeting should have an A record pointing back to the same server. Note that this one test may use a cached DNS record. claims to be non-existent host <br /> 220 ESMTP (38228bb00cd6e368f95b35630d887d6b) <br />

WARN Acceptance of abuse address WARNING: One or more of your mailservers does not accept mail to Mailservers are expected by RFC2142 to accept mail to abuse.'s abuse response:<br /> >>> RCPT TO:<><br /> <<< 550 No such user ( <br />

WARN SPF record Your domain does not have an SPF record. This means that spammers can easily send out E-mail that looks like it came from your domain, which can make your domain look bad (if the recipient thinks you really sent it), and can cost you money (when people complain to you, rather than the spammer). You may want to add an SPF record ASAP, as 01 Oct 2004 was the target date for domains to have SPF records in place (Hotmail, for example, started checking SPF records on 01 Oct 2004).

None of these will likely prevent mail transfer, but they are easily corrected to bring them up to compliance.

The rDNS can be fixed by getting RR to change it, or by getting them to delegate to you rDNS for your IP block.

The hostname can be fixed by either changing the A record to or changing the hostname in the SMTP server from to

Create an email address for either via creating a new account or adding alias to existing account (postmaster@ or admin@, etc.)

You can learn about Sender Policy Framework here: 

Glad you got it worked out.


AylwardAuthor Commented:
all are working now... thanks again for your help !! :)  
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 8
  • 6
Tackle projects and never again get stuck behind a technical roadblock.
Join Now