As a server admin, I don’t know much about how to build a big list or write compelling copy to boost conversion rates, but I do know that having the right DNS records is key to successful email delivery.
The 3 Records you must know for good email delivery are:
These are the 3 core records you must have correct for sending email. Of course, you need an MX record if you want to receive email, but that’s another topic.
Below I explain how to setup your DNS records to ensure the best delivery of your email. If you have done this or still having issues, consider our email checkup service. The fee is usually $250 per server. We go over every aspect of your email server setup.
We do not offer support of MS Exchange or other mail transfer agents at this time.
If you need help, please contact us for details.
If you have to get one DNS record right, the reverse DNS record, also know as a PTR record, is the one. Without a valid reverse DNS record, many ISPs will block your email . As the name states, these records do the reverse of what a normal DNS A record does — they map IP addresses back into host names. Here’s a simple example showing a forward, conventional DNS lookup using an A record and a reverse DNS record.
Here’s another example from Microsoft:
Forward A record:
;; ANSWER SECTION: mail.microsoft.com. 681 IN A 220.127.116.11
Reverse PTR record:
dig -x 18.104.22.168
;; ANSWER SECTION: 22.214.171.124.in-addr.arpa. 3600 IN PTR mail.microsoft.com.
In the DNS lookups, you can see that the A record for mail.microsoft.com resolves to 126.96.36.199 and that if we lookup up 188.8.131.52, we get back mail.microsoft.com. There is no requirement that the forward and reverse lookups must match but it is helpful if they do.
In most cases, you cannot just add a reverse DNS record to your own nameservers. Due to how the lookup functions, your server provider likely has to set the reverse DNS record for you. At our partners, they either provide a portal interface or we have to open a support ticket for them to do this.
PTR records are a 1:1 mapping. You can only have 1 domain assigned to a PTR record. This can create problems if you have multiple domains on a single server.
Generally, you want the forward and reverse DNS lookups to match as in the example above. While this is not an official requirement, I recommend you set matching records when possible as some systems will reject email when they do not match.
Dedicated IP addresses may help but only if your mail server sends email on the dedicated IP address and not the server’s primary IP. The best way to tell is to send a test message and review the headers. If the primary IP is used, set your reverse DNS record to the server’s hostname. If the site’s dedicated IP is used, set your reverse DNS record to the site’s domain name.
After reverse DNS, email service providers now often require valid SPF (Sender Policy Framework) records. Even if they do not hard block your email, an absent or incorrect SPF record may trigger additional email filtering. This secondary filtering is what often causes the email to fail.
The SPF is a TXT type record that specifies what servers may send email on behalf of your domain. In the figure below, you can see how a system uses SPF to make decisions about how to route an email.
If you follow the flow, you will see that the recipient server (2) tries to verify the SPF record or Sender ID Framework in Microsoft’s nomenclature. The pass/fail status of the SPF record is then passed from the check stage in step 3 to the reputation data filter in step 4.
If you fail SPF authentication, most ISPs will give you a poor reputation score and route your email to the spam or junk folder — some may even just block the email entirely.
Here is an example of a SPF record, again using Microsoft:
microsoft.com. 3600 IN TXT "v=spf1 include:_spf-a.microsoft.com include:_spf-b.microsoft.com include:_spf-c.microsoft.com include:_spf-ssg-a.microsoft.com include:spf-a.hotmail.com ip4:184.108.40.206 ip4:220.127.116.11 ip4:18.104.22.168 ip4:22.214.171.124 ip4:126.96.36.199 ~all"
This is a DNS TXT record that specifies what IPs and other systems are allowed to send email on behalf of microsoft.com. Here you will notice that the SPF record uses IP addresses and include statements, but you can also simply include A or MX records.
Fortunately there are many SPF wizards available to help you automatically generate these records.
I often see these errors in regard to SPF DNS records. This is especially true on cPanel or Plesk type servers where a default SPF DNS record may not be accurate.
As with the reverse DNS issues, if you use shared hosting or have multiple sites on the same domain, you need to check what IP your email uses. Many control panel systems will include the IP for the domain’s DNS A record, but for a site on a dedicated IP address, this may not be the IP used by the email system. In these cases, you need to add the ip4 record with server’s main IP.
Don’t forget 3rd parties that may send email on your behalf. For example, if you use MailChimp, Sendgrid or some other email delivery service, they should provide you with an include record to add to your SPF TXT statement. For example, our billing services run from a 3rd party and we had to get them to supply us with an SPF include record.
If you use your ISP’s SMTP server, Gmail or similar 3rd party email service provider, you will need to get them to provide you with an SPF include record. I often see marketing firms using their web servers for sending out campaigns but then use Gmail for their own email. Google provides some good info on SPF records if you use their email services
Lastly, you are often better off not having an SPF record at all than having an incorrect one. If you have an incorrect SPF record, some systems will reject your email while if you simply lack an SPF record, you message is accepted but undergoes more rigorous spam checks.
Just like SPF records, you are better off having no DKIM record at all than having an incorrect one. I find DKIM is often misunderstood. While I see DKIM DNS records being used by some spam systems, the initial intent of DKIM was email security not spam.
The goal of DKIM is to allow you to be certain that a message from domain.com is indeed from domain.com. To do this, DKIM automatically adds a digital signature to each message. This signature is based on a private key known only to your server. You then publish a public key in your domain’s DNS record. The recipient server can then use the public key to decode the signature and be sure the message has not been altered. So the main goal here is to someone from tampering with an email while in transit.
While the initial purpose was security, many ISPs, including Gmail, Yahoo and others, do use DKIM information in their screening efforts. I know with Gmail, if your DKIM signature fails, you have a very high probability that your message will be routed to the spam folder.
DKIM records are complex and must be generated correctly. They often look like this:
;default._domainkey.rackaid.com. IN TXT
default._domainkey.rackaid.com. 1800 IN TXT "v=DKIM1;k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/VMzpi2yfvnzVXCzPawWRC5LtnlzD0f7a3 /NI+oDfxiBAOlVISxps7sv0UPBK1D+rJAhCt4KB+eJcTFtOgXVWQmUMQLcAEHSwHHlbmZd3B8fMs4jYaoeJfPIy1bB0cZ1zh95dOfcMD8QFDsRlVFjrmRanvqOaJZ4Ftkbfqze5hQIDAQAB"
Setting up DKIM will vary depending on your email server platform. Due to the complexity of these records, be sure that you test them if you implement them.
While there are some online tools that will run DNS checks, I find the best way to verify DKIM and SPF is to send an email to Gmail. Send an email to Gmail from a non-Gmail account. Once the message arrives view the original: Select the drop down and then show the original.
You will get a message like this. I’ve highlighted the important areas.
Delivered-To: firstname.lastname@example.org Received: by 10.205.68.132 with SMTP id xy4csp69603bkb; Tue, 28 Jan 2014 12:35:30 -0800 (PST) X-Received: by 10.224.87.193 with SMTP id x1mr5956237qal.70.1390941329649; Tue, 28 Jan 2014 12:35:29 -0800 (PST) Return-Path: <email@example.com> Received: from mail.rackaid.com (mail.rackaid.com. [188.8.131.52]) by mx.google.com with ESMTP id v8si11907914qab.33.2014.01.28.12.35.29 for <firstname.lastname@example.org>; Tue, 28 Jan 2014 12:35:29 -0800 (PST) Received-SPF: pass (google.com: domain of email@example.com designates 184.108.40.206 as permitted sender) client-ip=220.127.116.11; Authentication-Results: mx.google.com; spf=pass (google.com: domain of firstname.lastname@example.org designates 18.104.22.168 as permitted sender) email@example.com; dkim=pass firstname.lastname@example.org Received: from [192.168.1.10] (unknown [22.214.171.124]) by mail.rackaid.com (Postfix) with ESMTPSA id A19D020AA0 for <email@example.com>; Tue, 28 Jan 2014 20:35:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rackaid.com; s=default; t=1390941328; bh=PIvxKsqRIWfk0KxweqtYayNK3Tof/BKNkwSnJe1EvME=; h=Date:From:To:Subject; b=Acmmq3p3lx7JAAA/95A6vCIXkJMvJZ9HAh5lWHZLVFzbywGx0e37bPcFDAZM2xAm0 Q1Dk1rc2ZDepmLA57fGif8T/JDH/UmvCRbW4/pRtNRE7cV+cq/JhYg3sZ03PEcyOGk AD7E5Of2LZ0L3T9VRel14gQxo8sx85YK4z2Y6cgc= Message-ID: <52E81490.firstname.lastname@example.org> Date: Tue, 28 Jan 2014 15:35:28 -0500 From: rackAID Support <email@example.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Jeffrey Huckaby <firstname.lastname@example.org> Subject: DKIM TEst Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM
Note the Received-SPF pass line. This indicates that our SPF DNS record has passed. Similarly, the next-line shows the authentication results for both spf and dkim. If either of these lines fail, you have a DNS record problem or a signing problem with DKIM.
If you cannot fix these issues, you are better off not having these records at all.
Be sure to use proper reverse DNS (PTR), SPF and DKIM records with your email campaigns. Doing so will assure better delivery rates – which hopefully means better ROI for your campaigns.