What are MX Records? Anatomy of a DNS Zone File – Part Three


A mail exchange record or MX record is a type of record in a DNS zone file. MX records are responsible for specifying which mail server is in charge of receiving email messages on behalf of a domain.

When you send an e-mail, your computer queries the DNS for the MX records of the recipient’s domain name.  This query results in a list of all available MX records that are responsible for accepting incoming mail.  The email client then attempts to make an SMTP (Simple Mail Transfer Protocol) connection to the primary mail server.

MX records are ranked by priority from lowest to highest to specify which mail server is the primary one.  The primary server is always the one to be used, unless it is unavailable and then, the next subsequent server is tried.  If there are no MX records available, the server will simply request the A record of the domain.

I used the following dig query to find the MX records for no-ip.com: dig no-ip.com MX +short (the +short condenses the reply to only show the MX records)

dig no-ip.com MX +short

10 mail1.no-ip.com.
15 mail2.no-ip.com.
5 mail0.no-ip.com.

The reply shows that there are three MX records for no-ip.com.

The primary mail server that email will be routed to is mail0.no-ip.com.  If that server is unavailable, the mail client will then try mail1.no-ip.com, lastly, if that server is unavailable too, it will try mail2.no-ip.com.

To increase reliability, if there are multiple MX records with the same preference number, all of these must be tried first, before the email client can try the next subsequent record. The SMTP client will try all of the MX records until delivery is successful.

Multiple MX records make primary and backup mail possible, but what if you don’t want the headache of running multiple mail servers, but still want the redundancy? No-IP has two easy solution.

Backup MX gives you mail redundancy on exclusive networks with professional mail server admins monitoring the system. Not only that, but No-IP’s Backup MX servers filter viruses and employ RBL lists to help keep the junk from reaching your inbox. No-IP also allows you to provide a valid user list so that bad mail can be stopped at the SMTP level, saving connections and resources on your server.

Another No-IP product, Mail Reflector will help you get around Port 25 if your ISP blocks it.  Mail is first delivered on the standard port to our mail system and then is immediately delivered to your mail server on whichever port you specify. This gives you complete control of your mail system and bypasses seemingly insurmountable restrictions. Mail Reflector also provides all of the features of Backup MX, including virus filtering, greylisting, and customizable RBL lists, so that even if your mail server is temporarily unavailable, mail will not be lost.

Backup MX or Mail Reflector can save you time, money and unnecessary headaches.

Questions on MX records or our mail services? Leave them below!

Check out Part One and Part Two of this series:

The Anatomy of a DNS Zone File: SOA Record

The Anatomy of a DNS Zone File – Part Two: What are NS Records and Why Are They Important to DNS?

Want Email Without the Headache of Managing Your Own Mail Server?

Managing a mail server isn’t for everyone and if you, like myself, are not so technically inclined, then you should definitely consider our POP3/IMAP service.  No-IP’s POP3/IMAP mail service gives you complete email service for your domain, without the headaches or the technical experience that is needed to run your own mail server.

The following are the pros of choosing our POP3/IMAP mail service versus running your own mail server:

1. Control email for your own domain without the cost or hassle of running your own server

2. No need to hire an internal resource to manage your server, with our POP3/IMAP service, all of the technical stuff is handled by us!

3. Travel a lot or work from home? With POP3/IMAP you can access your email anytime and anywhere with webmail!

4. RBL (Realtime Blackhole List) and virus scanning help avoid spam (no not the “meat” in a can) and junk mail

5. Secure back-up capabilities to ensure that none of your emails ever get lost

6. Full control and access to your account to allocate and control memory usage and add/remove users

So, what are you waiting for? Sign Up for our POP3/IMAP service today.  No-IP POP3/IMAP offers tiered accounts for every need, large and small! Questions or comments? Leave them below!

Dig Tutorial

First and foremost, what the heck is Dig? Dig is an acronym for “domain internet groper”.  Dig is a useful tool for webmasters and system administrators, it can be used to query DNS servers and fix DNS related issues.  Dig is a part of the BIND DNS software.

There are many beneficial and useful ways to use dig.  Do you ever find yourself needing to make changes to DNS records, but aren’t sure how to verify your changes?

Check out the following breakdown of a dig query.

Type the following dig query into your Terminal and follow along!

dig www.no-ip.com

