TXTing

txt
On Friday I talked a bit about the history behind TXT records, their uses and abuses.
But what’s in a TXT record? How is it used? When and where should you use them?
Here’s what you get if you query for the TXT records for exacttarget.com from a unix or OS X command line with dig exacttarget.com txt

~ ∙ dig exacttarget.com txt
; <<>> DiG 9.8.3-P1 <<>> exacttarget.com txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27531
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;exacttarget.com. IN TXT
;; ANSWER SECTION:
exacttarget.com. 300 IN TXT "v=spf1 include:spf0.exacttarget.com -all"
exacttarget.com. 300 IN TXT "spf2.0/pra ip4:207.250.79.101 ip4:207.67.98.192/27 ip4:72.18.216.98 include:cust-senderid.exacttarget.com include:salesforce.com include:message1-senderid-inc.exacttarget.com include:hotels-senderid-inc.exacttarget.com ip4:206.246.157.1 -all"
exacttarget.com. 300 IN TXT "c/JoPaoCrXsJAEy9WKGJqA70w09P2sdGF+jRXcyVQm62Qb/gfNTUetiZApbdDNAQwRLCYKoDIdKw/6+kICwYCw=="
exacttarget.com. 300 IN TXT "v=msv1 t=CD773640-B552-4170-B97B-3186A3D66D49"
;; Query time: 222 msec
;; SERVER: 192.168.80.1#53(192.168.80.1)
;; WHEN: Mon Aug 17 11:34:30 2015
;; MSG SIZE rcvd: 499

(On Windows? You can either use web-based lookup tools, or fire up PowerShell and run “Resolve-DNSName exacttarget.com -Type TXT” to get the same data in a slightly different format. As a last resort “nslookup -type=txt exacttarget.com” will work too, but it’s a terrible, and sometimes misleading, tool. On iOS or Android? It’s useful to be able to use your phone to check DNS from somewhere not on your network …)
You can see that this query returns four TXT records. The first (v=spf1…) is an SPF record, one that just includes the real SPF data from elsewhere. The second (spf2.0/pra …) is SenderID (the dead Microsoft-specific SPF variant). The third (c/JoP…) I don’t recognize, almost certainly domain authorization of some sort, and the third (v=msv1 …) is Microsoft domain authorization (needed if you want to use office.com for your email, but also needed for things like Hotmail feedback loops).
The right-hand side of each TXT record is surrounded by double quotes here – they’re just added by dig to show you that it’s a string, they’re not part of the TXT record itself. Other tools may delimit the strings in different ways.
Right down at the bottom you can see the total size of the DNS reply packet – 499 bytes. That’s an important number to know about. If the size of your DNS reply packets exceeds 512 bytes then things can go wrong in subtle ways; depending on the path DNS replies follow they may get truncated or discarded. Everything may look fine to you and to other places you check your DNS from but some recipients, particularly those who are behind old networking gear or poorly configured firewalls and NATs, may reliably see DNS failures, breaking your SPF and potentially harming delivery.
Lets look at the SPF record that ExactTarget are including – spf0.exacttarget.com (I’m using ExactTarget’s DNS as an example as it shows off all the features I want to talk about and is mostly a good example of how you should do things).

~ ∙ dig spf0.exacttarget.com txt
; <<>> DiG 9.8.3-P1 <<>> spf0.exacttarget.com txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55889
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;spf0.exacttarget.com. IN TXT
;; ANSWER SECTION:
spf0.exacttarget.com. 300 IN TXT "v=spf1 ip4:50.18.45.249 ip4:50.18.121.236 ip4:50.18.121.248 ip4:50.18.123.221 ip4:50.18.124.70 ip4:50.18.125.97 ip4:50.18.125.237 ip4:50.18.126.162 " "ip4:50.31.32.0/19 ip4:62.17.146.128/26 ip4:64.18.0.0/20 ip4:64.20.241.45 ip4:64.132.88.0/23 ip4:64.132.92.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.231.80.0/20 " "ip4:66.249.80.0/20 ip4:67.23.31.6 ip4:67.228.2.24/30 " "include:spf1.exacttarget.com -all"
;; Query time: 607 msec
;; SERVER: 192.168.80.1#53(192.168.80.1)
;; WHEN: Mon Aug 17 12:39:56 2015
;; MSG SIZE rcvd: 456

