This article provides a quick overview of the DNS records required for an email server and presents a minimal sample configuration. The example assumes that you are running servers for both email and the web. Comments indicating the changes if you are using a third-party provider are provided.
I have already done several postings on email. Many of these articles have focused on detecting and reducing incoming Spam. This article focuses on configuring DNS for small email domains. Most servers delivering personal email get this reasonably right. (After all, there is a person who will complain if his mail gets blocked). Automated systems tend to be less likely to be configured correctly. Establishing credibility starts with showing authorization. Configuration of the mail server is a minimal portion of this. Properly configuring DNS provides a significant level of credibility.
If you don’t have a domain, any of the many email providers should be sufficient for reasonable volumes of email. From time to time some providers are used to send Spam, but they should deal with it promptly. Their Spam ratio is usually small enough that you don’t need to worry about it. Pick one and stick with it. You should be able to skip the rest of the article or read it for interest. You may want to check if your service complies with these recommendations
If you own a domain, your DNS records need to be properly configured. You also have the ability to create unlimited sub-domains under your domain. Think carefully about which sub-domains you create. Each Internet host should have its own (possibly private) sub-domain. Common services like mail and web usually have their own sub-domain as well. You should consider the following record types:
The following zone configuration is a minimal configuration for an example domain (example.com) with a mail server on address 192.0.2.11 and a web server on 192.0.2.10. NS records are provided by the domain provider (example.net). Mail for the domain is only sent and received by smtp.example.com. (There is nothing magic about the “smtp” name, and you can use any name you choose instead.) Hostnames are not included as they do not need to be publicly visible. Mail and web servers typically have their own name which may be only published on the internal mail server.
- SOA
- Identifies the authority for domains with name servers. Includes an email address (usually hostmaster) to which problems with the domain can be sent. Forward this address to an administrator who can deal with any reported issues.
- NS
- Used to identify the authoritative Name Servers for the domain. Your domain (e. d. example.com) will require name servers. You must have at least two, and I would recommend no more than five or six. Many domain registrars provide DNS servers for free or at low cost. The domain registrar’s DNS servers should be adequate for most small domains. Configuring your own name servers correctly is a difficult task. (Names servers should be available with as close to 100% availability as possible.)
- A
- Provides an IPv4 address for the domain. Required for the target of an MX record unless an AAAA is used. Every host must have an A or AAAA record to be reachable by name. Optional for other domains. A domain may have multiple A records.
- AAAA
- Provides an IPv6 address for the domain. This is equivalent to an IPv4 A record. If you have IPv6 addresses, it is recommended you use them in addition to IPv4 addresses.
- PTR
- Returns one or more DNS names for an IP address (IPv4 or IPv6). Required for servers sending mail to other servers on the Internet including the MX. Optional in most other cases. These are configured by the IP address provider, normally your ISP. For IPv6 addresses, you likely have or can have control of the IPv6 records.
- MX
- Identifies the mail server for a domain. The target domain (mail server) must have a static IP address. An MX record has a priority in addition to a target domain (the mail server). The target domain must have an A record (and/or an AAAA> record for IPv6). If you use SPF>, the domain must permit the MX to send mail on its behalf, but need not allow itself to send email. Your mail servers should have high availability (98% or higher). An occasional outage of a few hours should be acceptable. Your mail server should identify itself using this name as a FQDN (Fully-Qualified Domain Name).
- TXT (SPF)
- Provides free form text records. Sender Policy Framework (SPF) is a specific format that specifies the email seding policy for the domain. See Protecting your Email Reputation with SPF for more details. Formatted TXT records are also used to distribute DKIM (Domain Key Identified Mail) and DMARC (Domain-based Message Authentication, Reporting and Conformance) data. At a minimum you should have SPF records for your domain and its MX address.
- CNAME
- Used to redirect one domain to another. Not allowed for the target of an MX record, but commonly used for web servers. Only useful for leaf sub-domains. No other record types are permitted with a CNAME.
;; -*- zone -*-
$ORIGIN example.com.
$TTL 48H
@ IN SOA ns1 hostmaster (
2012040900 ; serial
12H ; refresh for slaves
15M ; retry
4W ; expire time at slaves *2
3H ; negative TTL *2
)
IN NS ns1.example.net.
IN NS ns2.example.net.
IN A 192.0.2.10 ; Web sever at example.com (optional)
IN MX 10 smtp
IN TXT "v=spf1 mx -all"
smtp IN A 192.0.2.11
IN TXT "v=spf1 a -all"
www IN A 192.0.2.10 ; Standard web server address.
IN TXT "v=spf1 -all"
imap IN CNAME smtp ; Address imap service
mail IN CNAME smtp ; SMTP address for mail clients
;; EOFYou may have noticed that there is no PTR record in the above configuration. The pointer record is configured in a separate file and is often controlled by a different organization. For smaller organizations, it is usually controlled by their (Internet Service Provider. It will be necessary to contact them to have them set the name in the PTR record for the mail server (192.0.2.11) to be the name on the A record (smtp.example.com).
The PTR record and A records for the mail server are used for rDNS (reverse DNS) validation by many email servers. If the PTR does not point to an A record which in turn points back to the same PTR, rDNS will fail. Some servers refuse email from hosts for which rDNS fails, and others send the email to the Spam folder. Neither case is desirable.
The name your MX identifies it as needs to be a fully qualified domain name, and it should be the name on the PTR record for the IP address connected to the Internet. rDNS validation may be applied to the name presented in the HELO or EHLO command. The hostname of the MX is usually not the same as the name it uses while communicating as an MX. However, the hostname registered in DNS is usually the name the MX uses to identify itself.
Notes:
If you use a third party for your mail server, specify their MX name instead of SMTP in the MX record. You will need to use a fully qualified domain name (mail.example.net.) ending with a period. If you forget the period, your domain will be added to the end of the name you specify.
If you use a shared third party server for your web server, you likely will use a CNAME record to point to their server. Append a period to the end of their server name so that your domain name doesn’t get appended to the end of the name.
Verify your configuration with the nslookup, host, or dig command. nslookup and host both allow you to specify a nameserver to query. Verifying the results from your NS servers immediately after changes allows you to catch problems before they are cached in too many servers. If you are using your domain registrar’s DNS servers it may take a few minutes after you make a change before it is visible.