TXTing

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.