The TXT recordText strings and so much more!
The TXT or “descriptive text” DNS record type was created to hold human-readable text. It now plays a critical role in the prevention of spam on the Internet.
The TXT record type was introduced in the original DNS specifications (RFC 1034 and 1035) in 1987. They were to be used for notes and text created by DNS administrators. There was originally no definitive purpose for TXT records. They were used for whatever information the DNS administrator thought was useful. This included contact information, the locations and owners of machines, humorous messages, and other administrivia.
TXT records were used this way until 2003. In 2003 efforts began to fight back against spam and other abuses of email. This led to the creation of SPF (Sender Policy Framework). SPF stores email authority information in TXT records. Other uses for the TXT record type have been added over the years.Mail authentication before TXT records. Photo by 戸山 神奈
TXT record format
The RFC 1035 definition of the record data for TXT record is one or more “character-strings”. Each character string can be at most 255 characters long.
TXT records also have a Time-to-Live value in seconds, like all other DNS records. A simple example TXT record for
example.org with a TTL of 3600 seconds (one hour) might look like this:
example.org. 3600 TXT "Welcome to the example domain!"
There are a few somewhat confusing aspects of TXT records. Namely, the use of quotation marks and multiple character strings. Quotation marks are not necessary if you are working with TXT records in a DNS provider's web portal. When editing a traditional zone file, quotation marks are required around each string.
Each TXT record can contain multiple character strings. Each character string may contain up to 255 characters. Multiple TXT records may also exist at a single name in the DNS. See our 'related questions' section below for more details.
The examples on this page will use DNS zone file format so will contain quotation marks.
A real world TXT example
Let's examine the actual TXT response for
icann.org. At the time this page was written, the TXT response using dig or our TXT lookup tool is:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18975 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;icann.org. IN TXT ;; ANSWER SECTION: icann.org. 600 IN TXT "v=spf1 ip4:18.104.22.168/20 ip4:22.214.171.124/21 ip4:126.96.36.199/27 ip4:188.8.131.52/27 ip4:184.108.40.206/32 ip4:220.127.116.11/31 ip4:18.104.22.168/32 ip4:22.214.171.124/31" " ip6:2620:0:2d0::0/48 ip6:2620:0:2830::0/48 ip6:2620:0:2ed0::0/48 include:salesforce.icann.org -all"
The DNS administrator for ICANN has followed SPF requirements and created a single TXT record with two strings. There are two strings because the total length of the SPF record is longer than 255 characters.
Also note that quotation marks surround each character string. These quotation marks are not part of the TXT data. Dig included them so we can see where each string begins and ends.
Uses of the TXT record type
The TXT record was intended for free-form text entered by DNS administrators. Use of the TXT record has been expanded to other applications over the years.
Today, TXT records are mainly used for:
- SPF — Sender Policy Framework
- DKIM — Domain Keys Identified Mail
- DMARC — Domain-based Message Authentication, Reporting & Conformance
- MTA-STS — SMTP MTA Strict Transport Security
- Domain verification
- DNS-SD — DNS Service Discovery
Sender Policy Framework (SPF)
SPF is specified in RFC 7208. SPF uses DNS TXT records to list the mail servers permitted to send email for a domain. The creators of SPF used TXT records out of convenience. There was an attempt to create a dedicated DNS record type for SPF but this was officially deprecated in RFC 7208 section 3.1.
Below is a very simple SPF record example. This record states that the mail servers at the IP addresses 10.0.0.1 and 10.0.0.2 are permitted to send mail for the
example.org. 3600 TXT "v=spf1 ip4:10.0.0.1 ip4:10.0.0.2 -all"
Domain Keys Identified Mail (DKIM)
DKIM is specified in RFC 6376. DKIM uses DNS TXT records to publish the public key from a domain's public-private key pair. This public key is used to securely validate emails signed with a digital signature.
Unlike SPF records, the DNS TXT record for DKIM is not created at the root of the domain. The string following "p=" in the record data of the TXT is a public key. An example DKIM record for the
example.org domain is shown below. (The public key is truncated for readability.)
default._domainkey.example.org. 3600 TXT "v=DKIM1;t=s;p=MIGfMA0GCSqGS..."
Domain-based Message Authentication, Reporting & Conformance (DMARC)
DMARC is specified in RFC 7489. DMARC uses DNS TXT records to specify email policy for a domain. The policy specifies what action to take if SPF or DKIM checks fail on email received from the domain.
Like the DKIM record, the DMARC record is not created at root of the domain. An example is shown below. This example specifies that mail which does not pass DMARC checks should be placed in quarantine. Reports should be sent to [email protected]
_dmarc.example.org. 3600 TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
SMTP MTA Strict Transport Security (MTA-STS)
MTA-STS is specified in RFC 8461. MTA-STS allows a mail service provider to declare it accepts Transport Layer Security (TLS) to secure SMTP connections. It can also specify if other SMTP servers should refuse to deliver email to the domain if TLS is unavailable.
Below is a simple example of a TXT record for MTA-STS. The existence of this record signals that SMTP servers should attempt to retrieve the MTA-STS policy for the
example.org domain using an HTTPS get request. This record also gives the current policy ID.
_mta-sts.example.org. 3600 TXT "v=STSv1; id=20220601120000Z;"
In recent years it has become popular to use a DNS TXT record to prove ownership of a domain. A service provider gives the domain's administrator a challenge string. The administrator must publish the challenge string in a TXT record in their DNS zone. The service provider performs a DNS query for the TXT record and verifies that the challenge string has been published. This proves that the administrator controls DNS for the domain.
The format of the domain verification TXT record varies with provider. Always follow your provider's instructions exactly. The name of the service is usually included in the challenge string, so to verify a domain with Google the record might look something like this:
example.org. 3600 TXT "google=6e6922db-e3e6-4a36-904e-a805c28087fa"
The IETF draft sahib-domain-verification-techniques contains a survey of current uses of this method.
DNS Service Discovery (DNS-SD)
DNS-SD is specified in RFC 6763. DNS-SD allows services to be discovered by application clients through the DNS. This is an alternative to SRV records. The record data of the TXT record contains a set of key/value pairs preceded by length bytes. DNS-SD is not currently in widespread use.
Finding TXT records for a zone
The TXT records for a zone can be queried with the dig or nslookup command line tools. To find the mail servers for wikipedia.org, use this command:
dig TXT wikipedia.org
On operating systems that support nslookup, you can use the following:
nslookup -type=txt wikipedia.org
You can also check the TXT records of any domain name in our TXT lookup tool, or by entering it here:
Should you enter quotation marks in TXT records?
You need quotation marks when working with standard DNS zone files but not when typing TXT data into a DNS provider's web portal. Consult your DNS provider's documentation if you are unsure.
If you were to look at a DNS message as it travels across the Internet, you would not find quotation marks around TXT character strings.
Quotation marks around the character strings are required in DNS zone files. The DNS specifications call this “presentation format”. The quotation marks are not treated as part of the TXT record data.
A typical TXT record in a zone file might look like this:
example.org. 3600 TXT "apple banana pear"
This TXT record's data is a single character string consisting of three words separated by spaces. When the file is read, the quotation marks are discarded.
How many TXT records should you have?
The DNS specification allows multiple TXT records to exist. For human-readable data you can use any combination of multiple strings and multiple TXT records.
TXT records for other applications must follow required standards. Using SPF as an example, RFC 7208 section 3 specifies that a single TXT record must be used for SPF. SPF data longer than 255 characters must be broken up into multiple strings.
It is common to see multiple TXT records today in the DNS. One TXT might be for SPF and others might exist for domain verification or other uses. For example this record set contains a SPF record and a domain verification record:
example.org. 3600 TXT "v=spf1 ip4:10.0.0.1 ip4:10.0.0.2 -all" example.org. 3600 TXT "google=6e6922db-e3e6-4a36-904e-a805c28087fa"
How large can TXT records be?
The RFCs do not impose a size limit on TXT records but there are practical considerations that are important.
DNS can be transported over UDP or TCP. It is best to keep the total size of the TXT record set small enough that TCP is not required. If possible, keep the total size of the DNS response message below 512 bytes. However this may not always be practical. Most modern DNS resolvers support UDP payloads larger than 512 bytes. A more realistic goal for the DNS response size is 1232 bytes. DNS Flag Day is an industry effort to set a uniform and safe upper bound for DNS UDP payload size.
Exceeding a DNS response size of 1232 bytes for DNS queries for your domain is problematic for these reasons:
- DNS requests made by legitimate clients will take longer to complete. This increases latency.
- Malicious parties may use the domain as part of DNS Distributed Denial-of-Service (DDoS) attacks. Botnets may query the domain in an attempt to overwhelm resolvers with expensive TCP requests.
Limiting the amount of TXT data as much as possible reduces latency and protects against abuse.