DNS : Keys to Email Delivery
DNS stands for Domain Name System and is a protocol for exchanging data on the Internet.
When you want to visit a website, you turn on the computer, open a web browser, and type in the domain name you want to visit, e.g. mmd-ca.com. The DNS then translates the name into an IP address. An IP address is a series of numbers separated by stops (e.g. 185.54.72) that identifies resources connected to the internet.
Likewise, email is associated with a domain name with certain more advance requirements, specifically to prove who you are and that you are not sending out an email under someone else domain name. AKA, you are not a spammer.
Most of the time, your hosting provider will manage these settings and process. Sometimes to your advantage and other times not. The keys for you to know what you really need set on your domain name, from your hosting provider, to make sure that your domain is not hijacked and blacklisted.
A word of warning though: this process is a constant battle, with requirements as defined by other servers, servers your email has to go through to be delivered. These rules are constantly being updated.
As of September 2021, the following are recommend settings and choices:
Static or Dynamic IP Address?
Do everything you can to have a static IP address. It is very difficult to run a business and control your email delivery, with a dynamic home-user Internet plan. This also means you hosting will not be cheap. At the very least, be associated on a server with no more than 30 hosting accounts.
Most hosting and the associated email, that are inexpensive, will place you on a server with thosands of other accounts. Thus customization of site and email options are next to none.
This article assumes you have at least one static IP address or have a hosting provider that is willing to customize and monitor the settings on your behalf.
WHAT ARE THE DNS KEYS REQUIRED FOR EMAIL
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.
TTL (Time to Live)
The MX Record, tells other mailservers on the net, what the name of your server is on the net.
TTL (Time to Live)
The PTR record is a reverse lookup which maps the IP address to the name. It is a key record in that many mailservers on the net, 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.
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.
A useful tool for creating your SPF Record is by SPF Wizard. or MXToolBox
TTL (Time to Live)
v=spf1 +a +mx +ip4:162.xxx.xxx.xx +v=spf1include:servers.mcsv.net?all ~all
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.
Today, this method has been abandoned in favor of the SPF method.
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.
Once receiver (or receiving system) determines that an email is signed with a valid DKIM signature, it’s certain that parts of the email among which the message body and attachments haven’t been modified. Usually, DKIM signatures are not visible to end-users, the validation is done on a server level.
Implementing the DKIM standard will improve email deliverability. If you use DKIM record together with DMARC and SPF, you can also protect your domain against malicious emails sent on behalf of your domains.
The most important reason to setup a DKIM record is that Gmail uses default DKIM. Without your server defining it, there is a great possibility that your emails will either be placed in spam or bounced.
For information on how to create your DKIM signature, read googles process article.
v=DKIM1; k=sa; p=”Your DKIM Signature“
Newer to the authentication party is the DMARC Record. Domain-based Message Authentication, Reporting, and Conformance, or DMARC, is a technical standard that helps protect email senders and recipients from spam, spoofing, and phishing. DMARC allows an organization to publish a policy that defines its email authentication practices and provides instructions to receiving mail servers for how to enforce them.
A DMARC record is included in an organization’s DNS database. It is a record that is a specially-formatted version of a standard DNS TXT record with a particular name, namely “_dmarc.mydomain.com” (note the leading underscore). The defining elements are as follows:
- v=DMARC1 specifies the DMARC version
- p=Policy of mail non-compliance: none, quarantine or reject.
- sp=Policy for any subdomain mail non-compliance: none, quarantine or reject.
- rua=mailto:email@example.com is the mailbox to which aggregate reports should be sent
- ruf=mailto:firstname.lastname@example.org is the mailbox to which forensic reports should be sent
- pct=100 is the percentage of mail to which the domain owner would like to have its policy applied\
A Classic DMARC record looks something like the below. Also note, that many mail servers will reject emails unless a policy has been defined. Using the p=none, will result in a error.
v=DKIM1; p=”none” or “quarantine” or “erject”;sp=”none” or “quarantine” or “reject”; rua=mailto:email@example.com; ruf=mailto:firstname.lastname@example.org