Overview
For proper configuration of a public-facing mail server, it is necessary to configure public DNS records so that other mail servers can discover and distribute emails to your users, and so that other mail servers will trust you to receive your mail. There are also DNS records designed to protect you from spam and to help other servers to identify that your server is not a spam host.
- DNS Management
- DNS Records
- Related Articles
DNS Hosting Provider
Virtually all DNS Hosting Providers facilitate a web browser-based control interface used to modify your DNS records and should provide the technical support needed. Some common DNS Hosting providers are GoDaddy, Network Solutions, DigitalOcean, and DynDNS. Some ISP might also offer DNS hosting on your behalf, but make sure they offer a web-based interface DNS records control. All of their interfaces are different, but they accomplish the same basic thing; they allow you to publish your hostnames and important DNS records 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. 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.
Static or Dynamic IP Address
It's recommended to have at least one static IP address, as dynamic DNS hosting such as DynDNS has some drawbacks and limitations.
A Records
A record maps a name to an address. You will first need an A record for your mail server. Your static IP address from your ISP was the first step. For example, you might log into the web portal for the 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, mail servers still wouldn't know that this is where to send mail. That's what MX records are for.
MX Records
Your MX record tells other mail servers the name of the server on the Internet to send mail to for your domain. It is a free text field because it can have any name, including a name of a server from a mail hosting provider or a mail spam filter. If you have the Kerio Connect server with an A record mail.example.com you will need to create an MX record that just says mail.example.com as its value. For additional information, refer to Configuring an MX Record.
PTR Records
The PTR record is a reverse lookup which maps the IP address to the name.
Some mail servers will not trust mail coming from your server unless they can do a reverse DNS lookup. Strict mail servers do a forward lookup on the name your mail server 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.
The PTR record creation requires more advanced knowledge of DNS. It's recommended to contact your DNS hosting provider to create a PTR record on your behalf. They will ask the name you want, and what IP address you want to assign to that name. Knowing the A record for mail.example.com you must create a reverse PTR record.
Some hosting services are providing PTR records automatically if the server has a valid Domain name. Refer to the DigitalOcean PTR record discussion.
The successful PTR record creation can be checked in the MXtoolbox.
SPF Record
SPF allows the receiving mail servers to check during mail deliver that a mail claiming to come from a specific domain was submitted by an IP address authorized to send emails by that domain's administrators. Recipient email servers check a special TXT DNS record, which lists the authorized sending hosts and IP addresses corresponding to that domain.
Adding SPF records in the email sender's DNS is an effective way to prevent mail spoofing and avoiding mail rejection by the recipient's domain if they perform strict SPF checking.
Here is some information on how you can Help prevent spoofing and spam with SPF.
For information about SPF configuration in Kerio Connect, refer to Creating an SPF.
DKIM
DKIM (Domain Keys Identified Mail) is an email authentication technique that allows the receiver to check that an email was indeed sent and authorized by the owner of that domain. This is done by giving the email a digital signature. This DKIM signature is a header that is added to the message and is secured with encryption.
For additional information, refer to Configuring DNS for DKIM in Kerio Connect.
DMARC
DKIM and SPF are both necessary to prevent spam. DMARC is a DNS TXT record just like DKIM and SPF and it provides additional information on the role of these records i.e. what an email recipient server should do when the SPF and DKIM records are not aligned to each other.
For example, consider the following DMARC record
v=DMARC1;p=reject;pct=100;rua=mailto:admin@kerio.com
Here, the sender requests that the receive reject all non-aligned messages and send a report about the rejections to a specific address.
The following chart illustrates some of the available tags that can specify the intended behaviour:
| Tag | Purpose | Sample |
| v | Protocol version | v=DMARC1 |
| pct | Percentage of messages subjected to filtering | pct=20 |
| ruf | Reporting address for forensic reports | ruf=mailto:fail@kerio.com |
| rua | Reporting address for aggregate reports | rua=mailto:reports@kerio.com |
| p | Email rejection/quarantine policy | p=reject OR p=quarantine |
| sp | Policy for subdomains of the original domain | sp=reject |
| adkim | Alignment mode for DKIM | adkim=s (strict) |
| aspf | Alignment mode for SPF | aspf=r (relaxed) |
More details about configuring this are in Adding DKIM and DMARC Records to Kerio Connect.