DNS for Email Marketershttps://www.rise.company/forum/image...t_dnspng-1.jpgAs 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:
- Reverse DNS (PTR)
- SPF (Sender Policy Framework)
- DKIM (DomainKeys Identified Mail)
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.
Reverse DNS RecordsIf 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.
https://www.rise.company/forum/image...utiongif-1.jpg
Here’s another example from Microsoft:
Forward A record:
dig mail.microsoft.com;; ANSWER SECTION:
mail.microsoft.com. 681 IN A 131.107.125.5Reverse 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.
Reverse DNS SetupIn 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 RecordsAfter 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.
https://www.rise.company/forum/image...spf_flow-1.jpg
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 ErrorsI 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.
DKIM RecordsJust 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 TXTdefault._domainkey.rackaid.com. 1800 IN TXT "v=DKIM1;k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBi QKBgQC/VMzpi2yfvnzVXCzPawWRC5LtnlzD0f7a3
/NI+oDfxiBAOlVISxps7sv0UPBK1D+rJAhCt4KB+eJcTFtOgXVW QmUMQLcAEHSwHHlbmZd3B8fMs4jYaoeJfPIy1bB0cZ1zh95dOf cMD8QFDsRlVFjrmRanvqOaJZ4Ftkbfqze5hQIDAQAB"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 RecordsWhile 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.
https://www.rise.company/forum/image...ginalpng-1.jpg
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
DKIMNote 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.
DNS Record RecapBe 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.
