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 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 Records
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:
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.
Reverse DNS Setup
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.
.
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.
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 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: jeffatrackaid@gmail.com
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: <support@rackaid.com>
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 <jeffatrackaid@gmail.com>;
Tue, 28 Jan 2014 12:35:29 -0800 (PST)
Received-SPF: pass (google.com: domain of support@rackaid.com 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 support@rackaid.com designates 54.221.232.71 as permitted sender) smtp.mail=support@rackaid.com;
dkim=pass header.i=@rackaid.com
Received: from [192.168.1.10] (unknown [173.165.203.78])
by mail.rackaid.com (Postfix) with ESMTPSA id A19D020AA0
for <jeffatrackaid@gmail.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.8030603@rackaid.com>
Date: Tue, 28 Jan 2014 15:35:28 -0500
From: rackAID Support <support@rackaid.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 <jeffatrackaid@gmail.com>
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.
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.
Article ID: 120, Created On: 1/28/2016, Modified: 1/28/2016