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

SPF Fail: too many DNS lookups

I’ve had a couple folks come to me recently for help troubleshooting SPF failures. The error messages said the SPF record was invalid, but by all checks it was valid.
Eventually, we tracked the issue down to how many include files were in the SPF record.
The SPF specification specifically limits the number of lookups that can happen during a SPF check.

Read More

Four things to check before your next mailing

Like many bits of technology, email is often set-and-forget. Everything is checked and rechecked during setup, and then no one goes back and looks at it again. But mail programs are not static, and people make changes. These changes don’t really break things, but over time they can create their own set of problems.
Setting aside some time every quarter or even every year to check and make sure all the bits of mail are configured correctly is a good idea.

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