DNS for Email Marketers
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 DNS Records you must know for good email delivery are:
- Reverse DNS (PTR)
- SPF (Sender Policy Framework)
- DKIM (DomainKeys Identified Mail)
These are the 3 DNS records you must have correct for sending email reliably. Of course, you need an MX record if you want to receive email, but that’s another topic.
Reverse DNS Records
If you have to get one DNS record right, the reverse DNS record, also know as a PTR record, is the one. 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.
Without a valid reverse DNS record, many ISPs will block your email .
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:
dig mail.microsoft.com
;; ANSWER SECTION: mail.microsoft.com. 681 IN A 131.107.125.5
Reverse PTR record:
dig -x 131.107.125.5
;; ANSWER SECTION: 5.125.107.131.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 131.107.125.5 and that if we lookup up 131.107.125.5, 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.
How To Setup a Reverse DNS Record
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.
SPF Records
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:147.243.128.24 ip4:147.243.128.26 ip4:147.243.128.25 ip4:147.243.1.47 ip4:147.243.1.48 ~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.
Common SPF Errors
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.
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.
DKIM Records
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.
Checking DNS Records
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: [email protected] 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 protected]> Received: from mail.rackaid.com (mail.rackaid.com. [54.221.232.71]) by mx.google.com with ESMTP id v8si11907914qab.33.2014.01.28.12.35.29 for <[email protected]>; Tue, 28 Jan 2014 12:35:29 -0800 (PST) Received-SPF: pass (google.com: domain of [email protected] designates 54.221.232.71 as permitted sender) client-ip=54.221.232.71; Authentication-Results: mx.google.com; spf=pass (google.com: domain of [email protected] designates 54.221.232.71 as permitted sender) [email protected]; dkim=pass [email protected] Received: from [192.168.1.10] (unknown [173.165.203.78]) by mail.rackaid.com (Postfix) with ESMTPSA id A19D020AA0 for <[email protected]>; 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: <[email protected]> Date: Tue, 28 Jan 2014 15:35:28 -0500 From: rackAID Support <[email protected]> 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 <[email protected]> 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.
DNS Record Recap
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.
Email Delivery Optimization Services
If you need help getting your email to the inbox, we provide email support services. We will start by setting up your DNS records and verifying they are correct. We then check email sending behavior, server configuration and headers to optimize email delivery rates.
We support:
- Red Hat Entperise (Postfix & Sendmail)
- cPanel (Exim)
- Plesk (Qmail & Postfix)
- CentOS (Postfix & Sendmail)
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.