Essential DNS Records for Mail Delivery and Spam Protection
Details
DNS Hosting Provider
Virtually all DNS Hosting Provider provide a web browser based control interface used to modify your DNS records, and should provide the technical support needed if you get stuck trying to modify any of the DNS records discussed in this article. Some common DNS Hosting providers consist of companies such as GoDaddy, Network Solutions and DynDNS to name three. There are possibly hundreds, so shop around if you have not found one yet. Many companies, including your own ISP might offer DNS hosting on your behalf, but make sure they offer a web based interface which allows you to have some control over your DNS records and make sure they offer good technical support. All of their interfaces are different, but they accomplish the same basic thing; they allow you to publish your hostnames and important DNS records such as the ones mentioned in this article to the Internet.
Hosting Your Own DNS
From within your DNS web hosting portal, it might be possible to configure it to not host your DNS, but instead to point your NS records someplace else. You could point your NS records to another DNS hosting provider or to your own DNS server at your static IP address. This article does not discuss how to do this, but if you are pointing it to your own DNS servers under your direct control, you must have advanced knowledge of the DNS servers you are managing or must have access to the documentation needed to create the DNS records yourself. This article still may prove useful to let you know what kinds of records you need. You still may need additional references to look up how to create them if you are not an expert with the DNS server you are managing. However, this article is aimed primarily at readers who will be using a web based DNS hosting service with it's own technical support to help them if they need assistance with their DNS.
Static or Dynamic IP Address
Do everything you can to have a static IP address. It is very difficult to run a business with a dynamic home-user Internet plan. If there is no alternative, it might be possible to use something like DynDNS to do dynamic DNS hosting, but there are drawbacks this article will not cover. This article assumes you have at least one static IP address. For the most part, the web interface will be similar, however, at a dynamic DNS hosting provider.
"A” Record
An "A" record maps a name to an address. You will first need an A record for your mailserver. Your static IP address from your ISP was the first step, of course. For example, you might log into the web portal for the example.com domain and create an "A" record for "mail" for 192.0.2.21. This would create a mail.example.com published on the Internet. However, mailservers still wouldn't know that this is where to send mail. That's what "MX" records are for.
"MX” Record
Your MX record tells other mailservers the name of the server on the Internet to send mail to for your domain. It is a free text field, because it could have any name, including a name that is not part of your domain such as a name of a server from a mail hosting provider or a mail spam filter for example. If you have the Kerio Connect server with A record mail.example.com, you will need to create an MX record that just says "mail.example.com” as its value.
A separate Kerio Knowledge Base article discusses MX records:
The PTR record is a reverse lookup which maps the IP address to the name.
Some mailservers will not trust mail coming from your server unless they can do a reverse DNS lookup. This takes two possible forms. Most mailservers care that a PTR record exists at all. Strict mailservers do a forward lookup on the name your mailserver introduces itself as such as mail.example.com, verify it is the IP address that is read off the connection, and do a PTR lookup on that IP address to see if it resolves to the same name.
A very common mailserver that comes to mind is craigslist. AOL is also famous for doing this check, and they have changed their minds from time to time and taken this check off, but it is impossible to predict when they will put the check back on again because they have several times in the past and still do sometimes.
The PTR record is more difficult than the others because it might require more advanced knowledge of DNS. This PTR record discussion here will assume you do not control your own PTR records. This assumes you own only a small number of IP addresses, and you must call your Internet Service Provider (ISP) to ask them to create a PTR record for you. Knowing the A record for mail.example.com, you must create a reverse PTR record. Most ISPs have a DNS Services department which can create a PTR record for you. They will ask the name you want, and what IP address you want assigned to that name. Beware, the person answering the phones often does not know what a PTR record is, and you often must get past that person to make the call work out. First ask for a PTR record and see if they know what to do. Next, ask if they have a DNS services department.
If you must create your own PTR record you will need to do it in your own DNS hosting services web interface. You might need to call them for support. If you host your own DNS, you will need to create a reverse zone which is not covered in this article.
"SPF” Record
SPF gives other mailservers a way to verify that mail claiming to be from your domain is from one of your IP addresses. They do this by checking a special TXT record you put in your DNS records. It is an interesting way to prevent mail spoofing.
For more information about SPF, see Kerio KB 248
"Caller-ID” Record
Caller-ID was an earlier way to do what SPF does today. As with SPF, Caller-ID gives other mailservers a way to verify that mail claiming to be from your domain is from one of your IP addresses. They do this by checking a special TXT record you put in your DNS records. It is an interesting way to prevent mail spoofing. Caller-ID is not nearly as popular as SPF, but does protect you slightly differently than SPF. Because of this, not everyone believes Caller-ID is irrelevant. Read KB 248 for more information about this:
Recommended Reading
Mail Routing is discussed in RFCs 5321 and 2821.
Some DNS errors including some useful discussion of PTR records and email security are included in RFC 1912:
SPF is documented in RFC 4408. This RFC is actually an easy read as far as RFCs go.
Caller-ID is an internet draft on the IETF website: