2

It's been 24 hours since I added an MX record

The name was @, type was MX and value was mail.heeldiaries.com

There's also an A record with mail.heeldiaries.com pointing to the IP of the server.

When I do a mail-tester.com test it is saying

We didn't find a mail server (MX Record) behind your domain name heeldiaries.com

We check if there is a mail server (MX Record) behind your domain name heeldiaries.com.

You may want to publish a DNS record (MX type) for the domain name heeldiaries.com or use a different bounce email address.

Have I setup this up wrongly or is there another problem?

Community
  • 1
Shiv
  • 199
  • 1
  • 6

3 Answers3

6

You have much bigger problems in play here. When I attempted to run a dig +trace +additional on your domain, this is what I saw at the tail end of the output:

heeldiaries.com.        172800  IN      NS      ns1.heeldiaries.com.
heeldiaries.com.        172800  IN      NS      ns2.heeldiaries.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20160915044336 20160908033336 27452 com. xNERKmnAlkb3XiEf76OahP52D10WKZLu7GcWpYhVT4be0SBbmq9Kn+XV AnaMG/Ywu1/4VPyMfDxnw+XJLMXLn3NJN7TbNLA9Z0TqcpbRZcnTq1Na cO9/iuAx32Oaf5pbJIwuSS7HAhfDY4tahpYuSYDz8xOQzyf5W6wnjWAL sAc=
QJOOMS3U9KGEU3Q28GLBBD9JQUPTIIHO.com. 86400 IN NSEC3 1 1 0 - QJOQ3610JU9ONV7GVL7AF1JS331CDLT7 NS DS RRSIG
QJOOMS3U9KGEU3Q28GLBBD9JQUPTIIHO.com. 86400 IN RRSIG NSEC3 8 2 86400 20160914041706 20160907030706 27452 com. KMBTolTWT5O+kSWb6jxfV1KJwQ4BSuhdet4Z5de62vstjHsbIqbE0/De P+B3ueyu89cKi38Umht4PmZo8s33VSuuWpglncPxAZ5SR+IzE2KGNnsk mwjFrAtpvmp3CkVk9IP8yfud22WV/yNMvCpURBZ1kcx6VNapJFUDfMJJ Y6Q=
ns1.heeldiaries.com.    172800  IN      A       62.100.204.133
ns2.heeldiaries.com.    172800  IN      A       62.100.204.133
dig: couldn't get address for 'ns1.heeldiaries.com': no more
  1. The domain doesn't comply with BCP 16. Two nameservers sharing an IP is something you simply don't do, and it doesn't matter how small your site is. (adding another IP from the same datacenter won't help you here - make sure to read section 3.2)
  2. My upstream DNS server (Linode) choked when asked to return the authoritative answer for ns1.heeldiaries.com. While it's clear that glue exists for this DNS entry, there is a problem obtaining it from your DNS server.

Next, let's check for the presence of SOA and NS records. This should tell us whether the zone lives on the server at all, and whether we have some form of glue record mismatch.

$ dig @62.100.204.133 +short heeldiaries.com SOA
ns1.localhost.ltd. root.heeldiaries.com. 2016091014 7200 3600 1209600 180
$ dig @62.100.204.133 +short heeldiaries.com NS
ns1.localhost.ltd.
ns2.localhost.ltd.

There is a glue record mismatch here. You have configured your registrar to return NS records of ns1 and ns2.heeldiaries.com, but the authoritative NS records living on your DNS server are returning those localhost.ltd entries instead. Considering that localhost.ltd is a bogus domain that doesn't exist, the fact that things are broken should not surprise anyone.

$ dig localhost.ltd SOA | grep status
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 39368

Further, even if we ignore the fact that your domain completely breaks when the NS records are refreshed, you don't have A records defined for the nameservers in your glue:

$ dig @62.100.204.133 ns1.heeldiaries.com | grep status
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 60693
$ dig @62.100.204.133 ns2.heeldiaries.com | grep status
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5663

In short, your entire DNS configuration is hosed. If you were not the one who set this up, please have some stern words with the person who did. I strongly encourage you to move this domain to any number of free and reputable DNS hosting companies. You would not have had these problems if your company wasn't trying to host its own DNS with neither the appropriate resources (geo-redundancy) or training.

Community
  • 1
