Background
A domain may have multiple TXT records associated with it, provided the DNS server implementation supports this. Each record can in turn have one or more character strings. Traditionally these text fields were used for a variety of non-standardised uses, such as a full company or organisation name, or the address of a host. In 1993 RFC 1464 proposed a simple approach to storing attributes and their values in these text fields. This is now used extensively in: * Verification of domain ownership * Implementation of Sender Policy Framework (SPF) * DomainKeys Identified Mail (DKIM) records for verifying the sender of email messages * Zero-configuration networking DNS-based service discovery * Domain-based Message Authentication, Reporting and Conformance ( DMARC) policies Using TXT records to store data for different purposes is not without problems. The DNS protocol specifies that when a client queries for a specific record type (e.g., TXT) for a certain domain name (e.g., example.com), ''all'' records of that type must be returned in the same DNS message. That may lead to large transactions with lots of "unnecessary" information being transferred and/or uncertainty about which TXT record to use. There are two ways around this: to specify a domain name prefix to be used when using TXT records for a specific purpose (e.g., _domainkey.example.com – in the DKIM case) or to create a new record type entirely. The former is "easy" because it doesn't require any changes to the DNS. The latter is sometimes considered "cleaner" as it matches the design of the DNS database model better. In the past, creating new record types was often avoided since it was a complicated procedure in the IETF. The reluctance lingers with some people despite the process having been replaced by a much lighter and quicker one.Format
The structure of the TXT record is specified in as follows. Note that the specification is silent on the subject of character encoding of the text string. It explicitly states that the interpretation of the string is context dependent, and that the data is treated as binary inside the DNS. Later specifications (e.g., – DNS used for service discovery) may require the use of specific encodings for specific purposes. The RDATA section may contain multiple consecutive occurrences of (TXT Length + TXT). Data Length is the length of them all combined. This is the hex returned as part of the DNS response from example.com when queried for TXT records.example.com. IN TXT "This domain name is reserved for use in documentation"defines a structured format that can be used to define attributes and their values in a single record, as in these examples:
host.widgets.com. IN TXT "printer=lpr5" sam.widgets.com. IN TXT "favorite drink=orange juice"In practice, services using TXT records often do not follow this RFC, but instead have their own specific format.
Example usage
The character string from a TXT record used for SPF: "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 ip6:2620:0:860::/46 a -all" An example of use for DMARC:See also
* List of DNS record types * DMARC * DKIM * E-mail authenticationReferences
{{reflist Internet architecture Network addressing Internet governance Internet protocols Internet Standards DNS record types Email authentication Spam filtering