This query will call on the A record for the domain name www.no-ip.com.

So, lets dive into this a little deeper and explain what each part of the response means…

The first two lines tell us the version of dig that is being used, in my case, i am using version 9.4.3-P3, the command line parameters (www.no-ip.com) and the query options (printcmd). The printcmd options means that the command section (the name of these first two lines) is printed. You can disable this response by using the option +nocmd.

; <<>> DiG 9.4.3-P3 <<>> www.no-ip.com
;; global options: printcmd

Next, dig tells you the response that it collected from the DNS server. The answer received was (opcode: QUERY) and that the response contains 1 part in the answer section, 5 parts in the authority section and 6 parts in the additional section. Just before those responses you will see “flags”.  Flags state certain things about the DNS server and its response.

-qr (query response) simply means this is a response to a query
-rd (recursion desired) means that the incoming query requested recursive  support
-ra (recursion available) means that the responding server supports recursive queries

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55423
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 6

The question section is next. This section just states what I queried, in this case, I queried the A record of www.no-ip.com and it is in the Internet class or IN.

;www.no-ip.com.                       IN                  A

The answer section follows; it adds the IP address of www.no-ip.com, and it also names all of the NS records that are authoritative for the domain.

www.no-ip.com.    60          IN                  A    
no-ip.com. 50531              IN                  NS             ns2.no-ip.com.
no-ip.com. 50531              IN                  NS             ns4.no-ip.com.
no-ip.com. 50531              IN                  NS             ns5.no-ip.com.
no-ip.com. 50531              IN                  NS             ns3.no-ip.com.
no-ip.com. 50531              IN                  NS             ns1.no-ip.com.

The additional section lists the IP addresses of all of the NS records, along with what type of record they are.

ns1.no-ip.com. 7702             IN                  A  
ns1.no-ip.com. 128              IN                  AAAA         2620:0:2e60::33
ns4.no-ip.com. 128              IN                  A  
ns2.no-ip.com. 79306            IN                  A  
ns5.no-ip.com. 79306            IN                  A  
ns3.no-ip.com. 19260            IN                  A  

The last section just gives stats about the query: how long it took, the IP address it was queried from and how large the message was.  You can disable this reply by using the +nostats option.

;; Query time: 48 msec
;; WHEN: Fri Apr  8 11:22:02 2011
;; MSG SIZE  rcvd: 245

Using dig can help you troubleshoot your DNS related issues.  How often do you use dig?

The Anatomy of a DNS Zone File – Part Two: What are NS Records and Why Are They Important to DNS?


An NS record or (name server record) tells recursive name servers which name servers are authoritative for a zone.  Recursive name servers look at the NS records to work out who to ask next when resolving a name.

You can have as many NS records as you would like in your zone file.   The benefit of having multiple NS records is the redundancy of your DNS service.  It is important to note that in order to get the most redundancy out of your NS records, they should be hosted on different network segments.  If they are not hosted on different networks segments and the network goes down, your DNS goes down with it. Check out No-IP Plus Managed DNS if you are interested in redundancy and reliability for your domain.

NS records help to ensure that all of the domains on your server are available at all times. Multiple NS records ensure that your customers are able to reach your site each and every time without any problems, even if one or more of your nameservers are unreachable. (Again only if they are hosted on different network segments.)

An example of this is if your business is located in an area that is hit by a natural disaster and your web servers at that location are down, your NS records will point to an additional name server that is hosted elsewhere (where mother nature has not wreaked havoc) and the customers are still able to reach your site and will never suspect anything is awry.

Another great example is if your website is attacked by a DDoS (Distributed Denial of Service) attack your entire website will not be down. Traffic will be routed to the other name server location that has the backup of the primary name server.

Please see the following example of the NS records for No-IP.com
no-ip.com. 73002 IN NS ns1.no-ip.com.
no-ip.com. 73002 IN NS ns2.no-ip.com.
no-ip.com. 73002 IN NS ns3.no-ip.com.
no-ip.com. 73002 IN NS ns4.no-ip.com.
no-ip.com. 73002 IN NS ns5.no-ip.com.
no-ip.com. 73002 IN NS ns1.no-ip.com.

Check out Part 1 and Part 3 of this series:

The Anatomy of a DNS Zone File: SOA Record

Anatomy of a DNS Zone File Part Three: MX Records


Questions or Comments? Please leave them below.