Andrew B
  • 31,858
  • 12
  • 90
  • 128
  • 1
    You've corrected everything that you're able to for the moment, yes. Everything else appears to be in order and mail delivery should be more reliable. That said, until the single IP issue is addressed you will still be subject to intermittent lookup failures when clients are temporarily unable to route to the single IP. There's no getting around that problem until the employer is willing to invest in a proper solution. – Andrew B Sep 11 '16 at 02:28
  • 1
    Also, as a courtesy I'd like to warn you that you've been placed in a situation of extremely high liability. Authoritative DNS hosting is not half as simple as most people who enthusiastically make this decision believe it to be. You are not trained to troubleshoot these problems (which I mean as no insult), and you have been handed a mess. Make sure your client understands that you accept no liability for being placed in this situation. Please link to these comments if needed. – Andrew B Sep 11 '16 at 02:33
  • 1
    @Shiv note that this highly-detailed and excellent analysis by AndrewB was only possible because you didn't redact your domain name - **thank you for that**. You may wish to accept AndrewB's answer by clicking the "tick" outline next to it (I would!). Other posters, please note: [the less information you withhold or mislead us about, the more accurate an answer you are likely to get](http://meta.serverfault.com/a/6574/55514). – MadHatter Sep 11 '16 at 05:49
  • Thanks AndrewB, that was a big help! Thanks a lot! And @MadHatter Thanks and yep his analysis was top quality :D I accepted the answer because it fixed the main problem as well: 10/10 now on mail-tester. Thanks again! – Shiv Sep 11 '16 at 06:04
  • Nope. The best I can do is encourage you to read [the Q&A I linked earlier](http://serverfault.com/q/710108/152073). The short version is that you can't control where packet drops are going to occur along any given network route, or how frequently. (therefore you should provide at least two routes) – Andrew B Sep 11 '16 at 18:47
-1

I'm getting off and on hit's still at some DNS Providers, I believe it's still propagating. You can use this MX Lookup Tool, it allows your to choose different providers. When I switch between providers, you can see it appears and disappears. But it may be stable by the time you read this. Also test with this eMail Tester, it's a lot better.

MadHatter
  • 78,442
  • 20
  • 178
  • 229
Henry
  • 910
  • 1
  • 5
  • 17
  • -1 for propagating the myth of DNS propagation. The OP's MX record doesn't propagate and isn't going to propagate, because DNS records don't propagate. Additionally, the MX record is new, so there isn't any DNS caching involved. – joeqwerty Sep 10 '16 at 13:24
  • 1
    It's the common terminology for TTL Caching and in my language "proprograte" is referred as promoting. Once your TTL Cache expires at the DNS Servers your new DNS Records are Promoted, AKA Proprogated. So when I say your DNS records are still proprogating, I mean they are still being promoted, which occurs when the TTL Cache expires. – Henry Sep 10 '16 at 14:09
  • 1
    Common or not, it's incorrect and only serves to give people who don't understand DNS the misconception that they have to wait for their DNS records to propagate to other DNS servers. Additionally, as I stated in my original comment, the OP newly created the MX record, which means it can't have been cached anywhere. If the MX record had already existed and the OP merely changed it then TTL caching would have been at play. As it stands, that isn't the case here. – joeqwerty Sep 10 '16 at 14:15
  • 1
    @joeqwerty not to carp, but can't a negative response also be cached? Just because an RR is newly-created doesn't mean that a local resolver won't have cached a previous NXDomain in response to an earlier query. – MadHatter Sep 10 '16 at 14:25
  • 1
    @MadHatter: Yes, and maybe I'm being too pedantic but this answer didn't say that. This answer very clearly stated `I believe it's still propagating`, which is technically incorrect. TTL caching and propagation aren't the same thing. I'm not trying to be a jerk here, I'm just trying to illustrate that we're using the wrong term and perpetuating a misunderstanding when we use the term propagation in relation to questions like this. – joeqwerty Sep 10 '16 at 15:11
  • I agree with @joeqwerty, it is highly inappropriate to imply that any form of propagation occurs with record adds. (the real problem here is misconfiguration) – Andrew B Sep 10 '16 at 16:44
  • @joeqwerty I'm not sure I'd support your greater point with respect to the use of the term propagation in the context of DNS changes, but whatever we understand that term to mean (or not!), I agree that it is clearly not the problem in this question. – MadHatter Sep 11 '16 at 05:43
-2

The records have propagated. Use http://mxtoolbox.com/ to check the status of the DNS records. Alternatively, run nslookup to see the current status of the domain record : nslookup set type= any heeldiaries.com

Peter Nduati
  • 334
  • 1
  • 6
  • -1 for propagating the myth of DNS propagation. The OP's MX record doesn't propagate and isn't going to propagate, because DNS records don't propagate. Additionally, the MX record is new, so there isn't any DNS caching involved. – joeqwerty Sep 10 '16 at 13:24