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

Office365/EOP IPv6 changes starting today

Terry Zink at Microsoft posted earlier this week that Office365/Exchange Online Protection will have a significant change this week. Office365 uses Exchange Online Protection (EOP) for spam filtering and email protection. One of the requirements to send to EOP over IPv6 is to have the email authenticated with either SPF or DKIM.  If the mail sent to Office365/EOP over IPv6 is not authenticated with SPF or DKIM, EOP would reject the message with a 554 hard bounce message.  Most mail servers accept the 554 status code and would not retry the message.  After multiple 5xx hard bounces to an email address, many mail servers would unsubscribe the user from future email campaigns.  The update starting today April 24, will change the error status code for unauthenticated mail to EOP from a 554 hard bounce to a 450 soft bounce and a RFC-compliant and properly configured mail server would then retry the message.
Prior to April 24, 2015, EOP responds to unauthenticated mail with a status code of: “554 5.7.26 Service Unavailable, message sent over IPv6 must pass either SPF or DKIM validation”.

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