This time we get just one TXT record in reply.
What are all those double quotes in the middle of the reply? Well, a TXT record contains one or more text strings – and this one contains four.
Each string in the reply is delimited by double quotes, then those four delimited strings are separated by a single space (again, this is specific to the way dig displays results and other tools might display them differently).
What do the multiple strings mean? From a DNS point of view, nothing special, they’re just four separate strings. Other protocols layered on top of DNS can have different semantics, though. SPF specifies that when there are multiple strings in a TXT reply then those strings are to be concatenated together with no additional whitespace.
That’s important to know – it means that SPF will treat “foo” “bar” as the single string “foobar”, not “foo bar”. And that “ip4:1.2.3.4” “ip4:5.6.7.8” will be treated as the invalid string “ip4:1.2.3.4ip45.6.7.8” and not the “ip4:1.2.3.4 ip4:5.6.7.8” you expected. You can see above that ExactTarget do the right thing, making sure that there’s appropriate white space when the strings are concatenated.
I mentioned above that it was important to keep the size of DNS replies below 513 bytes. That restriction, along with the limit of 10 DNS queries in  valid SPF record makes optimizing large SPF records quite complex – but that’s probably a topic for a dedicated white paper rather than a couple of paragraphs in a blog post.
It also makes the space for TXT records at the root of the domain particularly precious.
DKIM and DMARC records aren’t a problem, as they all live under their own dedicated hostnames. But SPF, SenderID and domain authentication TXT records all share the space at the domain root, so there are several groups with different needs who risk stepping on each others toes when they update TXT records there. If your customer support group starts using an outsourced ticketing system and are required to add a TXT record at the domain root to prove they own it then that new record might push the size of your DNS reply over 512 bytes and cause your SPF authentication to start failing for some recipients.
What can you do about that?

  • Be aware that the root of the domain is valuable DNS real estate.
  • Get rid of any junk there (such as SenderID records).
  • Take advantage of SPF’s include: functionality to move your SPF data to TXT records elsewhere (though you have to balance that against the desire to minimize the number of DNS queries needed to query all your SPF records).
  • If you need to authenticate your domain use something other than a TXT record at the root (Google, for example, also accept CNAMEs, meta tags and html files instead).
  • If a vendor requires you to add a TXT record at the root, push back and ask them to support, e.g., using CNAMEs or a TXT record at a subdomain instead.

I hope this makes TXT records a little less inscrutable and simplifies using and diagnosing problems with them.

Related Posts

4 things spammers do legitimate marketers don't

I’ve never met a spammer that claims to be a spammer. Most that I’ve met claim to be legitimate marketers (or high volume email deployers). But there are things spammers do that I never expect to see a legitimate marketer doing.
I’ve written about these things throughout the blog (tag: TWSD), but it’s probably time to actually pull them together into a single post.

Read More

PTR Records

PTR records are easy to over look and they have a significant impact on your ability to deliver mail without them.  Some ISP and mailbox providers will reject mail from IP addresses that do not have a PTR record created. PTR records are a type of DNS record that resolves an IP address to a fully qualified domain name or FQDN.  The PTR records are also called Reverse DNS records. If you are sending mail on a shared IP address, you’ll want to check to make sure the PTR record is setup, however you most likely will not be able to change it.  If you are on a dedicated IP address or using a hosting provider like Rackspace or Amazon AWS, you’ll want to create or change the PTR records to reflect your domain name.
We usually think about DNS records resolving a domain name such as www.wordtothewise.com to an IP address.  A query for www.wordtothewise.com is sent to a DNS server and the server checks for a matching record and returns the IP address of 184.105.179.167.  The A record for www is stored within the zone file for wordtothewise.com.  PTR records are not stored within your domain zonefile, they are stored in a zonefile usually managed by your service provider or network provider.
Some service providers provide an interface where you can create the PTR record yourself, others require you to submit a support request to create or change the PTR record.
If you know what IP address you are sending mail from, use our web based DNS tool to check if you have a PTR record created.
http://tools.wordtothewise.com/dns
Checking for a PTR record for 184.105.179.167 returns
167.128-25.179.105.184.in-addr.arpa 3600 PTR webprod.wordtothewise.com.
If you received Response: NXDOMAIN (There is no record of any type for x.x.x.x.in-addr.arpa), this means you’re missing the PTR record and need to create one ASAP if you are sending mail from that IP address!

Read More

Troubleshooting tools

There have been a number of comments on my post about Hotmail moving to SPF authentication having to do with troubleshooting authentication failures. I have been helping clients troubleshoot these issues, and am able to take on new clients to solve authentication problems. Contact me for more information.
Of course, many of these issues can be solved with access to the right tools. Steve’s been working on a number of tools that may help the troubleshooting process and we’ve recently launched them on Emailstuff.org. The website itself contains a number of DNS and data related tools we use for investigations and thought we’d share with the public at large.
One of the really useful tools is the SPF record expander. Plug in any domain, like google.com, and see what IP addresses they authorize to send mail.

Read More